关于byte[ ] & 0xFF的问题

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

private static String byte2Hex(byte[] bytes){
		StringBuffer stringBuffer = new StringBuffer();
		String temp = null;
		for (int i=0;i

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

你可能感兴趣的:(Java知识)