最近一直在忙點私活,又好久沒寫blog了,再不寫點的話二月份就又要以單篇文章結束了。前一陣子一直在研究Unicode,索性把研究結果介紹一下吧。
可能大家都聽說過 Unicode、UCS-2、UTF-8 等等詞匯,但它們具體是什么意思,是什么原理,之間有什么關系,恐怕就很少有人明白了。下面就分別介紹一下它們。
<!-- end Pukiwiki generated code-->?
<!-- begin Pukiwiki generated code-->基本知識
介紹Unicode之前,首先要講解一些基礎知識。雖然跟Unicode沒有直接的關系,但想弄明白Unicode,沒這些還真不行。
字節和字符的區別
咦,字節和字符能有什么區別啊?不都是一樣的嗎?完全正確,但只是在古老的DOS時代。當Unicode出現后,字節和字符就不一樣了。
字節(octet)是一個八位的存儲單元,取值范圍一定是0~255。而字符(character,或者word)為語言意義上的符號,范圍就不一定了。例如在UCS-2中定義的字符范圍為0~65535,它的一個字符占用兩個字節。
Big Endian和Little Endian
上面提到了一個字符可能占用多個字節,那么這多個字節在計算機中如何存儲呢?比如字符0xabcd,它的存儲格式到底是 AB CD,還是 CD AB 呢?
實際上兩者都有可能,并分別有不同的名字。如果存儲為 AB CD,則稱為 Big Endian ;如果存儲為 CD AB,則稱為 Little Endian 。
具體來說,以下這種存儲格式為Big Endian,因為值(0xabcd)的高位(0xab)存儲在前面:
地址 | 值 |
0x00000000 | AB |
0x00000001 | CD |
相反,以下這種存儲格式為Little Endian:
地址 | 值 |
0x00000000 | CD |
0x00000001 | AB |
UCS-2和UCS-4
Unicode是為整合全世界的所有語言文字而誕生的。任何文字在Unicode中都對應一個值,這個值稱為 代碼點 (code point)。代碼點的值通常寫成 U+ABCD 的格式。而文字和代碼點之間的對應關系就是 UCS-2 (Universal Character Set coded in 2 octets)。顧名思義,UCS-2是用兩個字節來表示代碼點,其取值范圍為 U+0000~U+FFFF。
為了能表示更多的文字,人們又提出了UCS-4,即用四個字節表示代碼點。它的范圍為 U+00000000~U+7FFFFFFF,其中 U+00000000~U+0000FFFF和UCS-2是一樣的。
要注意,UCS-2和UCS-4只規定了代碼點和文字之間的對應關系,并沒有規定代碼點在計算機中如何存儲。規定存儲方式的稱為 UTF (Unicode Transformation Format),其中應用較多的就是UTF-16和UTF-8了。
UTF-16和UTF-32
UTF-16
UTF-16由 RFC2781 規定,它使用兩個字節來表示一個代碼點。
不難猜到,UTF-16是完全對應于UCS-2的,即把UCS-2規定的代碼點通過Big Endian或Little Endian方式直接保存下來。UTF-16包括三種:UTF-16,UTF-16BE(Big Endian),UTF-16LE(Little Endian)。
UTF-16BE和UTF-16LE不難理解,而UTF-16就需要通過在文件開頭以名為BOM(Byte Order Mark)的字符來表明文件是Big Endian還是Little Endian。BOM為U+FEFF這個字符。
其實BOM是個小聰明的想法。由于UCS-2沒有定義U+FFFE,因此只要出現 FF FE 或者 FE FF 這樣的字節序列,就可以認為它是U+FEFF,并且可以判斷出是Big Endian還是Little Endian。
舉個例子。“ABC”這三個字符用各種方式編碼后的結果如下:
UTF-16BE | 00 41 00 42 00 43 |
UTF-16LE | 41 00 42 00 43 00 |
UTF-16(Big Endian) | FE FF 00 41 00 42 00 43 |
UTF-16(Little Endian) | FF FE 41 00 42 00 43 00 |
UTF-16(不帶BOM) | 00 41 00 42 00 43 |
Windows平臺下默認的Unicode編碼為Little Endian的UTF-16(即上述的 FF FE 41 00 42 00 43 00)。你可以打開記事本,寫上ABC,然后保存,再用二進制編輯器看看它的編碼結果。
另外,UTF-16還能表示一部分的UCS-4代碼點——U+10000~U+10FFFF。表示算法比較復雜,簡單說明如下:
- 從代碼點U中減去0x10000,得到U'。這樣U+10000~U+10FFFF就變成了 0x00000~0xFFFFF。
- 用20位二進制數表示U'。 U'=yyyyyyyyyyxxxxxxxxxx
- 將前10位和后10位用W1和W2表示,W1=110110yyyyyyyyyy,W2=110111xxxxxxxxxx,則 W1 = D800~DBFF,W2 = DC00~DFFF。
例如,U+12345表示為 D8 08 DF 45(UTF-16BE),或者08 D8 45 DF(UTF-16LE)。
但是由于這種算法的存在,造成UCS-2中的 U+D800~U+DFFF 變成了無定義的字符。
UTF-32
UTF-32用四個字節表示代碼點,這樣就可以完全表示UCS-4的所有代碼點,而無需像UTF-16那樣使用復雜的算法。與UTF-16類似,UTF-32也包括UTF-32、UTF-32BE、UTF-32LE三種編碼,UTF-32也同樣需要BOM字符。僅用'ABC'舉例:
UTF-32BE | 00 00 00 41 00 00 00 42 00 00 00 43 |
UTF-32LE | 41 00 00 00 42 00 00 00 43 00 00 00 |
UTF-32(Big Endian) | 00 00 FE FF 00 00 00 41 00 00 00 42 00 00 00 43 |
UTF-32(Little Endian) | FF FE 00 00 41 00 00 00 42 00 00 00 43 00 00 00 |
UTF-32(不帶BOM) | 00 00 00 41 00 00 00 42 00 00 00 43 |
UTF-8
UTF-16和UTF-32的一個缺點就是它們固定使用兩個或四個字節,這樣在表示純ASCII文件時會有很多00字節,造成浪費。而 RFC3629 定義的UTF-8則解決了這個問題。
UTF-8用1~4個字節來表示代碼點。表示方式如下:
UCS-2 (UCS-4) | 位序列 | 第一字節 | 第二字節 | 第三字節 | 第四字節 |
U+0000 .. U+007F | 00000000-0xxxxxxx | 0xxxxxxx | ? | ? | ? |
U+0080 .. U+07FF | 00000xxx-xxyyyyyy | 110xxxxx | 10yyyyyy | ? | ? |
U+0800 .. U+FFFF | xxxxyyyy-yyzzzzzz | 1110xxxx | 10yyyyyy | 10zzzzzz | ? |
U+10000..U+10FFFF |
00000000-000wwwxx-
xxxxyyyy-yyzzzzzzz |
11110www | 10xxxxxx | 10yyyyyy | 10zzzzzz |
可見,ASCII字符(U+0000~U+007F)部分完全使用一個字節,避免了存儲空間的浪費。而且UTF-8不再需要BOM字節。
另外,從上表中可以看出,單字節編碼的第一字節為[00-7F],雙字節編碼的第一字節為[C2-DF],三字節編碼的第一字節為[E0-EF]。這樣只要看到第一個字節的范圍就可以知道編碼的字節數。這樣也可以大大簡化算法。
?
版權聲明 :可以任意轉載,但轉載時必須標明原作者charlee、原始鏈接 http://tech.idv2.com/2008/02/21/unicode-intro/ 以及本聲明。
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號聯系: 360901061
您的支持是博主寫作最大的動力,如果您喜歡我的文章,感覺我的文章對您有幫助,請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點擊下面給點支持吧,站長非常感激您!手機微信長按不能支付解決辦法:請將微信支付二維碼保存到相冊,切換到微信,然后點擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對您有幫助就好】元
