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