有趣的byte与0xff

原创已于 2022-12-26 17:11:54 修改 · 1.1k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#java #补码 #原码 #二进制 #十六进制

于 2022-12-06 17:18:39 首次发布

基础代码分析专栏专栏收录该内容

15 篇文章

订阅专栏

背景: 最近看到这样一段代码,字节数据转字符串，起初没有看懂，为啥Integer.toHexString(0xFF & bArray[i]) 这个方法里要写成0xFF & bArray[i]

这句代码的最终目的是把byte[]转换为16进制字符串，toHexString()是把一个int转换为十六进制String ，&0xFF是为了保证byte类型转int后其二进制的一致，即补零扩展...

 public String bytesToHexString(byte[] bArray) {
        StringBuffer sb = new StringBuffer(bArray.length);
        String sTemp;
        for (int i = 0; i < bArray.length; i++) {
            sTemp = Integer.toHexString(0xFF & bArray[i]);
            if (sTemp.length() < 2) {
                sb.append(0);
            }
            sb.append(sTemp.toUpperCase());
        }
        return sb.toString();
  }

看完这段解释，好像懂了又好像没懂，为啥要补零扩展？还有什么扩展呢？

一、了解基本概念原码、反码、补码

原码，就是符号位加上真值的绝对值, 即用第一位表示符号, 其余位表示值,正数的符号位为 0、负数的符号位为 1
反码，负数的反码是在其原码的基础上, 符号位不变，其余各个位取反，正数的反码是其本身
补码，负数的补码是在其原码的基础上, 符号位不变, 其余各位取反, 最后+1. (即在反码的基础上+1)，正数的补码就是其本身

反码是原码和补码相互转换时的临时过渡，用处不大

二、为什么计算机中要以补码形式存储数据？

在计算机系统中数值一律用补码的形式来表示和存储。原因是：使用补码时，可以将符号位和数值位统一处理；同时加法和减法也可以统一处理（CPU只有加法器）此外，补码与原码相互转换，其运算结果是相同的，不需要额外的硬件电路。其次存放补码可以保证计算的准确性。因为CPU只有加法，所以要将1-1转换成1+（-1）来计算。因为1是正数，所以1的反码补码都是其本身。以int类型数据为例子：

1的原/反/补码 0000 0000 0000 0000 0000 0000 0000 0001

-1的原码 1000 0000 0000 0000 0000 0000 0000 0001

-1的反码 1111 1111 1111 1111 1111 1111 1111 1110

-1的补码 1111 1111 1111 1111 1111 1111 1111 1111

将1的补码和-1的补码相加计算，

0000 0000 0000 0000 0000 0000 0000 0001

1111 1111 1111 1111 1111 1111 1111 1111

结果是

1 0000 0000 0000 0000 0000 0000 0000 0000

转换为int 类型，这时候你会发现最高位1其实丢了，因为int 类型占4个字节即32bit,所以0000 0000 0000 0000 0000 0000 0000 0000 再次转为原码还是0000 0000 0000 0000 0000 0000 0000 0000，即得到运算结果是十进制的0

三、补零扩展和补符号扩展

byte占8位，int占32位等。正因如此，当把一个低精度的数据类型转成一个高精度的数据类型时，必然会涉及到如何扩展位数的问题。这里有两种解决方案：

补零扩展：填充一定位数的0。
补符号位扩展：填充一定位数的符号位（非负数填充0，负数填充1）

举例说明，

-127的原码是 1111 1111 （注意1111 1111 表示无符号是就是255 ，有符号时就是-127 ，有符号时+127 是 0111 111）

-127的反码是 1000 0000

-127的补码是 1000 0001 计算机中存储的就是这个补码，

使用补零扩展得到结果是 0000 0000 0000 0000 0000 0000 1000 0001 正数的补码就是其本身，所以转换为10进制是129

使用补符号扩展得到的结果是 1111 1111 1111 1111 1111 1111 1000 0001

求这个补码的补码即原码 1000 0000 0000 0000 00000 0000 0111 1111所以转换为10进制是-127

由此可见对与-127，在计算机存储的是补码1000 0001，补零扩展后，为0000 0000 0000 0000 0000 0000 1000 0001，使用补零扩展能够保证二进制存储的一致性，但不能保证十进制值不变，补符号扩展，虽然得到的十进制值没有改变，但是二进制的值却变了，变成了1111 1111 1111 1111 1111 1111 1000 0001

四、我们到底想要什么？

情况一，我们需要十进制的一致性

public class Test{
    public static void main(String[] args) {
        Byte a=-127;
        int b=a;
        System.out.println(b);
    }
}
// 输出结果是-127

这是因为Java中只有有符号数，当byte扩展到short, int时，Java中的扩展方式是补符号位扩展

但是我做byte->int的转化所有时候都只是为了保持十进制的一致性吗？

不一定吧？好比我们拿到的文件流转成byte数组，难道我们关心的是byte数组的十进制的值是多少吗？我们关心的是其背后二进制存储的补码吧。所以大家应该能猜到为什么byte类型的数字要&0xff再赋值给int类型，其本质原因就是想保持二进制补码的一致性。