使用 utf-8 編碼來編寫網頁的時候， 往往會因為 bom (Byte Order Mark) 的問題，導致網頁中經常出現一些不明的空行或者亂碼字符。 這些都是因為 utf-8 編碼方式對于 bom 不是強制的。因此 utf-8 編碼在保存文件的時候，會出現不同的處理方式。比如有的瀏覽器(FireFox)可以自動過濾掉所有 utf-8 bom ， 有的 (IE) 只能過濾掉一次 bom （為什么是一次？ 當你出現 Include 多次文件時就會碰上這個問題了）。


使用editplus或其他編輯器刪除掉文件中的BOM簽名，重新刷新頁面，樣式正常了。

在這里找到一段關于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來標記文本文件的編碼方式的。

...

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的話，將會造成在頁面上輸出這三個字符，顯示效果就要看瀏覽器了，一般是一個空行或是一個亂碼。