[Why]java with 0xFF when byte converts int

Look at the following code before you dissect the problem
public static String bytes2hexstring (byte[] b) {
String ret = "";
for (int i = 0; i < b.length; i++) {
String hex = integer.tohexstring (b[i] & 0xFF);
if (hex.length () = = 1) {
Hex = ' 0 ' + hex;
}
RET + = Hex.touppercase ();
}
return ret;
}
Above is the byte[] conversion hex String, note here b[i] & 0xFF will be a byte and 0xFF with the operation, and then use integer.tohexstring to obtain a hexadecimal string, you can see
b[i] & 0xFF operation is still an int, then why and 0xFF to do with the operation? Direct integer.tohexstring (b[i]); Would you like to convert byte strong to int? The answer is No.

The reason for this is:
The size of 1.byte is 8bits and the size of int is 32bits
The 2.java binary is in complement form

================== The following text seems to have a problem ===================
First, we will review the basic theory of computer

Byte is a byte saved with 8 bits, which is 8 0, 1.
The first bit of a 8-bit is the sign bit,
Which means that 0000 0001 represents the number 1.
1000 0000 means-1.
So the positive maximum is 0111 1111, which is the number 127.
Negative numbers up to 1111 1111, that is, numbers-128

This is the binary source code, but in Java is used in the form of complement, the following describes what is the complement

1, anti-code:
If a number is positive, then its inverse code is the same as the original code;
If a number is negative, then the sign bit is 1, the rest of you are the original code to take the reverse;

2, Complement: Using overflow, we can change the subtraction into addition
For decimal numbers, 5 available subtraction is obtained from 9:
9-4=5 because 4+6=10, we can add 6 as a 4 complement.
Rewrite for addition:
9+6=15 (minus the high 1, which is 10) gets 5.

For hexadecimal numbers, the subtraction from C to 5 is available:
C-7=5 because 7+9=16 will be 9 as a complement of 7
Rewrite for addition:
C+9=15 (minus the high 1, which is 16) gets 5.

In the computer, if we use 1 bytes to represent a number, one byte has 8 bits, more than 8 bits go into 1, in memory the case is (100000000), carry 1 is discarded.

⑴ A number is positive, then its original code, anti-code, the same complement
⑵ a number is negative, just the sign bit is 1, the rest of you are the original code inversion, and then the entire number plus 1

-1 of the original code is 10000001
-1 of the anti-code is 11111110
+ 1
-1 of the complement is 11111111

0 of the original code is 00000000
0 of the anti-code is 11111111 (positive zero and negative zero of the same code)
+1
0 of the complement is 100000000 (drop the beginning of 1, positive zero and the same complement of negative zero)

The integer.tohexstring parameter is int, and if you do not &0xff, then when a byte is converted to int, because int is 32 bits, and byte is only 8 bits, then the complement is
For example, the decimal number of the complement 11111111 is 1 to int when converted to 11111111111111111111111111111111 many 1 ah, hehe! That is 0xFFFFFFFF but this number is wrong, and this complement will cause errors.
and 0xFF and after the high 24 bits will be cleared 0, the result is right.

----
A byte in Java, whose range is -128~127, and the integer.tohexstring parameter is int, and if it is not &0xff, then when a byte is converted to int, for negative numbers, a bit extension is done, for example, A byte-1 (or 0xff) will be converted to INT-1 (that is, 0xFFFFFFFF), then the result of conversion is not what we want.

And 0xFF is the default is shaping, so, a byte with 0xFF to join the first to convert that byte into a shaping operation, so that the result of the high 24 bits will always be cleared 0, so the result is always what we want.

Reprinted from Http://www.blogjava.net/orangelizq/archive/2008/07/20/216228.html

[Why]java with 0xFF when byte converts int