如果写过通信类的代码，比如socket编程，应该对这个问题不陌生。
byte & 0xff 是将byte从（-128 至 127）转化成 int（转化后的数值范围： 0 至 255）。
其实就是1个byte有两种表示方法，我们既可以用-128 - 127这段范围来表示一个字节，也可以用 0 - 255这个范围的数来表示一个字节。
用Java中的InetAddress类来获取我当前的ip
public class InetAddressTest {
public static void main(String[] args) throws UnknownHostException {
InetAddress localHost = InetAddress.getLocalHost();
byte[] address = localHost.getAddress();
for (byte b : address) {
System.out.print(b + " ");
}
}
}
输出结果
-64 -88 2 119
本机ip
好像不太一样，我们ip地址只用 0 - 255来表示，不会出现负数。
所以再换一种写法，将取出来的字节 & 0xff
public class InetAddressTest {
public static void main(String[] args) throws UnknownHostException {
InetAddress localHost = InetAddress.getLocalHost();
byte[] address = localHost.getAddress();
for (byte b : address) {
System.out.print( ( b & 0xff ) + " ");
}
}
}
结果
192 168 2 119
Process finished with exit code 0
果然就是我们想要的结果
因为Java中的byte是有符号的，他的范围只能是 -128 - 127。
我们在使用tcp等协议的时候，首先要把传输的消息转化成字节流，然后再传输，在编程语言中字节流通常用十进制的byte数组来表示。
假如我们就想用 0-255来表示一个字节，不想用负数，该怎么办呢？
可惜Java中没有 无符号字节（unsigned byte）， 我们只能用 int 来存储0-255。
而int的范围是（-2^31 ~ 2^31-1），只用了256个，剩下的空间都被浪费了，得不偿失啊。
所以我们存储的时候、传输的时候可以用byte，但是使用的时候就需要做一个转换了，那为什么0xff就可以得到无符号byte呢。
& 0xff的作用
作为一个十六进制数，0xff在Java中是用什么类型存储的呢？
应该显而易见吧，0xff是整型。
假设我现在要转化 字节 -1
-1的原码、反码、补码分别如下：
原码 1 0 0 0 0 0 0 1 反码 0 1 1 1 1 1 1 0 补码 0 1 1 1 1 1 1 1
现在和 0xff做运算， ff 就是（1111 11111），而因为他是整型，占4个字节，32为，所以0Xff的前面还有24个0。
用 -1 的补码进行计算
-1 0 1 1 1 1 1 1 1 0xff 000000000 000000000 000000000 1 1 1 1 1 1 1 1 = 000000000 000000000 000000000 0 1 1 1 1 1 1 1 = 255
其实在Java中，”任何数 & 0Xff等于那个数本身“ 这句话就显得不那么正确了
”任意整型 & 0xff = 本身“ 是没有问题的
但是字节 & 0xff 就被拖到了另一个次元，从byte进化成了int。
最近在写有关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
以上为个人经验，希望能给大家一个参考，也希望大家多多支持。
