UTF-8與UTF-8(BOM)區別和一些說明
當前位置：點晴教程→知識管理交流
→『 技術文檔交流 』
寫在前面在我們通常使用的windows系統中，我發現了一個有趣的現象。我新建一個空的文本文檔，點擊文件-另存為-編碼選擇UTF-8，然后保存。此時這個文件明明是空的，卻占了3字節大小。原因在于：此時保存的編碼方式自動會變為UTF-8 BOM 一、一個漢字在不同的編碼方式中占多少字節？1.在UTF-8中，一個漢字占3個字節（一個字符占一個字節） 2.在ASCII碼中，一個漢字占2個字節（一個字符占一個字節） 3.在Unicode編碼中，一個漢字占2個字節（一個字符同樣占兩個字節，所以JAVA中char a = '中';是可以的） 二、UTF-8與UTF-8 BOMBOM即byte order mark，具體含義可百度百科或維基百科，UTF-8文件中放置BOM主要是微軟的習慣，但是放在別的系統上會出現問題。不含BOM的UTF-8才是標準形式，UTF-8不需要BOM帶BOM的UTF-8文件的開頭會有U+FEFF，所以我新建的空文件會有3字節的大小。 BOM的含義 BOM即Byte Order Mark字節序標記。BOM是為UTF-16和UTF-32準備的，用戶標記字節序（byte order）。拿UTF-16來舉例，其是以兩個字節為編碼單元，在解釋一個UTF-16文本前，首先要弄清楚每個編碼單元的字節序。例如收到一個“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16字節流"594E"，那么這是“奎”還是“乙”？ Unicode規范中推薦的標記字節順序的方法是BOM：在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"（零寬度無間斷空間）的字符，它的編碼是FEFF。而FEFF在UCS中是不不能再的字符（即不可見），所以不應該出現在實際傳輸中。UCS規范建議我們在傳輸字節流前，先傳輸字符"ZERO WIDTH NO-BREAK SPACE"。這樣如果接收者接收到FEFF，就表明這個字節流是Big-Endian的；如果收到FFFE，就表明這個字節流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被稱為BOM。 UTF-8是以字節為編碼單元，沒有字節序的問題。 延伸一下： UTF-8編碼是以1個字節為單位進行處理的，不會受CPU大小端的影響；需要考慮下一位時就地址 + 1。 UTF-16、UTF-32是以2個字節和4個字節為單位進行處理的，即1次讀取2個字節或4個字節，這樣一來，在存儲和網絡傳輸時就要考慮1個單位內2個字節或4個字節之間順序的問題。
UTF-8 BOM UTF-8 BOM又叫UTF-8 簽名，UTF-8不需要BOM來表明字節順序，但可以用BOM來表明編碼方式。當文本程序讀取到以 EF BB BF開頭的字節流時，就知道這是UTF-8編碼了。Windows就是使用BOM來標記文本文件的編碼方式的。 補充： "ZERO WIDTH NO-BREAK SPACE"字符的UCS編碼為FEFF（假設為大端），對應的UTF-8編碼為 EF BB BF 即以EF BB BF開頭的字節流可表明這是段UTF-8編碼的字節流。但如果文件本身就是UTF-8編碼的，EF BB BF這三個字節就毫無用處了。 所以，可以說BOM的存在對于UTF-8本身沒有任何作用。
UTF-8文件中包含BOM的壞處 1、對php的影響 php在設計時就沒有考慮BOM的問題，也就是說他不會忽略UTF-8編碼的文件開頭的那三個EF BB BF字符，直接當做文本進行解析，導致解析錯誤。 2、在linux上執行SQL腳本報錯 最近開發過程中遇到，windows下編寫的SQL文件，在linux下執行時，總是報錯。 在文件的開頭，無論是使用中文注釋還是英文注釋，甚至去掉注釋，也會報 血淚建議：UTF-8最好不要帶BOM 「UTF-8」和「帶 BOM 的 UTF-8」的區別就是有沒有 BOM。即文件開頭有沒有 U+FEFF。 Linux中查看BOM的方法：使用less命令，其它命令可能看不到效果：
發現詞語之前多了一個<U+FEFF>，導致報錯。 出于兼容性考慮最好不要帶BOM。 文件中有全角字符 在ASP中，如果文件使用了全角字符，需要帶BOM，否則會因識別不了全角字符而報錯。  該文章在 2024/7/31 8:47:43 編輯過 |
關鍵字查詢
相關文章
正在查詢... 
|
400 186 1886
