java中程式碼 &0xFF是怎麼個意思
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進行運算。