传输的对象单位 -- 字节流 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。
