UTF-8 BOM 可能導(dǎo)致樣式錯(cuò)亂的解決方法

使用 utf-8 編碼來(lái)編寫(xiě)網(wǎng)頁(yè)的時(shí)候， 往往會(huì)因?yàn)?bom (Byte Order Mark) 的問(wèn)題，導(dǎo)致網(wǎng)頁(yè)中經(jīng)常出現(xiàn)一些不明的空行或者亂碼字符。 這些都是因?yàn)?utf-8 編碼方式對(duì)于 bom 不是強(qiáng)制的。因此 utf-8 編碼在保存文件的時(shí)候，會(huì)出現(xiàn)不同的處理方式。比如有的瀏覽器(FireFox)可以自動(dòng)過(guò)濾掉所有 utf-8 bom ， 有的 (IE) 只能過(guò)濾掉一次 bom （為什么是一次？ 當(dāng)你出現(xiàn) Include 多次文件時(shí)就會(huì)碰上這個(gè)問(wèn)題了）。


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

在這里找到一段關(guān)于BOM的說(shuō)明，也許可以幫助你理解：

在UCS 編碼中有一個(gè)叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的編碼是FEFF。而FFFE在UCS中是不存在的字符，所以不應(yīng)該出現(xiàn)在實(shí)際傳輸中。UCS規(guī)范建議我們?cè)趥鬏斪止?jié)流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。這樣如果接收者收到FEFF，就表明這個(gè)字節(jié)流是Big-Endian的；如果收到FFFE，就表明這個(gè)字節(jié)流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱(chēng)作BOM。

UTF-8不需要BOM來(lái)表明字節(jié)順序，但可以用BOM來(lái)表明編碼方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF。所以如果接收者收到以EF BB BF開(kāi)頭的字節(jié)流，就知道這是UTF-8編碼了。

Windows就是使用BOM來(lái)標(biāo)記文本文件的編碼方式的。

...

UTF-8編碼的文件中，BOM占三個(gè)字節(jié)。如果用記事本把一個(gè)文本文件另存為UTF-8編碼方式的話，用UE打開(kāi)這個(gè)文件，切換到十六進(jìn)制編輯狀態(tài)就可以看到開(kāi)頭的FFFE了。這是個(gè)標(biāo)識(shí)UTF-8編碼文件的好辦法，軟件通過(guò)BOM來(lái)識(shí)別這個(gè)文件是否是UTF-8編碼，很多軟件還要求讀入的文件必須帶BOM?？墒?，還是有很多軟件不能識(shí)別BOM。我在研究Firefox的時(shí)候就知道，在Firefox早期的版本里，擴(kuò)展是不能有BOM的，不過(guò)Firefox 1.5以后的版本已經(jīng)開(kāi)始支持BOM了?，F(xiàn)在又發(fā)現(xiàn)，PHP也不支持BOM。

PHP在設(shè)計(jì)時(shí)就沒(méi)有考慮BOM的問(wèn)題，也就是說(shuō)他不會(huì)忽略UTF-8編碼的文件開(kāi)頭BOM的那三個(gè)字符。由于必須在?或者?php后面的代碼才會(huì)作為PHP代碼執(zhí)行，所以這三個(gè)字符將會(huì)直接輸出。如果插件的文件有這個(gè)問(wèn)題，將會(huì)導(dǎo)致在后臺(tái)頁(yè)面里激活或者不激活插件后顯示白屏，如果是模版文件有這個(gè)問(wèn)題，將會(huì)導(dǎo)致這三個(gè)字符直接輸出，造成頁(yè)面上方有一個(gè)小空行。國(guó)外的英文插件和模版一般都是用的ASCII碼的編碼方式，不會(huì)有BOM，只有國(guó)內(nèi)的插件和模版會(huì)由于作者的不知情造成問(wèn)題。還有，大家修改模版的時(shí)候，由于輸出頁(yè)面使用UTF-8編碼，那么修改模版的時(shí)候如果有加入中文字符的話，必須把文件轉(zhuǎn)成UTF-8編碼才能正常顯示，這個(gè)時(shí)候如果所使用的編輯器自動(dòng)加上了BOM的話，將會(huì)造成在頁(yè)面上輸出這三個(gè)字符，顯示效果就要看瀏覽器了，一般是一個(gè)空行或是一個(gè)亂碼。