Why is byte with 0xFF (turn)

Inadvertently looking over the code, found a difficult to understand the code.

     byte[] bs = digest.digest (Origin.getbytes (Charset.forname (CharsetName)));                    for (int i = 0; i < bs.length; i++) {              int c = bs[i] & 0xFF;            if (c < +) {                 sb.append ("0");              }              Sb.append (Integer.tohexstring (c));          return sb.tostring ();  

BS is a byte array that is output after a string of MD5 is encrypted. It's hard for me to understand at first why I want to copy the bs[i]&oxff to the int type in the next loop.

Bs[i] is 8-bit binary, 0xFF into 8-bit binary is 11111111, then Bs[i]&0xff is not or bs[i] itself? Is it interesting?

And then I wrote a demo.

Package Jvmproject;public class Test {public    static void Main (string[] args) {        byte[] a = new byte[10];        a[0]= -127;        System.out.println (A[0]);        int c = a[0]&0xff;        System.out.println (c);    }}

I first print a[0], after printing the A[0]&0xff value, originally I think the result should be-127.

But the results are really unexpected!

-127

129

What is it for? &0xff was wrong.

The landlord really does not understand Ah, and then to the complement that direction to think.

Remember that when learning computer principles, it is understood that the storage in the computer is stored using the twos complement.

Review the three concepts of the original code anti-code complement

For positive numbers (00000001), the first sign is the symbol bit, and the anti-code complement is itself

For negative numbers (100000001) The original code, the inverse code is the original code in addition to the symbol bit to take the inverse operation that is (111111110), the complement is the inverse code for +1 operations namely (111111111)

The concept is so simple.

When assigning 127 to a[0], a[0] as a byte type, its computer is stored with a complement of 10000001 (8 bits).

When you output A[0] as an int type to the console, the JVM makes a bitwise of the processing because the int type is 32 bits so the complement is 1111111111111111111111111 10000001 (32 bits). This 32-bit twos complement represents also-127.

Found no, although the binary complement stored behind the Byte->int computer was converted from 10000001 (8-bit) to 1111111111111111111111111 10000001 (32-bit) it is clear that the decimal digits of the two complement representations are still the same.

But I do byte->int conversions all the time just to keep the decimal consistency?

Not necessarily, huh? Like the files we get into a byte array, do we care what the decimal value of the byte array is? What we care about is the complement of binary storage behind it.

So you should be able to guess why the number of a byte type is &0xff and then assigned to the int type, the essential reason is to maintain the consistency of the twos complement.

When byte is to be converted to int, the high 24 bits are bound to be 1, so that the second complement is in fact inconsistent, and the &0XFF can set the high 24 bits to 0 and the low 8 bits to remain the same. This is done to ensure the consistency of the binary data.

Of course, the binary data is guaranteed, and if the binary is interpreted as byte and int, the value of the 10 binary must be different because the position of the symbol bit has changed.

As in Example 2, int c = a[0]&0xff; a[0]&0xff=1111111111111111111111111 10000001&11111111=000000000000000000000000 10000001, this value is 129,

So the output value of C is 129. Some people ask why the above equation A[0] is not 8 bits but 32 bits, because when the system detects that a byte may be converted to int, or that a byte is converted to an int after some operation, it expands the byte's memory space high 1 to 32 bits, and then participates in the operation.

In fact, when extending from a number type to a wider type, the 0 extension is a complement to the symbol bit extension.
This is because there are only signed numbers in Java, and when a byte is extended to short, int, that is, the positive number is the same, because the sign bit is 0, so anyway it is the 0 extension, but the negative complement 0 extension and the sign bit extension result are completely different.
Fill the number of symbols, the original value is unchanged.
Fill zero, equivalent to the signed number as unsigned number, such as -127 = 0x81, as unsigned number is 129, 256 + (-127)
For signed numbers, when you are growing from a small scale, you need to use &0XFF to ensure that you are expanding by 0.
From the large to small processing, the sign bit automatically invalid, so no processing.

Let me understand deeper, that is, when the byte expands to int, the automatic transformation is the sign bit extension, this way can guarantee that the decimal value will not change, and &0xff is 0 extension, this will ensure the consistency of binary storage, but the decimal value has changed. That is, by the symbol bit extension can guarantee that the decimal value is unchanged, the complement 0 extension can guarantee that the binary storage will not change. The positive number can be said to be both the symbol bit expansion, but also the complement 0 extension, so in both binary storage and decimal values can be guaranteed consistent.

Http://www.cnblogs.com/think-in-java/p/5527389.html

Why is byte with 0xFF (turn)