帶bom的utf8 php檔案 偶爾出現亂碼的問題..

有沒有人遇到過類似的情形呢？

因為不是一直出現，而且嘗試過最簡單的代碼也出問題，就沒往代碼方面去想，一直在糾結是不是php擴充出了問題。

後來同事把bom去掉就好了，驚喜之餘更多的是鬱悶。。。太丟人了

雖然問題解決了，但具體是什麼原因呢？

回複內容：

有沒有人遇到過類似的情形呢？

因為不是一直出現，而且嘗試過最簡單的代碼也出問題，就沒往代碼方面去想，一直在糾結是不是php擴充出了問題。

後來同事把bom去掉就好了，驚喜之餘更多的是鬱悶。。。太丟人了

雖然問題解決了，但具體是什麼原因呢？

Unicode是唯一的，但Unicode的編碼方式不是唯一的。編碼方式可能是唯一的，但大端小端在前還不一定是唯一的。光說開啟一個“Unicode”檔案，其實不太容易做。

BOM就是把一個Unicode保留字元U+FEFF，按照檔案儲存體者的編碼方式編碼後，塞到檔案內容的最前邊。這樣用不同的Unicode編碼去解析檔案頭，就可以得知檔案的編碼方式和大小端順序。結果就是檔案頭部多出來了兩三個位元組。

有了BOM所有的程式都必須為BOM作出修改，這無疑是一個“大折騰”的行為。所以一般不認為BOM是個好主意。BOM引發的問題，我能想起來兩個：

• PHP無法指定header（因為有BOM相當於開啟輸出）
• UNIX可執行指令碼的Shabang標記（#!）不能識讀

任何時候都採用無BOM的UTF-8編碼的Unicode，絕對是一個引發麻煩最少的最實用策略。UTF-8是Unicode的最佳實務，沒有之一。

必須指出的是，何棄療的微軟經常做出非要DOM不可的行為，最典型的例子就是那個記事本（存檔就加DOM）。所以任何時候，都千萬別偷懶用記事本編輯PHP。華語驕傲Notepad++是Windows下的不二之選。

永遠不要忘記：微軟是技術落後，並且只會對超過自己的開源界冷嘲熱諷，從不肯真正改正自己問題的業界毒瘤。話下的狠了點，不過就算沒到這程度，也差不了多少。從一點一滴開始遠離微軟，讓生活變得輕鬆些。

BOM: Byte Order Mark

UTF-8 BOM 又叫 UTF-8 簽名，其實 UTF-8 的 BOM 對 UFT-8 沒有作用，是為了支援 UTF-16，UTF-32 才加上的 BOM ，BOM 簽名的意思就是告訴弱編輯器（記事本）當前檔案採用何種編碼，方便編輯器識別。

PHP 在設計之初，沒有考慮到 BOM 頭的問題，因此很容易因為 BOM 頭引發詭異的問題，比如編碼轉換失敗，樣式錯亂等等問題，而且此問題相當隱蔽，很難確定發生問題的檔案（試想在沒有工具的情況下從上萬的工程檔案中找到哪個檔案帶有 BOM 頭）。

BOM 頭是隱藏字元，非編輯字元，就像普通空檔案一樣，當我們寫

{BOM頭}

當 file.php 被其他檔案包含時，由於 BOM 頭在 php 標籤外，會當作輸出內容輸出到瀏覽器，然後引發問題。

少年，珍愛生命，遠離 BOM 。

一般的編輯器，是偵測不到utf8+bom的， 諸如記事本、寫字板等等。 須使用editplus、ultraedit等文字編輯器進行偵測， 然後另存新檔utf8 no bom格式。

出現問題的原因可能是您用過記事本類的弱文字編輯器編輯過。

