在写大作业的时候，一开始对 &0xff 的操作一直处于疑惑状态.。

byte[i] 是8位二进制，0xff 转化成8位二进制就是 11111111，那么byte[i] & 0xff不是还是byte[i]本身吗？

Are you kidding me？

对于这个问题，我在网上看到一个demo很有趣：

#include

int main(void)

{

char byte = -127;

int a;

a = byte;

printf("%d\n", a);

a = byte & 0xff;

printf("%d", a);

return 0;

}

然而~

事情开始有趣了起来…

为什么加了 &0xff 反而不对了呢??

我们先来复习一下补数的概念:

对于正数(00000001)原码来说,首位表示符号位,反码与补码都是本身

对于负数(100000001)原码来说，反码是对原码除了符号位之外作取反运算即(111111110)然后作+1运算即(111111111)

再介绍一下符号扩充的概念：

以8位二进制数为例，符号扩充就是指在保持当前值不变的前提下将其转化为16位和32位的二进制数。规则就是，不管是正数还是用补码表示的负数，都只需要用符号位的值(0或1)来填充高位即可。

进入正题:

当将-127赋值给byte的时候，byte作为一个char类型，其计算机存储的补码是10000001(8位)[在计算机中，负数都是以补码形式储存]。

a = byte;//-127

第一次将 byte 作为int类型向控制台输出的时候，编译器作了一个符号扩充的处理，因为int类型是32位二进制数，所以byte扩充后的补码就是1111111111111111111111111 10000001(32位)，这个32位二进制补码表示的十进制数也是-127.这说明符号扩充并不会影响当前对应的十进制数的值。

这是一个很好的性质，但是我们将char类型进行int类型的转化的时候，目的并不仅仅是要保证对应十进制数的不变性。比如说我们这次的大作业，是要将4个char类型转化成1个int类型，这就需要保证二进制补码的一致性，也就是4个char类型所对应的二进制01序列原封不动地作为一个int类型的4个字节(高八位 中八位 中八位 低八位)的二进制序列。

a = byte & 0xff;//129

那我们第二次进行赋值的时候为什么会改变a的值呢？

我们来具体分析一下:

之前介绍了符号扩充的概念，当byte(10000001)要转化为int的时候，高的24位必然会补1。这样，其二进制补码其实就已经改变了。而&0xff(11111111)可以将byte变int时，高的24位设置为0，低8位保持byte的原样。

那可能会有同学疑惑：为什么0xff 高的24位不会同样补1呢？这是因为 0xff或者0xFF本身就是一个int的字面常量，自身就是32位长的，所以不会进行符号扩充。

当然，在我想保证二进制补码一致性的时候，二进制数所对应十进制数自然也就发生变化啦。这是无法兼得滴~

来看看代码的具体实现：

a = byte & 0xff;//129

byte & 0xff = 111111111111111111111111110000001&11111111

=000000000000000000000000 10000001

这个二进制数位权加一下就是129啦

这很好的解释了为什么加了 &0xff 结果反而出错了：

因为这个时候的程序保证了二进制补码的一致性而不是对应十进制数的一致性。

最后

咱们回到刚开始大作业转换算法的问题。我们是想保证二进制补码的一致性，所以要先对byte进行 &0xff 操作。当然假如byte的符号位位0 ，那么 &0xff 就没有什么意义。但是当byte的符号位为1的时候，你就需要掂量一下了，因为你最后是要和 value进行 逻辑或 操作的(很大概率你辛辛苦苦获得的二进制序列可就全部变成1了哦)！！