注意，我们这里举列的原码和反码只是为了求负数的补码，在计算机中没有原码，反码的存在，只有补码。
一.原码
1>.正数的原码就是它的本身
假设使用一个字节存储整数，整数10的原码是：0000 1010
2>.负数用最高位是1表示负数
假设使用一个字节存储整数，整数-10的原码是：1000 1010
二.反码
1>.正数的反码跟原码一样
假设使用一个字节存储整数，整数10的反码是：0000 1010
2>.负数的反码是负数的原码按位取反（0变1,1变0），符号位不变
假设使用一个字节存储整数，整数-10的反码是：1111 0101
三.补码（再次强调，整数的补码才是在计算机中的存储形式。）
1>.正数的补码和原码一样
假设使用一个字节存储整数，整数10的补码是：0000 1010（第三次强调：这一串是10这个整数在计算机中存储形式）
2>.负数的补码是负数的反码加1
假设使用一个字节存储整数，整数-10的补码是：1111 0110（第三次强调：这一串是-10这个整数在计算机中存储形式）
四.在计算机中，为什么不用原码和反码，而是用补码呢？
因为在使用原码，反码在计算时不准确，使用补码计算时才准确。
1>.使用原码计算10-10
0000 1010 （10的原码）
+ 1000 1010 （-10的原码）
------------------------------------------------------------
1001 0100 （结果为：-20，很显然按照原码计算答案是否定的。）
2>.使用反码计算10-10
0000 1010 （10的反码）
+ 1111 0101 （-10的反码）
------------------------------------------------------------
1111 1111 （计算的结果为反码，我们转换为原码的结果为：1000 0000，最终的结果为：-0，很显然按照反码计算答案也是否定的。）
3>.使用补码计算10-10
0000 1010 （10的补码）
+ 1111 0110 （-10的补码）
------------------------------------------------------------
1 0000 0000 （由于我们这里使用了的1个字节存储，因此只能存储8位，最高位（第九位）那个1没有地方存，就被丢弃了。因此，结果为：0）
五.小试牛刀
有了上面的案例，接下来，我们来做几个小练习吧，分别计算以下补码表示的十进制数字是多少呢？
1>.0b0000 1111
相信这个数字大家异口同声的就能说出它的答案是：15（因为正数的补码和原码一样）
2>.0b1111 1111
计算过程：0b1111 1111（补码）------>0b1111 1110（反码）------>0b1000 0001（原码）
将其换算成原码之后就可以得到最后的结果为：-1
3>.0b1111 0000
计算过程：0b1111 0000（补码）------>0b1110 1111（反码）------>0b(原码)
将其换算成原码之后就可以得到最后的结果为：-16
4>.0b1000 0001
计算过程：0b1000 0001（补码）------>0b1000 0000（反码）------->0b1111 1111（原码）
将其换算成原码之后就可以得到最后的结果为：-127
------------------------------------------------------------------------------------------------------------------------------------------
最近在tcp的基础上写一个自定义的协议，处理拆包粘包的时候发现一个情况
数据是以字节流的形式在tcp中传输，所以，大于一个字节的数据类型，都要转为byte[] 的形式
以int类型举例，在java中一个int类型的数据占4个字节，也就是需要new byte[4]
java中的数据类型都是有符号类型，也就是说区分正负的
一个字节=8bit，也就是说一个 byte 可以存放8个 0 或者 1
二进制的最高位为符号位，所以byte 的取值范围为-128~127，（-2^7~2^7-1）
在 Java 中，是采用补码来表示数据的。
正数的补码和原码相同，负数的补码是在原码的基础上各位取反然后加 1。
譬如：int a = -29 的二进制表示为
int 32字节，先取a的的绝对值求原码，29 的原码为00011101
不足4字节，高位补24个0
00000000000000000000000000011101
再求反码
通过上面的代码看，int 在tcp传输的时候要转换为byte[], int a = -29; 一共4个字节32位，于是byte[4] 每一个小标存储一个字节也就是8位，写到这里我们发现还是用不上&0xff，不要着急，接下来就用上了
于是，我们发现int 29 被装进 byte[] 的时候，成了这个样子：
下标0表示的是前8位，
下标1表示的是8-16位，
下标2表示的是16-24位，
下标3表示的是24-32位
也很容易理解，因为-1的补码就是 ，所以这4个byte的二进制组合起来就是int -29 的二进制
你把数据拆开了还要把它组合起来啊，也就是byte[] 转 int
分解问题就是单个byte 转 int
byte 八个bit位，int 32个bit位，byte为负数的时候，需要把高24位的全部置为0.保持低八位的一致性，不然得到的int就成了另一个数字
0xff 是16进制，也就是255 二进制也就是 1111 1111
补到32位也就是 这里是24个0 这里是八个1
一个负数的byte & 0xff的时候，高24位就成了0，保证了一致性
然而正数的补码还是它自己，不受影响，虽然只有负数的时候才需要 &0xff，但不至于再判断一次去吧？
版权声明：
本文来源网络，所有图片文章版权属于原作者，如有侵权，联系删除。
本文网址：https://www.bianchenghao6.com/java-jiao-cheng/11169.html