踩坑，netty读取基本数据类型出现负数

传输的对象单位 -- 字节流 00000000

解析16进制（流）解析成了负数：

情况一：
------------ 其实就是大小端的问题（高位在前还是在后）。转换一下重新解析就好了。

情况二：
------------ 这就是看计算机基础和JAVA基本功扎不扎实了，同时也是一个小细节问题。我们知道在JAVA中基本类型都是有符号类型，就是说Java中所有的byte类型都是signed类型。只能表达（-128 ~ 127）。而物联网设备传输给我们的时候却可能是无符号类型unsigned byte type（0 ~ 255）。那么知道了原委，处理应该就很简单了。

Java中unsigned byte 的转换

转换方式：
`int luminance = row[x] & 0xFF;`
首先将接受类型声明为short或者int类型。然后与0xFF取&即可。

下面，具体说明这样做的原理。
0xff 表示为二进制就是 1111 1111。在[signed] byte类型中，代表-1；但在short或者int类型中则代表255.
当把byte类型的-1赋值到short或者int类型时，虽然值仍然代表-1，但却由1111 1111变成1111 1111 1111 1111.
再将其与0xff进行掩码：
  -1: 11111111 1111111
0xFF: 00000000 1111111
 255: 00000000 1111111
所以这样，-1就转换成255.

下面再补充一点关联点

16进制显示的误区：

物联网那边使用16进制只是因为行业习惯或者阅读方便的原因，实际底层一样是字节码。JVM实时堆栈存储其实也属于字节码，但是因为“人性化原因”会默认转为十进制方便阅读。而物联网设备响应的信息显示是16进制，实际也是字节码，使用字节码数组接收，然后直接收到转字符就行new String(recdata,0,data.length)。

记住一点即可，底层传输时数据均为二进制，所以调试的时候不要在意IDE工具显示堆栈的进制是什么，底层形态仍然是二进制。

ByteBuf读操作：

   ByteBuf.readByte() 读一个字节，有符号

   ByteBuf.readUnsignedByte() 读一个字节，无符号

   ByteBuf.readShort() 读连续的两个字节，有符号

   ByteBuf.readUnsignedShort() 读连续的两个字节，无符号

   ByteBuf.readInt() 读连续的四个字节，有符号

   ByteBuf.readUnsignedInt() 读连续的四个字节，无符号

   关于有符号与无符号的区别，以ByteBuf.readByte()和ByteBuf.readUnsignedByte()为例：

   ByteBuf.readUnsignedByte()就等价于：ByteBuf.readByte()&0xFF

在做byte -> int类型转换时，JVM会做一个补位处理，
（注：补位是补1还是补0，取决于byte的最高位是1还是0）
以协议中出现的0x8A的协议号为例，转成二进制为：10001010，
如果直接赋值int值后是其实在计算机存储的是11111111 11111111 11111111 10001010（32位），
这个时候其实与最初的0x8A已经完全不等了，所以我们需要对其进行与0xFF做与运算，
可以将高24位置为0，低8位保持不变，这样做就可以保证和二进制补码的一致了。

骚操作：

如果我们想读取3个字节的整型数值，可以使用：

int value=ByteBuf.readUnsignedShort()<<8+ByteBuf.readUnsignedByte();

依次类推，读5个字节，6个字节，7个字节，8个字节都可以这样先按上述的几个方法读取连续几位，再移位，再读取后面连续的几位，并相加。

如果想获取某个bit位是1还是0，可以用以下方法：

public static int getBitValue(long number, int index) {
      return (number & (1 << index)) > 0 ? 1 : 0;
}

也可以采用先移位，再&0x01。