最近在看node原始碼的時候，偶然間，看到如下函式：
/**
* remove byte order marker. this catches ef bb bf (the utf-8 bom)
* because the buffer-to-string conversion in `fs.readfilesync()`
* translates it to feff, the utf-16 bom.
*/function stripbom(content)
return content;
}
對於bom ，相信大多數人對其即陌生又熟悉，我們在各大ide中常常見到它的身影，但要真的把它解釋清除，卻有點力不從心。故此，筆者利用閒暇之餘搜尋資料整理成文，如果錯漏，還望提點！
在解釋bom之前，我們不得不提到位元組序。
在古時，我們的很多書刊保有從左到右的排版的習慣。即使是今天，某些國家的文字讀序依舊存在差異。計算機世界也是如此。
我們把多位元組排練的順序叫做位元組序。
這裡我們通過乙個例子展開說明（本例來自：「位元組序」是個什麼鬼？）：
給定兩個分別需要4個位元組儲存的整數，為了方便說明，使用16進製表示這兩個數，即0x12345678和0x11223344。對於如何儲存，有人提了兩個方案：
方案一：
方案二：
對於方案一，高位位元組在儲存在高位位址，低位位元組在低位位址，我們稱之為大端（big endian）位元組序。方案二把低位位元組在前，高位位元組在後，我們把這種順序叫做小端（little endian）位元組序。
對於人類而言，位元組序也許並不是問題。比如從右往左讀"位元組序"，聰明如你們，會發現「序節字」根本語義不通，可以輕鬆的找到解決之道。但對於計算機而言，它不明白什麼是語義，也沒法聯絡上下文。它只能按照給定的指令去讀取位元組。如果是大端位元組序，先讀到的就是高位位元組，後讀到的就是低位位元組。小端位元組序正好相反。
所以對於計算機而言，我們需要一種方法去標識位元組序，以防亂碼的出現。bom就是一種用於標識的unicode字元，它常被用來當做標示以utf-8、utf-16或utf-32為編碼的檔案
對於utf-16和utf-32而言，因為他們分別使用2個位元組和4個位元組編碼unicode字元，對於多位元組編碼，bom的存在顯然很有必要。此時bom被放置為檔案或字串流的第乙個字元，如果識別符號為u+fffe則表示大端位元組序，如果識別符號為u+feff則表示小端位元組序。
那既然bom是用於標示位元組序的，那為什麼還要把它刪除呢？這裡就不得不提一下utf-8了。
utf-8是一種可變位元組長度的編碼方式（最小1位元組，最大4位元組），也就是說utf-8可以根據資料大小來決定要儲存的位元組數。它的編碼方式與其他兩者不同，無需使用bom。
utf-8在首位元組標識了位元組的個數。如果首位元組以0開頭，則代表單位元組編碼，如果以110開頭者表示該位元組為兩個位元組中的第乙個位元組，以此類推。除了單位元組外，多位元組utf-8碼的後續位元組均以10開頭。
所以1～4位元組utf-8編碼看起來是這樣的：
0******x
110***xx 10******
1110***x 10****** 10******
11110*** 10****** 10****** 10******
```
「位元組序」是個什麼鬼？
為什麼utf-8沒有位元組序問題？
unicode字符集與utf-8編碼
位元組順序標記
LQ系列 雜談 聊一聊演算法
今天由於藍橋杯系統維護，所以停止更新一天 今天想聊聊為什麼學演算法？演算法有什麼用？知乎上看到 作為計算機專業學生最應該學習的課程top5 計算機組成原理 數字邏輯電路 線性代數 概率論 離散數學 演算法 作業系統 編譯原理 掌握一門程式語言和程式設計技術 不知大家怎麼看演算法？曾經我身邊的朋友們說...
聊一聊系列 聊一聊移動web解析度的那些事兒
不同於pc時代，移動web的樣式更加多樣，也由於手機解析度的碎片化，移動web的相容問題日益突出，下面，我就和各位讀者一起聊聊移動web所面臨的手機解析度問題。在pc時代，我們書寫css的時候，理所應當的認為，我們所書寫的1px，在螢幕上就是1px的寬度。但是到了移動端，事情就不是這樣了，我們所書寫...
聊一聊小甜餅
cookies程式設計 cookie是儲存在客戶端的小文字，儲存的位置分為兩種 cookie可能儲存在客戶端瀏覽器的所佔記憶體中，關閉瀏覽器後，cookies就不再存在。cookie也可能儲存在客戶pc機的硬碟上，設定有效時間，超過有效時間後失效。cookie的常見應用 簡化登入 很多 在登入時，可...