关于byte[ ] & 0xFF的问题

最新推荐文章于 2025-07-17 08:48:02 发布

梅肉果冻

最新推荐文章于 2025-07-17 08:48:02 发布

阅读量2.9k

点赞数 3

CC 4.0 BY-SA版权

分类专栏： Java知识

本文链接：https://blog.youkuaiyun.com/u014691866/article/details/82431582

Java知识专栏收录该内容

20 篇文章

订阅专栏

本文深入探讨了在Java中byte类型数据如何通过按位与操作转换为int类型，并解释了为何需要使用0xFF来确保数据一致性，同时给出了具体的代码示例。

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

最近在写有关SHA256加密解密的问题，发现有一段代码是这样的，处于好奇理解了一下。

private static String byte2Hex(byte[] bytes){
		StringBuffer stringBuffer = new StringBuffer();
		String temp = null;
		for (int i=0;i<bytes.length;i++){
			temp = Integer.toHexString(bytes[i] & 0xFF);
			if (temp.length()==1){
				//1得到一位的进行补0操作
				stringBuffer.append("0");
			}
			stringBuffer.append(temp);
		}
		return stringBuffer.toString();
	}

Integer类中toHexString方法的参数是int类型，为什么byte[ ] & 0xFF可以表示int类型呢？

byte[i]是8位二进制，0xFF转化为8位二进制为11111111，& 之后的结果还是本身啊，这是怎么回事？

我们都知道计算机内的存储都是利用二进制的补码进行存储的。

复习一下，原码反码补码这三个概念

对于一个字节的最高位，计算机中是有规定的，正数的最高位为0，负数的最高位为1。

对于正数（00000001）原码来说，首位表示符号位，反码补码都是本身

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

下面写段代码测试下

public static void main(String[] args) {
		byte[] a=new byte[10];
		a[0]=-127;
		System.out.println("a[0]:"+a[0]);
		int b=a[0] & 0xFF;
		System.out.println("b:"+b);
	}

得到的结果为：

a[0]:-127
b:129

现在针对这个结果进行分析：

byte类型的a[0]的值为-127，在计算机中存储的补码为：10000001，这个补码是8位的，而int类型是32位的，所以a[0]作为int类型来输出的时候jvm给做了个补位便成了 111111111111111111111111 10000001（-127），虽然补码转换了，但是这两个补码表示的十进制数字是相同的。
为了

为了保证二进制数据的一致性，当byte要转化为int的时候，高的24位必然会补1，这样，其二进制补码其实已经不一致了，如果二进制被当作byte和int来解读，其10进制的值必然是不同的，因为符号位位置已经发生了变化，而&0xFF可以将高的24位置为0，低8位保持原样。

int b = a[0]&0xff; a[0]&0xff=1111111111111111111111111 10000001&11111111=000000000000000000000000 10000001 ，这个值就是129

所以最后显示的b的值为129