分享乙個位元組序方面的知識

在專案中進行通訊時遇到這樣的問題,對於包的長度和型別在傳輸中商定為大端(網路位元組序),但是在轉換後讀取到的資料顯示出來卻是小端(主機位元組序)的資料。下面將具體的過程進行描述,便於大家能對資料在記憶體中的分布情況，資料讀取，大端小端等方面的問題能夠一目了然。

包型別typedef struct task;

環境是windows，intel處理器，所以資料在記憶體的分布預設是小端的。

開始的時候我們在會對packet_len和packet_type進行htons將其轉換為網路位元組序(也就是大端)，然後將其用於網路傳輸

在解析到的時候我們獲取到的資料顯示出來是小端的，在查詢原因後發現,在我們自己的庫函式write_int和read_int中在寫入和讀取到的資料會改變位元組序的問題,其實帶有了ntohs和htons的功能。

具體行為如下：

packet_len = 15

16進製表示是0x000f，在記憶體中的表示是0f 00,這是由於小端的緣故會是低位在前.

而要將其從主機位元組序改變為網路位元組序,我們可以使用htons，在呼叫後big=htons(packet_len)

big的十六進製制表示是0x0f00，在記憶體中的表示是00 0f

在我們轉換為網路位元組序和一些列資料獲取後需要寫入到buffer中,通過傳送和接受該buffer來進行協議控制

寫入到buffer中我們使用了write_int，該函式的功能是將資料按位元組依次寫入到buffer

那麼packet_len在轉換為網路位元組序後在寫入buffer,取前兩個位元組分析(packet_len)

第乙個位元組是：0x0f

第二個位元組是: 0x00

那麼在這個時候我們就可以看到，我們實際傳輸的packet_len在儲存到buffer中已經變成了0x0f00,那麼根據小端機器低位在前,讀取的資料就是0x000f這個資料實際還是小端的資料，由此我們取消了對packet_len和packet_type呼叫htons

附:write_int函式

template

t write_int(int cb/*要寫入buffer的長度*/, t w0/*指向buffer的指標*/, long long v/*要寫入的資料*/)

return reinterpret_cast(w + cb);

}