关于&0xFF的理解

  做协议解析时候，一个byte的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，而在强制转化中，系统认定是有符号的byte，所以转化为-2。
  但是你按位相与后，应该是肯定了每一个bit都是数值而不是有一个符号位，想当于把有符号的数转换为无符号的数。 
 还是拿-2举例子：
 1111_1110 8bit byte
 扩展后
 11111111_1111111_1111111_11111110 32bit int
 此时，int的值还是-2，但是byte值应该是8bit位，所以与0xff相与，成为
 00000000_00000000_00000000_11111110
 这样才符合byte转换过去的取值范围
还需要注意的是char类型，
char c=(char)-1;
char是无符号类型，相当于c=65535;
所以，你要转换时候，直接就是65535
011111111_11111111  char 16bit
0000000_00000000_011111111_11111111 int 32 bit

总结

&0xFF就是为了将转换后的补码表达式，多余的位数去掉（1->0），转换前有效位数多少，转换后还应该多少位，
如果是short转化的话就应该是&0xffff