本文详解如何正确处理tcp通信中文件名和大小的字符串编码/解码，避免因二进制数据混入导致的unicodedecodeerror，并提供健壮、可复用的收发逻辑。
在基于Python Socket
的文件传输场景中（如使用pycryptodome进行加密传输），一个常见但易被忽视的问题是：将非纯文本的二进制数据误当作UTF-8字符串解码。你遇到的 UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb5 in position 2 正是典型表现——接收端调用 .decode() 时，实际收到的数据缓冲区中混入了加密后的二进制字节（如 0xb5 是无效UTF-8起始字节），导致解码失败。
根本原因在于：你的原始代码中，client.send(str(file_size).encode()) 发送的是纯ASCII数字字符串（如 "1024"），本应安全；但后续紧随其后的 client.sendall(encrypted) 发送的是密文（任意字节流），而TCP是字节流协议，无消息边界。接收端连续调用 recv(1024) 无法保证每次恰好收到完整字符串——很可能第一次 recv(1024) 拿到的是 "1024" 后半段 + 加密数据开头（如 "1024\xB5\xA2..."），此时 .decode() 就会崩溃。
✅ 正确做法是：严格分离控制信息（文件名、大小）与数据载荷（密文），并确保控制信息独立、完整、可预测地接收。推荐采用以下结构化协议：
-
发送端（Server/Client）：
- 先发送文件名（UTF-8编码，长度可控）
- 再发送文件大小（ASCII数字字符串，如 "12345"）
- 关键：在两者之间加入明确分隔符（如 \n）或固定长度头部（如4字节大端整数），避免粘包
-
接收端（Client/Server）：
- 使用 recv() 循环读取，直到收到完整分隔符（如 \n）为止，再解码为字符串
- 或使用 struct.pack/unpack 处理定长数值（更可靠）
以下是优化后的稳健实现示例：
# ✅ 推荐：使用换行符分隔控制信息（简单清晰）
# 发送端
client.send(f"{file_name}\n".encode('utf-8'))
client.send(f"{file_size}\n".encode('utf-8'))
client.sendall(encrypted)
client.send(b'')
client.close()
# 接收端 —— 关键：按行接收，避免截断
def recv_line(sock, max_len=1024):
buffer = b''
while len(buffer) < max_len:
chunk = sock.recv(1)
if not chunk:
raise ConnectionError("Connection closed unexpectedly")
buffer += chunk
if buffer.endswith(b'\n'):
return buffer.rstrip(b'\n').decode('utf-8')
raise ValueError("Line too long")
file_name = recv_line(client) # 自动处理完整行
file_size = int(recv_line(client)) # 安全转换为整数
print(f"Receiving '{file_name}' ({file_size} bytes)")
# 后续接收加密数据... ⚠️ 注意事项：
- 永远不要对未知二进制数据调用 .decode() —— 只对明确为文本的控制字段（如文件名、大小字符串）解码；
- errors='replace' 仅掩盖问题，不解决根本（可能得到乱码如 "102"，后续 int() 仍失败）；
- 若需更高可靠性，建议改用 struct 打包文件大小（如 struct.pack('>I', file_size) 发送4字节大端整数），接收端用 struct.unpack('>I', sock.recv(4)) 解析，完全规避编码问题；
- 加密数据（encrypted）必须以 bytes 形式原样传输/写入，绝不尝试 .decode()。
通过分离协议层与数据层、明确消息边界，即可彻底规避此类 UnicodeDecodeError，构建稳定可靠的文件传输系统。
