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會使用兩個或三個位元組。