关于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