Another analysis is as follows:
Why is byte related to 0xFF?
Look at the following code before you dissect the problem
Public Static String bytes2hexstring (byte[] b) { = ""; for (int i = 0; i < b.length; i++) { = integer.tohexstring (b[i] & 0xFF); if (hex.length () = = 1) {= ' 0 ' + hex; } + = 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 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
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.
Why byte is converted to int with 0xFF in Java
