[TOC] > [參考](https://www.ruanyifeng.com/blog/2016/11/byte-order.html) ## 簡述 1. 網絡的數據是以大端數據模式進行交互 2. 主機大多數以小端模式處理，如果不轉換，數據會混亂 3. 兩個主機在網絡通信需要經過如下轉換過程：主機字節序 —> 網絡字節序 -> 主機字節序 ## 導讀 ### 二進制協議 基于文本類型的協議（比如 JSON）和二進制協議都是字節通信，他們不同點在于他們使用哪種類型的字節和如何組織這些字節。 文本協議只適用于 ASCII 或 Unicode 編碼可打印的字符通信。例如 "26" 使用 "2" 和 "6" 的 utf 編碼的字符串表示，這種方式方便我們讀，但對于計算機效率較低。 在二進制協議中，同樣數字 "26" 可使用一個字節**0x1A**十六進制表示，減少了一半的存儲空間且原始的字節格式能夠被計算機直接識別而不需解析。當一個數字足夠大的時候，性能優勢就會明顯體現 ## 小端序在計算機中優勢 使用小端序時不移動字節就能改變 number 占內存的大小而不需內存地址起始位。比如我想把四字節的 int32 類型的整型轉變為八字節的 int64 整型，只需在小端序末端加零即可。 ``` 44 33 22 11 44 33 22 11 00 00 00 00 ``` 上述擴展或縮小整型變量操作在編譯器層面非常有用，但在網絡協議層非也 ### 描述 數值`0x2211`使用兩個字節儲存：高位字節是`0x22`，低位字節是`0x11`,**并不是數值的大小** >**大端字節序**：高位字節在前，低位字節在后，這是人類讀寫數值的方法。 >**小端字節序**：低位字節在前，高位字節在后，即以`0x1122`形式儲存。 **"只有讀取的時候，才必須區分字節序，其他情況都不用考慮。"** ## 為什么會有小端字節序 計算機電路先處理低位字節，效率比較高，因為計算都是從低位開始的。所以，計算機的內部處理都是小端字節序。 但是，人類還是習慣讀寫大端字節序。所以，除了計算機的內部處理，其他的場合幾乎都是大端字節序，比如網絡傳輸和文件儲存 ## 舉例 ### 大端字節序處理 16位整數 **以此公式轉換** `x = buf[offset] * 256 + buf[offset+1];` `buf`是整個數據塊在內存中的起始地址，`offset`是當前正在讀取的位置。第一個字節乘以256，再加上第二個字節，就是大端字節序的值 **使用邏輯運算符表示** `x = buf[offset]<<8 | buf[offset+1];` 第一個字節左移8位（即后面添8個`0`），然后再與第二個字節進行或運算 ### 以小端字節處理 16位整數 `x = buf[offset+1] * 256 + buf[offset];` ### 32位整數 ``` /* 大端字節序 */ i = (data[3]<<0) | (data[2]<<8) | (data[1]<<16) | (data[0]<<24); /* 小端字節序 */ i = (data[0]<<0) | (data[1]<<8) | (data[2]<<16) | (data[3]<<24); ``` ## go 實現 小端序,大端序 ``` a :=int32(65535) b :=int32(65535) buf :=new(bytes.Buffer) binary.Write(buf,binary.LittleEndian,a) fmt.Printf("%+v\n", buf.Bytes()) // [255 255 0 0] buf2 :=new(bytes.Buffer) binary.Write(buf2,binary.BigEndian,b) fmt.Printf("%+v\n", buf2.Bytes()) // [0 0 255 255] ```