本文主要討論Unicode的編碼與各種實現,著重討論UTF-16,UTF-8的實現規則,以及Big-endian和Little-Endian的存儲規則。
一、Unicode編碼
? ? Unicode出現之前已經有各種編碼標準:ANSI、ISO8859-1、GB2312、GBK以及BIG-5等。Unicode試圖統一各種編碼,在Unicode演進過程中,也有自身不斷修復的過程:剛開始的時候認為16位可以表達65535個字符,已經足夠收集所有的字符;后來隨著大量中文、韓文和日文等表意文字的加入,已經超出了65535個字符,16位已經不能描述所有的字符集了。
? ? 在Unicode字符集中的某個字符對應的代碼值,稱作代碼點(Code Point),用16進制書寫,并加上U+前綴。比如,‘田’的代碼點是U+7530;‘A’的代碼點是U+0041。
? ? 前面說過,Unicode的字符已經超過16位所能表達的范圍,把所有這些CodePoint分成17個代碼平面(Code Plane):
- U+0000 ~ U+FFFF劃入基本多語言平面(Basic MultilingualPlane,簡記為BMP);
- 其余劃入16個輔助平面(Supplementary Plane),代碼點范圍U+10000?~ U+10FFFF。
? ? 雖然這樣劃分,但并不是每個Plane中的Codepoint都對應有字符,這里面有保留的,還有特殊用途的。
二、Unicode編碼的實現
? ? Unicode的實現方式不同于編碼方式。一個字符的Unicode編碼是確定的,但是在實際存儲和傳輸過程中,由于不同系統平臺的設計不一定一致,以及出于節省空間的目的,對Unicode編碼的實現方式有所不同。Unicode的實現方式稱為Unicode轉換格式(UnicodeTransformation Format,簡稱為UTF)。
? ? 對Unicode編碼的實現方式有UTF-16BE、UTF-16LE、UTF-8、UTF-7以及UTF-32等實現方式,目前通用的實現方式是UTF-16LE、UTF-16BE和UTF-8。
2.1 UTF-16
? ? UTF-16是用16bit編碼來表達Unicode,這樣表達范圍是216(即65536)。如果表達BMP內的字符,用一個UTF-16就可表達,對于輔助平面內的字符,UTF-16有巧妙的設計。
? ? BMP內,從U+D800到U+DFFF之間的碼位區段是永久保留不映射到字符, UTF-16利用保留下來的0xD800-0xDFFF區段的碼位來對輔助平面的字符的碼位進行編碼。
對U+0000 ~ U+D7FF以及U+E000 ~ U+FFFF的編碼
? ? UTF-16與UCS-2編碼這個范圍內的碼位為單個16比特長的碼元,數值等價于對應的碼位。BMP中的這些碼位是僅有的碼位可以在UCS-2被表示。
對U+10000 ~ U+10FFFF的編碼
? ? 輔助平面(Supplementary Planes)中的碼位,在UTF-16中被編碼為一對16比特長的碼元(即32bit,4Bytes),稱作代理對(surrogatepair)。
?具體方法是:
UTF-16解碼 | ||||
hi?\?lo | DC00 | DC01 | ???…??? | DFFF |
D800 | 10000 | 10001 | … | 103FF |
D801 | 10400 | 10401 | … | 107FF |
??? | ? | ? | ? | ? |
DBFF | 10FC00 | 10FC01 | … | 10FFFF |
- 碼位減去0x10000, 得到的值是長度為20bit(0..0xFFFFF);
- 步驟1得到數值的高位的10比特的值(值范圍為0..0x3FF)被加上0xD800得到第一個碼元或稱作高位代理(high surrogate)或前導代理(lead surrogate)。值的范圍是0xD800..0xDBFF。
- 步驟1得到數值的低位的10比特的值(值范圍為0..0x3FF)被加上0xDC00得到第二個碼元或稱作低位代理(low surrogate)或后尾代理(trail surrogate)。值的范圍是0xDC00..0xDFFF。
? ? 這樣,這個范圍內的字符就被編碼成了一個代理對[lead surrogate,trail surrogate]:兩個16bits碼元,取值范圍分別是0xD800..0xDBFF,0xDC00..0xDFF。而BMP中得到的碼元范圍0x0000..0xFFFF中,0xD800..0xDFFF又是保留的,所以這三個區段是相互不重疊的,在解碼時很容易實現。UTF-16解碼高位代理+低位代理得到的碼元與碼位的對應關系如上表所示:
? ? 下面以對U+64321的UTF-16編碼為例,看一下對于輔助平面內的字符的編碼實現:
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 //結果的前16位元初始值
w2 = 0xDC00 //結果的后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
? ? 所以這個字 U+64321 最后的 UTF-16 編碼是:
0xD950 0xDF21
對于生成的編碼,因為對于16Bits的兩字節,還有存取先后的問題,還有Endian的問題,這在后續講述。
2.2 UTF-8
? ? UTF-8(8-bitUnicode Transformation Format)是一種針對Unicode的可變長度字符編碼,使用一至四個字節為每個字符編碼:
- ?Unicode范圍為U+0000..U+007F 的128個ASCII字符只需一個字節編碼;
- ?Unicode范圍為U+0080..U+07FF的字符需要二個字節編碼;
- ?Unicode范圍為U+0800..U+FFFF的其他BMP中的字符(這包含了大部分常用字)使用三個字節編碼;
- ?Unicode 輔助平面的字符(其他極少使用的字符)使用四字節編碼。
? ? 對上述提及的第四種字符而言,UTF-8使用四個字節來編碼似乎太耗費資源了。但UTF-8對所有常用的字符都只用三個字節表達,而且UTF-16編碼對前述的第四種字符同樣需要四個字節來編碼,而如果是ASCII居多的字符,UTF-8能極大的節約存儲空間。UTF-8逐漸成為電子郵件、網頁及其他儲存或傳送文字的應用中,優先采用的編碼。互聯網工程工作小組(IETF)要求所有互聯網協議都必須支持UTF-8編碼。互聯網郵件聯盟(IMC)建議所有電子郵件軟件都支持UTF-8編碼。
? ? 對CodePoint各個范圍內的字符進行UTF-8編碼的規則如下:
Code point | UTF-8字節流 |
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之間的區段在Unicode的定義中沒有具體字符使用的,被用來在UTF-16編碼中對輔助平面的字符進行編碼。
? ? 下面以“田”(CodePoint為U+7530)為例,看如何對其進行UTF-8編碼:
- ?U+7530落在U+0800..U+FFFF區間,采用三字節編碼;
- ?0x7530轉換為二進制為111 010100 110000;
- ?代入表中,得到111001111001010010110000;
? ? 這樣,得到“田”(U+7530)的UTF-8編碼:0xE7 94 B0。
? ? 知道UTF-8的編碼規則,我們可以對于UTF-8編碼中的任意字節B,進行下面解碼:
- ?如果B的第一位為0,則B為ASCII碼,并且B獨立的表示一個字符;如果B的第一位為1,第二位為0,則B為一個非ASCII字符(該字符由多個字節表示)中的一個字節,并且不為字符的第一個字節編碼(字符的第一個字節之外的后編碼);
- ?如果B的前兩位為1,第三位為0,則B為一個非ASCII字符(該字符由多個字節表示)中的第一個字節,并且該字符由兩個字節表示;
- ?如果B的前三位為1,第四位為0,則B為一個非ASCII字符(該字符由多個字節表示)中的第一個字節,并且該字符由三個字節表示;
- ?如果B的前四位為1,第五位為0,則B為一個非ASCII字符(該字符由多個字節表示)中的第一個字節,并且該字符由四個字節表示。
?
2.3 UCS-2 vs UTF-16,UCS-4 vs UTF-32
? ? UCS-2每個字符占用2個字節。UCS-2是UTF-16的子集。在沒有輔助平面前,UTF-16與UCS-2所指的是同一的意思。但當引入輔助平面字符后,UTF-16加入了對輔助平面內的字符的支持。現在若有軟件聲稱自己支持UCS-2編碼,那其實是暗指它不支持UTF-16中超過2bytes的字集。亦即,對于小于0x10000的UCS碼,UTF-16編碼就等于UCS碼。Java早期版本對Unicode的支持,就只是UCS-2的支持,現在加入了對UTF-16的完整支持。
?
? ? UCS-4與UTF-32的意義一致,對每個字符都使用4字節(31位字符集,加上恒為0的首位,共需占據32位)。理論上最多能表示231個字符,完全可以涵蓋一切語言所用的符號。雖然每一個碼位使用固定長定的字節看似方便,對于普通只需要2個字節存儲的常用字占絕大對數的字符集來說,卻極大的浪費了空間,并沒怎么得到應用。
三、Big-Endian/Little-Endian與BOM
? ? 在講UTF-16編碼方式時說到,最終生成的編碼可能是2個字節(BMP內的字符),這兩個字節在傳輸和存儲過程中,高/低位位置不同,是不同的字符。比如,“田”的UTF-16編碼是0x7530,但是如果存成0x3075,就變成了“ふ”,另外的字符。
? ? 所以,為了識別一個編碼過的字符的存儲順序,必須用特殊字符來指示。Unicode字符中U+FEFF被用來指示這種存儲順序,被稱作Byte Order Mark(BOM)。
- ?Big-Endian:最低位地址存放高位字節,可稱高位優先,內存從最低地址開始按順序存放(高數位數字先寫)。最高位字節放最前面。
- ?Little Endian:最低位地址存放低位字節,可稱低位優先,內存從最低地址開始按順序存放(低數位數字先寫)。最低位字節放最前面。
? ? 所以,BOM在Big-Endian系統上存儲為FE FF;而在Big-Endian系統上存儲則為FF FE。在以Big-Endian存儲的UTF-16(UTF-16BE)的文件的開頭,用FEFF指示;以Little-Endian存儲的UTF-16(UTF-16LE)的文件的開頭,用FEFF指示。
? ? 在Windows的記事本上,另存為的時候,你可以選擇不同的Endian存儲,然后再用純文本編輯工具(Ultra-edit)來檢驗一下,UTF-16的存儲順序。
? ? BOM的UTF-8編碼為11101111?1011101110111111?(EF BB BF),所以一般EF BB BF被放在文本的開頭,用來指示其編碼為UTF-8。
【附】基本概念對照
Code Point碼位
Code Unit碼元是指一個已編碼的文本中具有最短的比特組合的單元。對于UTF-8來說,碼元是8比特長;對于UTF-16來說,碼元是16比特長;對于UTF-32來說,碼元是32比特長。
BMP - Basic Multilingual Plane
UTF - Unicode Transformation Format
BOM – Byte Order Mark
UCS - Universal Character Set