之前我們整理了大端和小端 和 字元編碼 ，知道對於多位元組的資料會存在不同機器之間的儲存問題。對於整形我們知道可以通過網路位元組序進行傳輸，但是對於不同編碼的字串我們該怎麼辦呢？
其實字串就是一連串的記憶體資料，而記憶體資料我們可以看成乙個陣列，對於傳送就是把陣列中的資料按個傳送，傳送過程並不會影響資料。但是不同機器之前對資料的解釋有可能不一致。而bom就是對資料怎麼解釋的乙個標記。
bom（byte-order mark），即位元組順序標記，它是插入到以utf-8、utf16或utf-32編碼的資料開頭的特殊標記，用來識別資料的編碼型別。
對於utf-8來說，bom並不是必須的，因為bom用來標記多位元組編碼的編碼型別和位元組順序（big-endian或little-endian），utf-8中有的字元是單位元組，所以沒有順序而言。
在編碼表中定義乙個字元u+feff，它並沒有實際對應的符號。字元u+feff如果出現在位元組流的開頭，則用來標識該位元組流的位元組序，是高位在前還是低位在前。
在絕大多數編輯器中都看不到bom字元，因為它們能理解unicode，去掉了讀取器看不到的題頭資訊。若要檢視某個unicode檔案是否以bom開頭，可以使用十六進製制編輯器。但對於 php來說，bom是個**煩。php並不會忽略bom，所以在讀取、包含或者引用這些檔案時，會把bom作為該檔案開頭正文的一部分。
圖中的含義為：
utf-8編碼的資料，資料開頭會以0xef bb bf開頭
utf-16編碼的以大端模式儲存的資料，會以0xfe ff開頭
utf-16編碼的以小端模式儲存的資料，會以0xff fe開頭
為了識別 unicode 檔案，microsoft 建議所有的 unicode 檔案應該以u+feff字元開頭。這作為乙個「特徵符」或「位元組順序標記（byte-order mark，bom）」來識別檔案中使用的編碼和位元組順序。
linux/unix 並沒有使用 bom，因為它會破壞現有的 ascii 檔案的語法約定。
不同的編輯工具對bom的處理也各不相同。使用windows自帶的記事本將檔案儲存為utf-8編碼的時候，記事本會自動在檔案開頭插入bom（雖然bom對utf-8來說並不是必須的），但是editplus就不會這樣做。
感謝大家，我是假裝很努力的youngyangd（小羊）
參考資料：
位元組序 byte order
我們在做網路相關的程式設計時，經常會遇到網路位元組序和主機位元組序的問題 當我們要把資料傳送到網路中進行傳輸時，需要把資料先轉換為網路位元組序再傳送 當我們從網路中接收到資料後，需要先轉換為主機位元組序才能使用。位元組序是計算機體系結構的乙個基本屬性，每台計算機都是按照自己的位元組序方式處理資料的。...
位元組順序標記BOM
最近，從numbers匯出的csv檔案，匯入excel後，出現中文亂碼問題。網上查詢後，發現是numbers匯出的csv預設是utf 8無bom的，使用sublimtext3開啟，另存為utf 8withbom格式，再使用excel開啟，就可以正常識別中文。那麼，今天就來回顧一下bom吧 big e...
位元組順序 網路位元組順序
位元組順序 位元組順序是指佔記憶體多於乙個位元組型別的資料在記憶體中的存放順序，通常有小端 大端 兩種位元組順序。小端位元組序 指低位元組資料存放在記憶體低位址處，高位元組資料存放在記憶體高位址處 大端 位元組序是高位元組資料存放在低位址處，低位元組資料存放在高位址處。記憶體位址增長是從低位址到高位...