UTF-8文件中Unicode簽名BOM的示例分析

這篇文章將為大家詳細講解有關UTF-8文件中Unicode簽名BOM的示例分析，小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。

近日在調測一個UTF8編碼的中文Zen Cart網站時遇到一件怪事，網頁顯示文字正常，用ie的察看源文件（記事本打開）卻發現亂碼，firefox沒有這個問題。經在網上多方查證和多次測試，解決了這個問題，其實是UTF-8文件的Unicode簽名BOM(Byte Order Mark)問題。

BOM(Byte Order Mark)，是UTF編碼方案里用于標識編碼的標準標記，在UTF-16里本來是FF FE，變成UTF-8就成了EF BB BF。這個標記是可選的，因為UTF8字節沒有順序，所以它可以被用來檢測一個字節流是否是UTF-8編碼的。微軟做這種檢測，但有些軟件不做這種檢測，而把它當作正常字符處理。

微軟在自己的UTF-8格式的文本文件之前加上了EF BB BF三個字節, windows上面的notepad等程序就是根據這三個字節來確定一個文本文件是ASCII的還是UTF-8的, 然而這個只是微軟暗自作的標記, 其它平臺上并沒有對UTF-8文本文件做個這樣的標記。

也就是說一個UTF-8文件可能有BOM，也可能沒有BOM，那么怎么區分呢？三種方法。1，用UltraEdit-32打開文件，切換到十六進制編輯模式，察看文件頭部是否有EF BB BF。2，用Dreamweaver打開，察看頁面屬性，看“包括Unicode簽名BOM”前面是否有個勾。3，用Windows的記事本打開，選擇 “另存為”，看文件的默認編碼是UTF-8還是ANSI，如果是ANSI則不帶BOM。

我找到Zen Cart的模版文件中的html_header.php，發現文件果然不帶BOM，用UltraEdit-32另存為的方式加上BOM后，再上傳html_header.php，一切正常。

注意用Convertz把gb2312文件轉換成UTF-8文件時，默認設置是不帶BOM的。不帶BOM可能出現上述亂碼問題，但是帶 BOM，對于php的include文件要小心，會在php字節流前面多出EF BB BF，提前輸出到顯示器有可能會帶來程序錯誤。一個解決方案是凡是被include的文件都保存為ANSI，主文件可以是UTF-8。要想把一個文件去掉 BOM，使用UlterEdit打開, 切換到十六進制編輯模式，把最前面三個字節(就是那該死的 EF BB BF)替換為20，保存（注意關閉保存時自動備份的功能），再切換到默認編輯模式，把最前面的三個空格去掉就可以了。

另外還學到一些編碼的小知識：所謂的unicode保存的文件實際上是utf-16，只不過恰好跟unicode的碼相同而已,但在概念上unicode與utf是兩回事，unicode是內存編碼表示方案，而utf是如何保存和傳輸unicode的方案。utf-16還分高位在前 (LE)和高位在后(BE)兩種。官方的utf編碼還有utf-32，也分LE和BE。非unicode官方的utf編碼還有utf-7，主要用于郵件傳輸。utf-8的單字節部分是和iso-8859-1兼容的，這主要是一些舊的系統和庫函數不能正確處理utf-16而被迫出來的，而且對英語字符來說，也節省保存的文件空間（以非英語字符浪費空間為代價）。在iso-8859-1的時候，utf8和iso-8859-1都是用一個字節表示的，當表示其它字符的時候，utf-8會使用兩個或三個字節。

關于“UTF-8文件中Unicode簽名BOM的示例分析”這篇文章就分享到這里了，希望以上內容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。