TCP服务端接收字节数组而非字符串的原因及解决方法

这种情况我之前做TCP服务端开发时碰到过好几次，大概率是编码格式不匹配或者数据传输时的字节解析错误导致的，咱们来一步步捋清楚原因和解决办法：

一、可能的问题根源 #

• 字符编码不兼容：客户端发送字符串时用的编码（比如ASCII、UTF-8）和服务端解析时用的编码不一致，就会把原本的数字、符号转成奇怪的转义格式。你看到的/06/05这类内容，很可能是服务端把字符对应的字节值错误解析成了八进制/十六进制转义，而不是直接转成文本字符。
• 字节流解析逻辑错误：TCP是基于字节流的协议，如果服务端接收时没有按正确的方式把字节转成字符串（比如把字节当成二进制数据打印，而不是解码成文本），就会出现这种乱码。比如字符'8'的ASCII码是56，要是直接把这个字节值转成八进制就会显示成070，看起来就像乱码。
• 客户端的额外转义处理：有些客户端可能会对特殊字符（比如'-'）做转义，或者发送的是二进制封装的字符串，服务端没有做对应的反转义处理，自然读不到原始字符串。

二、正确接收的解决方法 #

1. 统一字符编码格式 #

确保服务端和客户端使用完全相同的编码（推荐UTF-8或ASCII，这俩是通用的文本编码）。举几个常见语言的示例：

• Python：

import socket

server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind(("0.0.0.0", 9999))
server.listen(1)

conn, addr = server.accept()
# 接收字节后用UTF-8解码成字符串
raw_data = conn.recv(1024)
received_str = raw_data.decode("utf-8").strip()
print(f"正确接收的内容：{received_str}")
conn.close()

• Java：

Socket clientSocket = serverSocket.accept();
InputStream in = clientSocket.getInputStream();
byte[] buffer = new byte[1024];
int bytesRead = in.read(buffer);
// 指定UTF-8解码字节数组
String receivedStr = new String(buffer, 0, bytesRead, StandardCharsets.UTF_8);
System.out.println("正确接收的内容：" + receivedStr);

2. 按正确方式解析字节流 #

如果客户端发送的是固定长度的字符串（比如你说的A8745783-K8757853是17位），可以按固定长度接收，避免截断或多余解析。比如C#的示例：

byte[] buffer = new byte[17];
int bytesReceived = client.Receive(buffer);
if (bytesReceived == 17)
{
    string receivedStr = Encoding.UTF8.GetString(buffer);
    Console.WriteLine("正确接收的内容：" + receivedStr);
}

3. 检查是否需要反转义 #

如果确认客户端发送时做了转义（比如把普通字符转成了八进制/十六进制转义序列），你需要找到客户端的转义规则，在服务端做反转义处理。比如如果客户端把'5'转成了\065，那你就需要写个小逻辑把这些转义序列替换回对应的字符。

4. 抓包验证原始数据 #

用Wireshark抓一下客户端发送的原始字节流，看看实际发送的是什么。比如如果抓包看到字节是41 38 37 34 35 37 38 33 2D 4B 38 37 35 37 38 35 33，这就是ASCII码对应的A8745783-K8757853，那问题肯定出在服务端的解析逻辑上；如果抓包的字节本身就是乱的，那就要排查客户端的发送逻辑。

内容的提问来源于stack exchange，提问作者TheHappyGuy