在进行协议分析时，一个字节的0xFE将直接转换为int，应该是254，但最终为-2。 在网上查的话，也有人说是因为java以补数表示的byte。 网站： http://www.blogjava.net/orangelizq/archive/2008/07/20/216228.html如果你有兴趣的话请去看看。
我不这么认为。 当然，byte底部表示使用补码。 好像一切都是补数呢。 我指的是问题的根源不是编码方式，而是有符号和无符号。
0xFE-1111_1110B
第一个bit为1，显示为负，剩下的要求补充。 (大家取反后1 )是-2
的byte确实是- 128到127
但是，现在我们假设0xFE是254，它是无符号的，并且支持c的unsigned char，但是强制转换会将0xFE转换为-2，因为系统已验证为有符号字节。
但是，相位匹配之后，应该确信所有的比特都是数值而不是一个编码比特，并且想把有符号的数据转换成无符号的数据。
还是以-2为例：
1111 _ 1110 8位字节
扩展后
11111111 _ 1111111 _ 1111111 _ 111111111032 bit int
此时，int值还为-2，但字节值应该为8bit位，因此为0xff相和
00000000 _ 0000000 _ 00000000000 _ 1111110
现在，它匹配byte变换的过去值的范围
也需要注意char类型
charc=(char )-1；
char为无符号类型，相当于c=65535；
所以，你转换的时候，直接是65535
011111111_11111111 char 16bit
0000000 _ 000000 _ 01111111 _ 1111111 int 32 bit
总结0xFF的原因是，对于变换后的补数式，去除多余的位数(1-0)，使变换前的有效位数为几位，变换后也应该为几位，
如果是短变换，应该是0xffff