Java中byte是有符号类型（-128～127），但网络协议等将其视为无符号（0～255），本质是字节语义鸿沟；统一解释需用b & 0xFF转为0～255，避免符号扩展干扰。
Java中byte本身是有符号的，范围-128～127，但网络协议、二进制文件、硬件接口等几乎都把字节当作无符号值（0～255）使用。所以不是“被解析错了”，而是Java类型语义和协议语义不一致——本质是字节语义鸿沟，处理关键在于统一解释视角。
理解负数出现的根本原因
Java的byte用补码表示，比如0xFF物理上是8个1，JVM按有符号解读就是-1；而TCP/IP或JPEG协议里它就代表255。当你用System.out.println(buf[0])直接打印，看到-1，只是Java在用自己规则读内存，并非数据损坏。InputStream.read()返回-1特指流结束，是约定，不是字节值。
将单个byte转为0～255的整数
最稳妥、最常用的方式是按位与0xFF：
-
int unsigned = b & 0xFF;—— 利用int是32位，&操作会把byte先提升为int（符号扩展），再用0xFF（即0x000000FF）屏蔽高24位，只保留低8位有效值 - 例如：
byte b = (byte)0xFF; int u = b & 0xFF;→ u = 255 - 不要用
Byte.toUnsignedInt(b)（JDK 8+才有），它底层也是b & 0xFF，但语义更清晰，可读性更好
处理byte数组时避免逐个踩坑
批量解析协议字段时，不能只在最后一步转换，必须在参与运算前就转成无符号语义：
立即学习“Java免费学习笔记（深入）”；
- 提取长度字段：
int len = ((buf[4] & 0xFF) —— 每个byte都要先&0xFF，否则高位byte为负时会符号扩展污染整个int - 做异或校验：
int xor = 0; for (byte b : data) xor ^= (b & 0xFF);—— 直接用int累加，避免byte异或后溢出变负影响结果 - 构造报文字段：写入前确认源值在0～255，再强转
(byte) value，Java会自动截断（如256→0，255→-1），但这是有意为之的模256行为
调试与日志输出技巧
开发阶段看到负数别急着修逻辑，先确认是不是显示问题：
- 打印十六进制更可靠：
String.format("0x%02X", b & 0xFF)→ 总是显示0x00～0xFF - 打印二进制看本质：
String.format("%8s", Integer.toBinaryString(b & 0xFF)).replace(' ', '0') - 用Arrays.toString()看数组会误导，改用自定义格式化方法，统一转成无符号再输出
