1. 程式人生 > >&0xff的原因

&0xff的原因

1. 只是為了取得低八位

例如:java socket通訊中基於長度的成幀方法中,如果傳送的資訊長度小於65535位元組,長度資訊的位元組

定義為兩個位元組長度。這時候將兩個位元組長的長度資訊,以Big-Endian的方式寫到記憶體中

	        out.write((message.length>>8)&0xff);//取高八位寫入地址
		out.write(message.length&0xff);//取低八位寫入高地址中
例如,有個數字 0x1234,如果只想將低8位寫入到記憶體中  0x1234&0xff

0x1234 表示為二進位制  0001001000110100

0xff       表示為二進位制  11111111

兩個數做與操作,顯然將0xff補充到16位,就是高位補0

此時0xff 為 0000000011111111

與操作  1&0 =0 1&1 =1 這樣 0x1234只能保留低八位的數 0000000000110100 也就是 0x34

2. 保證補碼的一致性

public static void main(String[] args) {
		byte b = -127;//10000001
		int a =  b&0xff;
		System.out.println(a);
	}

咋一看,b是8位的二進位制數,在與上0xff(也就是 11111111),不就是其本身嗎,輸出在控制檯結果卻是129

首先計算機內的儲存都是按照補碼儲存的,-127補碼錶示為 1000 0001

在經過這步  int a = b&0xff;將byte 型別提升為int時候,b的補碼提升為 32位,補碼的高位補1,也就是

1111 1111 1111 1111 1111 1111 1000 0001

負數的補碼轉為原碼,符號位不變,其他位取反,在加1,正數的補碼,反碼都是本身

結果是 1000 0000 0000 0000 0000 0000 0111 1111表示為十進位制 也是 -127

也就是 當 byte -> int  能保證十進位制數不變,但是有些時候比如檔案流轉為byte陣列時候,

我們不是關心的是十進位制數有沒有變,而是補碼有沒有變,這時候需要&上0xff

本例子中,將byte轉為int 高24位必將補1,此時補碼顯然發生變化,在與上0xff,將高24重新置0,

這樣能保證補碼的一致性,當然由於符號位發生變化,表示的十進位制數就會變了

1111 1111 1111 1111 1111 1111 1000 0001 

&

0000 0000 0000 0000 0000 0000 1111 1111

結果是

0000 0000 0000 0000 0000 0000 1000 0001

和原來的補碼 一致,但是顯然符號位變化了,表示的十進位制數發生變化,變為129

結論:

java中基本型別從小擴充套件到大的資料型別時候,是按照補零擴充套件還是補符號位擴充套件

正數因為符號位是0,無論如何都是補零擴充套件,但是負數補零擴充套件和補符號位擴充套件完全不同,

補符號位擴充套件,保證十進位制數不變

例如 byte>>>int  -127自動按照補符號位擴充套件,在高24位補符號位1,表示的十進位制數不變

補零擴充套件,保證補碼的一致性,但是表示的十進位制發生變化

例如,本例中byte提升為int,&0xff的操作

參考文章:http://www.cnblogs.com/think-in-java/p/5527389.html