Java Socket实现设备数据采集时非ASCII二进制流读取解析异常问题

两个直接导致数据解析失败的核心错误 #

• 误用字符流处理二进制原始报文
  你当前通过InputStreamReader把Socket获取的原始字节流强制按字符编码做转换，但设备发送的数据是混合了可打印ASCII字段、高位二进制字段的工业原始报文（报文中0xB5、0x99、0xAB这类值都超出了单字节ASCII的0-127范围），根本不属于纯文本流范畴。
  你贴的抓包结果里大量出现的十进制值65533，正好是UTF-8转码遇到非法高位字节时生成的Unicode替换字符（U+FFFD）——前几个落在ASCII范围内的字节能正常转成可见字符，一旦遇到超出ASCII范围的字节，转码逻辑就会因多字节匹配规则错位，把后续连续字节全部判定为非法，直接替换成乱码占位符，原始二进制数据会被永久损毁，无法恢复。
• 读取逻辑不适配高速数据传输场景
  你用inputStreamReader.ready()判断是否读完数据，这个方法对Socket流没有实际参考价值：它只能判断当前瞬间有没有缓存的字节可以非阻塞读取，根本无法识别后续是否还有数据正在网络传输途中。高速传输场景下，很容易出现当前缓存字节读完就直接break退出循环，导致还在路上的字节被直接丢弃。
  你之前Python实现里的s.recv(2048)本质是直接读取原始字节数组，全程没有做任何编码转换，所以能正常拿到全量数据。

可直接落地的修正方法 #

• 彻底移除InputStreamReader组件，直接使用Socket原生InputStream读取原始字节，全程不要做提前的字符编码转换。
• 对齐Python的实现逻辑，用固定大小的字节缓冲区接收数据（比如设置2048长度的byte数组，和Python的recv参数保持一致），不要逐字节循环拼接——高速场景下逐字节读取的IO开销极高，很容易导致内核接收缓冲区溢出、数据被覆盖丢失。
• 后续需要解析报文中的可打印ASCII段时，再单独把对应位置的字节按US-ASCII编码转成字符串即可，剩下的高位二进制字段直接按原始字节做数值解析。

修正后的核心代码参考：

Socket socket = new Socket(ipAddress, portNumber);
// 直接获取原始字节流，不做任何字符转换
InputStream inputStream = socket.getInputStream();
// 与Python逻辑对齐，设置2048长度的接收缓冲区
byte[] recvBuffer = new byte[2048];

public static byte[] recMsg(InputStream inputStream) throws IOException {
    // 一次性读取流中当前所有可读字节，返回实际读到的字节长度
    int readLen = inputStream.read(recvBuffer);
    if (readLen == -1) {
        throw new IOException("设备连接已断开");
    }
    // 直接返回前readLen个原始字节，无编码损坏
    // 如需解析ASCII字段，可单独处理，例如：
    // String asciiPart = new String(recvBuffer, 0, 2, StandardCharsets.US_ASCII);
    System.out.println("本次实际接收字节数：" + readLen);
    return Arrays.copyOf(recvBuffer, readLen);
}

避坑提醒：不要反复尝试给InputStreamReader更换编码集（比如尝试GBK、ISO-8859-1）解决问题——只要报文里存在不符合编码规则的二进制字段，不管选什么编码，走字符流通道都会导致数据损毁。工业设备的二进制报文要优先用原始字节流处理，只有明确识别到报文边界、需要解析可打印文本段的时候，再对指定位置的字节做编码转换。

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