在32位的電腦中數字都是以32格式存放的，如果是要求一個byte(8位)型別的數字，對於int這種32位的整形，高24位具有隨機性(從所有的數字形式來看，前面的24位取值並不確定，我把它視為具有一定的隨機性，比如int型的整數，高24位的取值都是不確定的。)，低8位

才是實際的資料。

java.lang.Integer.toHexString() 方法的引數是int(32位)型別，如果輸入一個byte(8位)型別的數字，這個

方法會把這個數字的高24為也看作有效位，這就必然導致錯誤，使用& 0XFF操作，可以把高24位置0以避免這樣錯誤

的發生。

這裡讓我想到的是MD5實現的演算法的時候有一段

1. publicstatic String md5Encode(String inputStr) {  
2.         MessageDigest md5 = null;  
3.         try {  
4.             md5 = MessageDigest.getInstance("MD5");  
5.             byte[] bytes = inputStr.getBytes("UTF-8");  
6.             byte[] md5Bytes = md5.digest(bytes);  
7.             StringBuffer hexValue = new
    StringBuffer();  
8.             for (int i = 0; i < md5Bytes.length; i++) {  
9.                 int value = ((int) md5Bytes[i]) & 0xff;  
10.                 if (value < 16) {  
11.                     hexValue.append("0");  
12.                 }  
13.                 hexValue.append(Integer.toHexString(value));  
14.             }  
15.             return hexValue.toString();  
16.         } catch (Exception e) {  
17.             return"";  
18.         }  
19.     }  

那麼這裡之所以轉為整形無非是整形的包裝類中有Integer.toHexString()這個將其轉為16進位制的方法，如果Byte中有的話，估計這裡是不會轉為整形的。如果結果小於十六的時候，要再前面加上一個0填滿兩位的十六進位制。