Unicode的編碼和實現

大概來說，Unicode編碼系統可分為編碼方式和實現方式兩個層次。

編碼方式

字符是抽象的最小文本單位。它沒有固定的形狀（可能是一個字形），而且沒有值。“A”是一個字符，“€”也是一個字符。字符集是字符的集合。編碼字符集是一個字符集，它為每一個字符分配一個唯一數字。

Unicode 最初設計是作為一種固定寬度的 16 位字符編碼。也就是每個字符占用2個字節。這樣理論上一共最多可以表示216（即65536）個字符。上述16位統一碼字符構成基本多文種平面。基本多文種平面的字符的編碼為U+hhhh，其中每個h代表一個十六進制數字。

很明顯，16 位編碼的所有 65，536 個字符并不能完全表示全世界所有正在使用或曾經使用的字符。于是，Unicode 標準已擴展到包含多達 1，112，064 個字符。那些超出原來的 16 位限制的字符被稱作增補字符。Unicode 標準 2.0 版是第一個包含

啟用增補字符設計的版本，但是，直到 3.1 版才收入第一批增補字符集。

Unicode字符平面映射

目前的Unicode字元分為17組編排，每組稱為平面（Plane），而每平面擁有65536（即216）個代碼點。然而目前只用了少數平面。

增補字符是代碼點在 U+10000 至 U+10FFFF 范圍之間的字符（上述表格中1號平面~16號平面之間的），也就是那些使用原始的 Unicode 的 16 位設計無法表示的字符。從 U+0000 至 U+FFFF 之間的字符集有時候被稱為基本多語言面 （BMP）。因此，每一個 Unicode 字符要么屬于 BMP，要么屬于增補字符。

實現方式

UTF-32、UTF-16 和 UTF-8 是具體的實現方案。Unicode的實現方式不同于編碼方式。一個字符的Unicode編碼是確定的。但是在實際傳輸過程中，由于不同系統平臺的設計不一定一致，以及出于節省空間的目的，對Unicode編碼的實現方式有所不同。Unicode的實現方式稱為Unicode轉換格式（Unicode Transformation Format，簡稱為UTF）。

例如，如果一個僅包含基本7位ASCII字符的Unicode文件，如果每個字符都使用2字節的原Unicode編碼傳輸，其第一字節的8位始終為0。這就造成了比較大的浪費。對于這種情況，可以使用UTF-8編碼，這是一種變長編碼，它將基本7位ASCII字符仍用7位編碼表示，占用一個字節（首位補0）。而遇到與其他Unicode字符混合的情況，將按一定算法轉換，每個字符使用1-3個字節編碼，并利用首位為0或1進行識別。這樣對以7位ASCII字符為主的西文文檔就大幅節省了編碼長度（具體方案參見UTF-8）。類似的，對未來會出現的需要4個字節的輔助平面字符和其他UCS-4擴充字符，2字節編碼的UTF-16也需要通過一定的算法進行轉換。

再如，如果直接使用與Unicode編碼一致（僅限于BMP字符）的UTF-16編碼，由于每個字符占用了兩個字節，在麥金塔電腦（Mac）機和個人電腦上，對字節順序的理解是不一致的。這時同一字節流可能會被解釋為不同內容，如某字符為十六進制編碼4E59，按兩個字節拆分為4E和59，在Mac上讀取時是從低字節開始，那么在Mac OS會認為此4E59編碼為594E，找到的字符為“奎”，而在Windows上從高字節開始讀取，則編碼為U+4E59的字符為“乙”。就是說在Windows下以UTF-16編碼保存一個字符“乙”，在Mac OS環境下打開會顯示成“奎”。此類情況說明UTF-16的編碼順序若不加以人為定義就可能發生混淆，于是在UTF-16編碼實現方式中使用了大端序（Big-Endian，簡寫為UTF-16 BE）、小端序（Little-Endian，簡寫為UTF-16 LE）的概念，以及可附加的字節順序記號解決方案，目前在PC機上的Windows系統和Linux系統對于UTF-16編碼默認使用UTF-16 LE。（具體方案參見UTF-16）

此外Unicode的實現方式還包括UTF-7、Punycode、CESU-8、SCSU、UTF-32、GB18030等，這些實現方式有些僅在一定的國家和地區使用，有些則屬于未來的規劃方式。目前通用的實現方式是UTF-16小端序（LE）、UTF-16大端序（BE）和UTF-8。在微軟公司Windows XP附帶的記事本（Notepad）中，“另存為”對話框可以選擇的四種編碼方式除去非Unicode編碼的ANSI（對于英文系統即ASCII編碼，中文系統則為GB2312或Big5編碼）外，其余三種為“Unicode”（對應UTF-16 LE）、“Unicode big endian”（對應UTF-16 BE）和“UTF-8”。

代碼點、碼位

在字符編碼術語中，碼位或稱編碼位置，即英文的code point或code position，是組成碼空間（或代碼頁）的數值。 例如，ASCII碼包含128個碼位，范圍是016進制到7F16進制，擴展ASCII碼包含256個碼位，范圍是016進制到FF16進制，而Unicode包含1,114,112個碼位，范圍是016進制到10FFFF16進制。Unicode碼空間劃分為17個Unicode字符平面（基本多文種平面，16個輔助平面），每個平面有65,536（= 216）個碼位。因此Unicode碼空間總計是17 × 65,536 = 1,114,112.

代碼單元、碼元

碼元（Code Unit，也稱“代碼單元”）是指一個已編碼的文本中具有最短的比特組合的單元。對于UTF-8來說，碼元是8比特長；對于UTF-16來說，碼元是16比特長；對于UTF-32來說，碼元是32比特長。碼值（Code Value）是過時的用法。
明白了上述兩個概念，我們就可以認為UTF-N（N為8,16,32）干的事就是把Unicode字符集的抽象碼位映射為N位長的整數（即碼元）的序列，用于數據存儲或傳遞。

UTF-32 即將每一個 Unicode 代碼點表示為相同值的 32 位整數。很明顯，它是內部處理最方便的表達方式，但是，如果作為一般字符串表達方式，則要消耗更多的內存。

UTF-16 使用一個或兩個未分配的 16 位代碼單元的序列對 Unicode 代碼點進行編碼。值 U+0000 至 U+FFFF 編碼為一個相同值的 16 位單元。增補字符編碼為兩個代碼單元，第一個單元來自于高代理范圍（U+D800 至 U+DBFF），第二個單元來自于低代理范圍（U+DC00 至 U+DFFF）。這在概念上可能看起來類似于多字節編碼，但是其中有一個重要區別：值 U+D800 至 U+DFFF 保留用于 UTF-16；沒有這些值分配字符作為代碼點。這意味著，對于一個字符串中的每個單獨的代碼單元，軟件可以識別是否該代碼單元表示某個單單元字符，或者是否該代碼單元是某個雙單元字符的第一個或第二單元。這相當于某些傳統的多字節字符編碼來說是一個顯著的改進，在傳統的多字節字符編碼中，字節值 0x41 既可能表示字母“A”，也可能是一個雙字節字符的第二個字節。

UTF-8 使用一至四個字節的序列對編碼 Unicode 代碼點進行編碼。U+0000 至 U+007F 使用一個字節編碼，U+0080 至 U+07FF 使用兩個字節，U+0800 至 U+FFFF 使用三個字節，而 U+10000 至 U+10FFFF 使用四個字節。UTF-8 設計原理為：字節值 0x00 至 0x7F 始終表示代碼點 U+0000 至 U+007F（Basic Latin 字符子集，它對應 ASCII 字符集）。這些字節值永遠不會表示其他代碼點，這一特性使 UTF-8 可以很方便地在軟件中將特殊的含義賦予某些 ASCII 字符。

下表所示為幾個字符不同表達方式的比較：

注：上述編碼中的數字均是十六進制表示的。

總結

以上就是本文關于淺談Java中Unicode的編碼和實現的全部內容，希望對大家有所幫助。如有不足之處，歡迎留言指出。感謝朋友們對本站的支持！

原文鏈接：http://www.cnblogs.com/tsiangleo/p/4433410.html