爲什麼byte變量要&0xFF

1.最近看到一些java加密的代碼，意外中發現如下一段代碼

 /**將二進制轉換成16進制 */
    public static String parseByte2HexStr(byte buf[]) {
        StringBuffer sb = new StringBuffer();
        for (int i = 0; i < buf.length; i++) {

            String hex = Integer.toHexString(buf[i] & 0xFF);
            if (hex.length() == 1) {
                hex = '0' + hex;
            }
            sb.append(hex.toUpperCase());
        }
        return sb.toString();
    }
   
    /**將16進制轉換爲二進制*/
    public static byte[] parseHexStr2Byte(String hexStr) {
        if (hexStr.length() < 1)
            return null;
        byte[] result = new byte[hexStr.length()/2];
        for (int i = 0;i< hexStr.length()/2; i++) {
            int temp = Integer.parseInt(hexStr.substring(i*2, i*2+2), 16);
            result[i] = (byte) (temp);
        }
        return result;
    }

parseByte2HexStr方法是將加密出來的密文（byte數組），或者數字簽名以16進制的方式顯示出來，但是其中一段位運算的代碼，讓人看上去很疑惑，String hex = Integer.toHexString(buf[i] & 0xFF);
就是爲什麼要循環將byte變量和0xff相與。byte是8位的變量,0xFF是，11111111，相與難道不是自己嗎？
原因是，toHexString方法接受的是一個整型參數，byte在會轉成int類型，如果byte是正數則沒問題，如果是負數，由於底層存的是補碼，高位會補1，這就和我們想保留低8位的初衷不符了，例如-127，
原碼：11111111 反碼：1000000 補碼10000001 轉成int 32位高位補1
11111111 11111111 11111111 10000001，這樣通過toHexString方法，得出的結果並非我們想要的，我們只需要低8位，所以將byte與上0xff，將前面的24爲置0，這樣就滿足我們的需求了。