無意間翻看之間的代碼，發現了一段難以理解的代碼。

     byte[] bs = digest.digest(origin.getBytes(Charset.forName(charsetName))) ;  
          
        for (int i = 0; i < bs.length; i++) {  
            int c = bs[i] & 0xFF ;
            if(c < 16){ 
                sb.append("0");  
            }  
            sb.append(Integer.toHexString(c)) ;  
        }  
        return sb.toString() ;  

bs是由一段字符串經過MD5加密後，輸出的byte數組。我起初難以理解為什麽在接下來的循環中要將bs[i]&oxFF再復制給int類型呢？

bs[i]是8位二進制，0xFF轉化成8位二進制就是11111111，那麽bs[i]&0xFF不是還是bs[i]本身嗎？有意思嗎？

後來我又寫了一個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);
    }
}

我先打印a[0],在打印a[0]&0xff後的值，本來我想結果應該都是-127.

但是結果真的是出人意料啊！

-127

129

到底是為什麽呢？&0xff反而不對了。

樓主真的是不懂啊，後來往補碼那個方向想了想。

記得在學計算機原理的時候，了解到計算機內的存儲都是利用二進制的補碼進行存儲的。

復習一下，原碼反碼補碼這三個概念

對於正數（00000001）原碼來說，首位表示符號位，反碼 補碼都是本身

對於負數（100000001）原碼來說，反碼是對原碼除了符號位之外作取反運算即（111111110），補碼是對反碼作+1運算即（111111111）

概念就這麽簡單。

當將-127賦值給a[0]時候，a[0]作為一個byte類型，其計算機存儲的補碼是10000001（8位）。

將a[0] 作為int類型向控制臺輸出的時候，jvm作了一個補位的處理，因為int類型是32位所以補位後的補碼就是1111111111111111111111111 10000001（32位），這個32位二進制補碼表示的也是-127.

發現沒有，雖然byte->int計算機背後存儲的二進制補碼由10000001（8位）轉化成了1111111111111111111111111 10000001（32位）很顯然這兩個補碼表示的十進制數字依然是相同的。

但是我做byte->int的轉化 所有時候都只是為了保持 十進制的一致性嗎？

不一定吧？好比我們拿到的文件流轉成byte數組，難道我們關心的是byte數組的十進制的值是多少嗎？我們關心的是其背後二進制存儲的補碼吧

所以大家應該能猜到為什麽byte類型的數字要&0xff再賦值給int類型，其本質原因就是想保持二進制補碼的一致性。

當byte要轉化為int的時候，高的24位必然會補1，這樣，其二進制補碼其實已經不一致了，&0xff可以將高的24位置為0，低8位保持原樣。這樣做的目的就是為了保證二進制數據的一致性。

當然拉，保證了二進制數據性的同時，如果二進制被當作byte和int來解讀，其10進制的值必然是不同的，因為符號位位置已經發生了變化。

象例2中，int c = a[0]&0xff; a[0]&0xff=1111111111111111111111111 10000001&11111111=000000000000000000000000 10000001 ，這個值算一下就是129，

所以c的輸出的值就是129。有人問為什麽上面的式子中a[0]不是8位而是32位，因為當系統檢測到byte可能會轉化成int或者說byte與int類型進行運算的時候，就會將byte的內存空間高位補1（也就是按符號位補位）擴充到32位，再參與運算。上面的0xff其實是int類型的字面量值，所以可以說byte與int進行運算。

（原文地址：http://www.cnblogs.com/think-in-java/p/5527389.html）

[轉]byte為什麽要與上0xFF？