bom: byte order mark
utf-8
bom又叫
utf-8
簽名,其實
utf-8
的bom對uft-8沒有作用,是為了支援utf-16,utf-32才加上的bom,bom簽名的意思就是告訴編輯器當前檔案採用何種編碼,方便編輯器識別,但是bom雖然在編輯器中不顯示,但是會產生輸出,就像多了乙個空行
php在處理bom頭的時候，有時候存在錯誤，可能造成你在使用 header 或 session_start 之類的函式時，出現 檔案已經輸出的錯誤，多數都是因為bom頭送出去了。。因為在php看來，成了乙個空格。所以使用無bom的格式！
bom——byte order mark，就是位元組序標記
在ucs 編碼中有乙個叫做"zero width no-break space"的字元，它的編碼是feff。而fffe在ucs中是不存在的字元，所以不應該出現在實際傳輸中。ucs規範建議我們在傳輸位元組流前，先傳輸 字元"zero width no-break space"。這樣如果接收者收到feff，就表明這個位元組流是big-endian的；如果收到fffe，就表明這個位元組流是little- endian的。因此字元"zero width no-break space"又被稱作bom。
utf-8不需要bom來表明位元組順序，但可以用bom來表明編碼方式。字元"zero width no-break space"的utf-8編碼是ef bb bf。所以如果接收者收到以ef bb bf開頭的位元組流，就知道這是utf-8編碼了。
utf- 8編碼的檔案中，bom佔三個位元組。如果用記事本把乙個文字檔案另存為utf-8編碼方式的話，用ue開啟這個檔案，切換到十六進製制編輯狀態就可以看到開 頭的fffe了。這是個標識utf-8編碼檔案的好辦法，軟體通過bom來識別這個檔案是否是utf-8編碼，很多軟體還要求讀入的檔案必須帶bom。可 是，還是有很多軟體不能識別bom。
在firefox早期的版本裡，擴充套件是不能有bom的，不過firefox 1.5以後的版本已經開始支援bom了。現在又發現，php也不支援bom。php在設計時就沒有考慮bom的問題，也就是說他不會忽略utf-8編碼的檔案開頭bom的那三個字元。
由 於必須在在bo-blog的wiki看到，同樣使用php的bo-blog也一樣受到bom的困擾。其中有提到另乙個麻煩：「受cookie送出機制的限 制，在這些檔案開頭已經有bom的檔案中，cookie無法送出（因為在cookie送出前php已經送出了檔案頭），所以登入和登出功能失效。一切依賴 cookie、session實現的功能全部無效。」這個應該就是wordpress後台出現空白頁面的原因了，因為任何乙個被執行的檔案包含了bom， 這三個字元都將被送出，導致依賴cookies和session的功能失效。
解決的辦法嘛，如果只包含英 文字元(或者說ascii編碼內的字元)，就把檔案存成ascii碼方式吧。用ue等編輯器的話，點檔案->轉換->utf-8轉 ascii，或者在另存為裡選擇ascii編碼。如果是dos格式的行尾符，可以用記事本開啟，點另存為，選ascii編碼。如果包含中文字元的話，可以 用ue的另存為功能，選擇「utf-8 無 bom」即可。
utf-8本來就不應該加bom，除了 讓編輯器知道它是個utf-8之外什麼用處都沒有。實際上編輯器完全有能力在不太多的幾個編碼格式之間根據特徵來判斷乙個檔案是什麼編碼，就算不能自動識 別，編輯器也應該有設定編碼的地方。所以我覺得bom對於utf-8來說是多餘的東西。
utf-16才需要加bom。因為它是按unicode順序編碼，在bmp範圍內是二位元組，需要識別是大或小字節序。
實 際上，我覺得utf-8引入大小位元組序的概念太愚蠢了，不知道那些標準委員會是怎麼想的。大小位元組序存在的意義，在於cpu的處理方式。如果cpu是大字 節序處理，那麼對於小字節序，就必須做一層轉換，這帶來了效率上的下降。但是在實際應用裡，誰會去關心大小位元組序？文字編碼引起位元組序的概念，只能說那些 制定標準的人太死板了。對於utf-16，我認為只要全世界都遵循一種位元組序方式，那就沒什麼必要用bom來標註了。
話說回來，php是不支援utf-16編碼的檔案的。因為例如$這個符號，在utf-8裡也是兩個位元組，php解碼器無法解析的。不知道php6內部處理引入unicode 的概念之後，對這個是否會有支援。
編 碼問題是乙個說起來簡單，但是實際上很繁瑣的東西。很多程式，都有分層編碼的概念。像mysql，就分為 client->connection->storage和storage->connection->result這些概念。 storage又分為system,database,table,column。我有時候在想，有必要搞這麼複雜嘛，****。像mysql，誰用利用 它這些特性阿？除非允許兩個client在不同的編碼環境下運作，否則它把client編碼分離出來根本沒有什麼必要。大多數情況下，直接binary in/binary out就好了
參考：
utf 8與utf 8無BOM的區別
utf 8 8 bit unicode transformation format 是一種針對unicode的可變長度字元編碼，又稱萬國碼。bom byte order mark，位元組序標記 utf 8不需要bom來表明位元組順序，但可以用bom來表明編碼方式。字元 zero width no b...
帶BOM的UTF 8和無BOM 的UTF 8的區別
utf 8 不需要 bom，儘管 unicode 標準允許在 utf 8 中使用 bom。所以不含 bom 的 utf 8 才是標準形式，在 utf 8 檔案中放置 bom 主要是微軟的習慣 順便提一下 把 utf 16 le 稱作 unicode 而又不詳細說明，這也是微軟的習慣 bom byte...
utf 8與utf 8 bom的區別
在utf 8編碼檔案中bom在檔案頭部，占用三個位元組，用來標識該檔案屬於utf 8編碼，現在已經有很多軟體識別bom頭，但還是有些不能識別bom頭，比如php就不能識別bom頭，這也就是用記事本編輯utf 8編碼的php檔案後，就會報錯的原因。在windows環境下，用記事本開啟任何乙個文字檔案，...