使用Camel Netty4监听TCP端口时的字节数据异常问题

你遇到的这个问题其实是Java中有符号byte类型的符号扩展导致的，我来给你拆解原因和解决办法：

问题根源 #

Java里的byte是有符号数据类型，取值范围是-128到127（对应十六进制0x80到0x7F）。当你读取到0x80、0x84这类大于0x7F的字节时，它们在Java中会被表示为负数（比如0x80对应十进制-128）。当你把这个byte转换成int（比如打印或者处理的时候），JVM会自动进行符号位扩展——把byte最高位的1填充到int的高24位，所以0x80就变成了0xFFFFFF80，这就是你看到多余ffffff的原因。

解决方案：去掉符号扩展 #

只需要在处理byte值的时候，通过位运算& 0xFF来清零高24位，就能得到无符号的8位数值。下面是修改你代码的几个关键点：

1. 修改decode方法中的打印逻辑
   把打印部分的代码改成这样，确保输出正确的无符号值：

// 替换原来的打印语句
System.out.println(bytes[0] & 0xFF); // 打印十进制无符号值
System.out.println(Integer.toBinaryString(bytes[0] & 0xFF)); // 打印二进制
System.out.println(Integer.toHexString(bytes[0] & 0xFF)); // 打印十六进制

2. 修正MyMessage类的存储和输出
   因为IMEI的字节是无符号的，建议把data1改成int类型存储无符号值，避免后续处理再出现符号问题：

class MyMessage {
    protected int data1; // 用int存储无符号字节值
    public MyMessage(byte[] data) {
        data1 = data[0] & 0xFF; // 去掉符号扩展
    }
    public String toString() {
        return "MyMessage: { 0x" + Integer.toHexString(data1) +" }";
    }
}

如果你用的是Java 8及以上版本，也可以用Byte.toUnsignedInt(data[0])来替代data[0] & 0xFF，效果完全一致，代码可读性会更好。

额外小建议 #

另外，你在MyMessageDecoder里用了静态的FileWriter，这在Netty的多线程处理环境下会有线程安全问题，建议要么改成线程安全的写入方式，要么直接依赖Camel路由里的to("file://...")逻辑来写入文件，避免重复操作。

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