快捷導(dǎo)航

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

更新時(shí)間：2009年06月13日 19:31:30 作者：

utf-8 是一種在web應(yīng)用中經(jīng)常使用的一種 unicode 字符的編碼方式，使用 utf-8 的好處在于它是一種變長(zhǎng)的編碼方式，對(duì)于 ANSII 碼編碼長(zhǎng)度為1個(gè)字節(jié)，這樣的話在傳輸大量 ASCII 字符集的網(wǎng)頁時(shí)，可以大量節(jié)約網(wǎng)絡(luò)帶寬。

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

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

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

在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"又被稱作BOM。

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

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

...

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

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