php utf-8的 BOM 問題解決

最近做程式的是否發現自己的php程式最上端總有莫名的分行符號

後來發現原來是bom在作怪，以下是我在解決這個問題後的一個總結

Unicode規範中有一個BOM的概念。BOM——Byte Order Mark，就是位元組序標記。在這裡找到一段關於BOM的說明：

在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編碼了。

Windows就是使用BOM來標記文字檔的編碼方式的。

另外unicode網站的FAQ-BOM詳細介紹了BOM。官方的自然權威，不過是英文的，看起來比較費勁。

UTF-8編碼的檔案中，BOM佔三個位元組。如果用記事本把一個文字檔另存新檔UTF-8編碼方式的話，用UE開啟這個檔案，切換到十六進位編輯狀態就可以看到開頭的FFFE了。這是個標識UTF-8編碼檔案的好辦法，軟體通過BOM來識別這個檔案是否是UTF-8編碼，很多軟體還要求讀入的檔案必須帶BOM。可是，還是有很多軟體不能識別BOM。我在研究Firefox的時候就知道，在Firefox早期的版本裡，擴充是不能有BOM的，不過Firefox 1.5以後的版本已經開始支援BOM了。現在又發現，PHP也不支援BOM。

PHP在設計時就沒有考慮BOM的問題，也就是說他不會忽略UTF-8編碼的檔案開頭BOM的那三個字元。由於必須在<?或者<?php後面的代碼才會作為PHP代碼執行，所以這三個字元將會直接輸出。如果外掛程式的檔案有這個問題，將會導致在後台頁面裡啟用或者不啟用外掛程式後顯示白屏，如果是模版檔案有這個問題，將會導致這三個字元直接輸出，造成頁面上方有一個小空行。國外的英文外掛程式和模版一般都是用的ASCII碼的編碼方式，不會有BOM，只有國內的外掛程式和模版會由於作者的不知情造成問題。還有，大家修改模版的時候，由於輸出頁面使用UTF-8編碼，那麼修改模版的時候如果有加入中文字元的話，必須把檔案轉成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”即可。請參考下面的圖片：