Java byte转int时为什么要与0xff进行与运算?_java 单字节超过ff 补码-优快云博客

本文链接：https://blog.youkuaiyun.com/qiruiduni/article/details/82381208

本文通过一个MD5加密的实例，详细解释了在Java中处理byte到int类型转换时，为何要与0xFF进行与运算。文章深入探讨了计算机存储机制、原码、反码及补码的概念，并说明了该操作如何确保与二进制补码表示的一致性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

先来看个栗子：

 byte[] bs = digest.digest(origin.getBytes(Charset.forName(charsetName))) ;  
          
 for (int i = 0; i < bs.length; i++) {  
     int c = bs[i] & 0xFF ;
     if(c < 16){ 
          sb.append("0");  
     }  
     sb.append(Integer.toHexString(c)) ;  
 }  
 return sb.toString() ;

bs是由一段字符串经过MD5加密后输出的byte数组。在for循环里，bs[i]是一个8位二进制，而0xFF的二进制为11111111，那么bs[i]与0xFF进行与运算，得到仍为bs[i]，不是多此一举吗，为什么要这样做呢？

在搞清楚之前，需要理解计算机存储机制以及原码、反码、补码的概念：

在学计算机原理时，知道计算机内部的存储都是利用二进制的补码进行存储的，如果用1个字节表示一个数字，一个字节有8位，超过8位就进1，在内存中的情况为：100000000，进位1被丢掉。

来回顾下反码、补码的概念：

反码

对于正数，反码和原码相同；

对于负数：反码是除符号位1之外的都取反。

补码：就是对反码加1

比如：

-1 的原码：10000001

-1 的反码：11111110

-1 的补码：11111111

0 的原码：00000000

0 的反码：11111111（正零和负零的反码相同）

0 的补码：100000000 （1丢掉，正零和负零的补码相同）

-----------------------------------------------------------------------------------

由上述可知，byte a = -127（原码：11111111）在内存中会以其补码（10000001）的形式存储，在做byte -> int类型转换时，JVM会做一个补位处理，由于int类型为32位，所以补位后的补码为：11111111 11111111 11111111 10000001（32位），这个32位二进制补码也是-127。（注：补位是补1还是补0，取决于byte的最高位是1还是0）

我们发现，在byte -> int转换时，计算机存储的补码和JVM补位后的补码表示的十进制数字仍然是相同的。

所以，在byte类型转为int类型时，为什么要和0xFF（原码：11111111）做与运算？其本质原因是要和二进制补码保持一致。当byte转int时，高24位必然会补1，这时与其二进制补码已经不一样了，补位后的补码与0xFF 做与运算，可以将高24位置为0，低8位保持不变，这样做就可以保证和二进制补码的一致了。