2012-04-25
本文主要討論Unicode的編碼及其各種實(shí)現(xiàn),著重討論UTF-16,UTF-8的實(shí)現(xiàn)規(guī)則,以及Big-endian和Little-Endian的存儲(chǔ)順序。
Unicode出現(xiàn)之前已經(jīng)有各種編碼標(biāo)準(zhǔn):ANSI、ISO8859-1、GB2312、GBK以及BIG-5等。Unicode試圖統(tǒng)一各種編碼,在Unicode演進(jìn)過(guò)程中,也有自身不斷修復(fù)的過(guò)程:剛開(kāi)始的時(shí)候用16位表達(dá)65535個(gè)字符,認(rèn)為已經(jīng)足夠收集所有的字符;后來(lái)隨著大量中文、韓文和日文等表意文字的加入,已經(jīng)超出了65535個(gè)字符,16位已經(jīng)不能描述所有的字符集了。
在Unicode字符集中的某個(gè)字符對(duì)應(yīng)的代碼值,稱作代碼點(diǎn)(Code Point),用16進(jìn)制書(shū)寫(xiě),并加上U+前綴。比如,‘田’的代碼點(diǎn)是U+7530;‘A’的代碼點(diǎn)是U+0041。
Unicode定義的字符集已經(jīng)超過(guò)16位所能表達(dá)的范圍,把所有這些CodePoint分成17個(gè)代碼平面(Code Plane):
雖然這樣劃分,但并不是每個(gè)Plane中的Code point都對(duì)應(yīng)有字符,這里面有保留的,還有特殊用途的。
Unicode的實(shí)現(xiàn)方式不同于編碼方式。一個(gè)字符的Unicode編碼是確定的,但是在實(shí)際存儲(chǔ)和傳輸過(guò)程中,由于不同系統(tǒng)平臺(tái)的設(shè)計(jì)不一定一致,以及出于節(jié)省空間的目的,對(duì)Unicode編碼的實(shí)現(xiàn)方式有所不同。Unicode的實(shí)現(xiàn)方式稱為Unicode轉(zhuǎn)換格式(Unicode Transformation Format,簡(jiǎn)稱為UTF)。
對(duì)Unicode編碼的主要有UTF-16BE、UTF-16LE、UTF-8、UTF-7以及UTF-32等實(shí)現(xiàn)方式,目前常用的實(shí)現(xiàn)方式是UTF-16LE、UTF-16BE和UTF-8。
UTF-16是用16bit編碼來(lái)表達(dá)Unicode,這樣表達(dá)范圍是216(即65536),也就是UTF-16的代碼單元(Code Unit)為16bits。如果表達(dá)BMP內(nèi)的字符,用一個(gè)UTF-16的Code Unit就可表達(dá),對(duì)于輔助平面內(nèi)的字符,UTF-16有巧妙的設(shè)計(jì)。
落在BMP內(nèi),從U+D800到U+DFFF之間的Code Point區(qū)段是永久保留不映射到字符, UTF-16利用這保留下來(lái)的0xD800-0xDFFF區(qū)段的CodePoint來(lái)對(duì)輔助平面內(nèi)的字符的Code Point進(jìn)行編碼。
對(duì)U+0000.. U+D7FF以及U+E000.. U+FFFF的編碼
UTF-16與UCS-2對(duì)這個(gè)范圍內(nèi)的CodePoint進(jìn)行編碼,采用單個(gè)16bit長(zhǎng)的CodeUnit,數(shù)值等價(jià)于對(duì)應(yīng)的Code Point。BMP中的這些Code Point是僅有的可以被UCS-2表示的Code Point。
對(duì)U+10000.. U+10FFFF的編碼
輔助平面(Supplementary Planes)中的CodePoint,在UTF-16中被編碼為一對(duì)16bit長(zhǎng)的Code Unit(即32bit,4Bytes),稱作代理對(duì)(surrogate pair)。
具體方法是:
UTF-16解碼 | ||||
hi \ lo | DC00 | DC01 | … | DFFF |
D800 | 10000 | 10001 | … | 103FF |
D801 | 10400 | 10401 | … | 107FF |
| ||||
DBFF | 10FC00 | 10FC01 | … | 10FFFF |
這樣,這個(gè)范圍內(nèi)的字符就被編碼成了一個(gè)代理對(duì)[lead surrogate,trail surrogate]:兩個(gè)16bits的Code Unit,取值范圍分別是0xD800..0xDBFF和0xDC00..0xDFFF。而B(niǎo)MP中得到的Code Unit的范圍是0x0000..0xFFFF(0xD800..0xDFFF是保留的,不包含其中),所以這三個(gè)區(qū)段是相互不重疊的,在解碼時(shí)很容易實(shí)現(xiàn)。
UTF-16解碼[高位代理+低位代理]得到的Code Unit對(duì)與Code Point的對(duì)應(yīng)關(guān)系如上表所示。
下面以對(duì)U+64321的UTF-16編碼為例,看一下對(duì)于輔助平面內(nèi)的字符是如何編碼的:
V = 0x64321
Vx = V - 0x10000
= 0x54321
= 01010100 0011 0010 0001
Vh = 01 0101 0000 // Vx 的高位部份的 10 bits
Vl = 11 0010 0001 // Vx 的低位部份的 10 bits
w1 = 0xD800 // 結(jié)果的前16位元初始值
w2 = 0xDC00 // 結(jié)果的后16位元初始值
w1 = w1 | Vh
= 1101 1000 0000 0000
| 01 0101 0000
= 1101 1001 0101 0000
= 0xD950
w2 = w2 | Vl
= 1101 1100 0000 0000
| 11 0010 0001
= 1101 1111 0010 0001
= 0xDF21
所以,這個(gè)字 U+64321 最終的 UTF-16 編碼是:
0xD950 0xDF21
UTF-16的Code Unit是16bits,兩個(gè)字節(jié)。存儲(chǔ)一個(gè)Code Unit的時(shí)候,還有存取的先后順序問(wèn)題,也就是Endian問(wèn)題,這在后面章節(jié)講述。
UTF-8(8-bit Unicode Transformation Format)是一種針對(duì)Unicode的可變長(zhǎng)度字符編碼,使用一至四個(gè)字節(jié)為每個(gè)字符編碼:
對(duì)上述提及的第四種字符而言,UTF-8使用四個(gè)字節(jié)來(lái)編碼似乎太耗費(fèi)資源了。但UTF-8對(duì)所有常用的字符都只用三個(gè)字節(jié)表達(dá),而且UTF-16編碼對(duì)前述的第四種字符同樣需要四個(gè)字節(jié)來(lái)編碼,而如果是ASCII居多的字符,UTF-8能極大的節(jié)約存儲(chǔ)空間。UTF-8逐漸成為電子郵件、網(wǎng)頁(yè)及其他儲(chǔ)存或傳送文字的應(yīng)用中,優(yōu)先采用的編碼?;ヂ?lián)網(wǎng)工程工作小組(IETF)要求所有互聯(lián)網(wǎng)協(xié)議都必須支持UTF-8編碼。互聯(lián)網(wǎng)郵件聯(lián)盟(IMC)建議所有電子郵件軟件都支持UTF-8編碼。
對(duì)CodePoint各個(gè)范圍內(nèi)的字符進(jìn)行UTF-8編碼的規(guī)則如下:
Code point | UTF-8字節(jié)流 |
U+00000000 – U+0000007F | 0xxxxxxx |
U+00000080 – U+000007FF | 110xxxxx 10xxxxxx |
U+00000800 – U+0000FFFF | 1110xxxx 10xxxxxx 10xxxxxx |
U+00010000 – U+001FFFFF | 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx |
其中,U+D800到U+DFFF之間的區(qū)段在Unicode字符集的定義中沒(méi)有具體字符使用的,被用來(lái)在UTF-16編碼中對(duì)輔助平面的字符進(jìn)行編碼。
下面以“田”(Code Point為U+7530)為例,看如何對(duì)其進(jìn)行UTF-8編碼:
這樣,得到“田”(U+7530)的UTF-8編碼:0xE7 94 B0。
知道UTF-8的編碼規(guī)則,我們可以對(duì)于UTF-8編碼中的任意字節(jié)B,進(jìn)行下面解碼:
UCS-2每個(gè)字符占用2個(gè)字節(jié)。UCS-2是UTF-16的子集。在沒(méi)有輔助平面前,UTF-16與UCS-2所指的是同一的意思。但當(dāng)引入輔助平面字符后,UTF-16加入了對(duì)輔助平面內(nèi)的字符的支持?,F(xiàn)在若有軟件聲稱自己支持UCS-2編碼,那其實(shí)是暗指它不支持UTF-16中超過(guò)2bytes的字集。亦即,對(duì)于小于0x10000的UCS碼,UTF-16編碼就等于UCS碼。Java早期版本對(duì)Unicode的支持,就只是UCS-2的支持,現(xiàn)在加入了對(duì)UTF-16的完整支持。
UCS-4與UTF-32的意義一致,對(duì)每個(gè)字符都使用4字節(jié)(31位字符集,加上恒為0的首位,共需占據(jù)32位)。理論上最多能表示231個(gè)字符,完全可以涵蓋一切語(yǔ)言所用的符號(hào)。雖然每一個(gè)Code Point使用固定長(zhǎng)定的字節(jié)看似方便,對(duì)于普通只需要2個(gè)字節(jié)存儲(chǔ)的常用字占絕大對(duì)數(shù)的字符集來(lái)說(shuō),卻極大的浪費(fèi)了空間,并沒(méi)怎么得到應(yīng)用。
在講UTF-16編碼方式時(shí)說(shuō)到,UTF-16編碼的Code Unit是2個(gè)字節(jié),這兩個(gè)字節(jié)在傳輸和存儲(chǔ)過(guò)程中,高/低位位置不同,是不同的字符。比如,“田”的UTF-16編碼是0x7530,但是如果存成0x3075,就變成了“ふ”,成了另外的字符。
所以,為了識(shí)別一個(gè)編碼過(guò)的字符的存儲(chǔ)順序,必須用特殊字符來(lái)指示。Unicode字符中U+FEFF被用來(lái)指示這種存儲(chǔ)順序,被稱作Byte Order Mark(BOM)。
BOM在Big-Endian系統(tǒng)上存儲(chǔ)為FE FF;而在Big-Endian系統(tǒng)上存儲(chǔ)則為FF FE。所以在以Big-Endian存儲(chǔ)的UTF-16(UTF-16BE)的文件的開(kāi)頭,用FEFF指示;以Little-Endian存儲(chǔ)的UTF-16(UTF-16LE)的文件的開(kāi)頭,用FFFE指示。
BOM的UTF-8編碼為11101111 1011101110111111 (EF BB BF),所以一般EF BB BF被放在文本的開(kāi)頭,用來(lái)指示其編碼為UTF-8。
四、Unicode編碼實(shí)踐
在Windows的文本編輯工具記事本上,選擇“另存為”的時(shí)候,用戶可以選擇不同的編碼選項(xiàng),對(duì)應(yīng)編碼選項(xiàng)有“ANSI”,“Unicode”,“Unicode big endian”,以及“UTF-8”。因?yàn)閃indows的存儲(chǔ)方式是Little-Endian,所以“Unicode”,“Unicode big endian”對(duì)應(yīng)的分別是UTF-16LE和UTF-16BE。
讀者可以試著編寫(xiě)一串字符,然后分別用不同的編碼保存,再用可以16進(jìn)制編寫(xiě)的純文本編輯工具(如,Ultra-edit)來(lái)檢驗(yàn)一下具體的編碼實(shí)現(xiàn)和存儲(chǔ)順序。下面是筆者將“田海立(U+7530, U+6D77, U+7ACB)”以不同編碼方式保存,得到的結(jié)果:
田海立_UTF-16BE.txt
FEFF75306D777ACB
田海立_UTF-16LE.txt
FFFE3075776DCB7A
田海立_UTF-8.txt
EFBBBFE794B0E6B5B7E7AB8B
為了明確起見(jiàn),BOM的編碼用粗體標(biāo)注;田的編碼用紅色標(biāo)注;海的編碼用綠色標(biāo)注;立的編碼用藍(lán)色標(biāo)注。可以看到,記事本(Notepad)存儲(chǔ)的Unicode編碼的文件的開(kāi)頭位置,用BOM的相應(yīng)編碼指示了編碼格式。
【后記】歷史
最近需要用到Unicode的編碼實(shí)現(xiàn)方式,又收集了一下資料。發(fā)現(xiàn)早在06年的時(shí)候,筆者就準(zhǔn)備總結(jié)一下Unicode的編碼實(shí)現(xiàn),文檔里也已經(jīng)有了提綱?,F(xiàn)在也不記得當(dāng)時(shí)什么原因給耽擱了,好在現(xiàn)在及時(shí)總計(jì)歸納。好腦子不如爛筆頭啊。如果當(dāng)初總結(jié)下來(lái),現(xiàn)在也不用再浪費(fèi)時(shí)間收集資料。
希望,這次的總結(jié)能比較完善,以后再用到Unicode編碼,只要參考此文即可?。ó?dāng)然前提是Unicode標(biāo)準(zhǔn)別又演進(jìn)了^_^)
聯(lián)系客服