談談 Unicode編碼，簡要解釋UCS、UTF、BMP、BOM等名詞

  這是一篇程式設計師寫給程式設計師的趣味讀物。所謂趣味是指可以比較輕鬆地瞭解一些原來不清楚的概念，增進知識，類似於打RPG遊戲的升級。整理這篇文章的動機是兩個問題：

問題一：

使用Windows記事本的“另存為”，可以在GBK、Unicode、Unicode big endian和UTF-8這幾種編碼方式間相互轉換。同樣是txt檔案，Windows是怎樣識別編碼方式的呢？

我很早前就發現Unicode、Unicode big endian和UTF-8編碼的txt檔案的開頭會多出幾個位元組，分別是FF、FE（Unicode）,FE、FF（Unicode big endian）,EF、BB、BF（UTF-8）。但這些標記是基於什麼標準呢？

問題二：

最近在網上看到一個ConvertUTF.c，實現了UTF-32、UTF-16和UTF-8這三種編碼方式的相互轉換。對於Unicode(UCS2)、GBK、UTF-8這些編碼方式，我原來就瞭解。但這個程式讓我有些糊塗，想不起來UTF-16和UCS2有什麼關係。

查了查相關資料，總算將這些問題弄清楚了，順帶也瞭解了一些Unicode的細節。寫成一篇文章，送給有過類似疑問的朋友。本文在寫作時儘量做到通俗易懂，但要求讀者知道什麼是位元組，什麼是十六進位制。

0、big endian和little endian

big endian和little endian是CPU處理多位元組數的不同方式。例如“漢”字的Unicode編碼是6C49。那麼寫到檔案裡時，究竟是將6C寫在前面，還是將49寫在前面？如果將6C寫在前面，就是big endian。如果將49寫在前面，就是little endian。

“endian”這個詞出自《格列佛遊記》。小人國的內戰就源於吃雞蛋時是究竟從大頭(Big-Endian)敲開還是從小頭(Little-Endian)敲開，由此曾發生過六次叛亂，一個皇帝送了命，另一個丟了王位。

我們一般將endian翻譯成“位元組序”，將big endian和little endian稱作“大尾”和“小尾”。

1、字元編碼、內碼，順帶介紹漢字編碼

字元必須編碼後才能被計算機處理。計算機使用的預設編碼方式就是計算機的內碼。早期的計算機使用7位的ASCII編碼，為了處理漢字，程式設計師設計了用於簡體中文的GB2312和用於繁體中文的big5。

GB2312(1980年)一共收錄了7445個字元，包括6763個漢字和682個其它符號。漢字區的內碼範圍高位元組從B0-F7，低位元組從A1-FE，佔用的碼位是72*94=6768。其中有5個空位是D7FA-D7FE。

GB2312支援的漢字太少。1995年的漢字擴充套件規範GBK1.0收錄了21886個符號，它分為漢字區和圖形符號區。漢字區包括21003個字元。

從ASCII、GB2312到GBK，這些編碼方法是向下相容的，即同一個字元在這些方案中總是有相同的編碼，後面的標準支援更多的字元。在這些編碼中，英文和中文可以統一地處理。區分中文編碼的方法是高位元組的最高位不為0。按照程式設計師的稱呼，GB2312、GBK都屬於雙位元組字符集 (DBCS)。

2000年的GB18030是取代GBK1.0的正式國家標準。該標準收錄了27484個漢字，同時還收錄了藏文、蒙文、維吾爾文等主要的少數民族文字。從漢字字彙上說，GB18030在GB13000.1的20902個漢字的基礎上增加了CJK擴充套件A的6582個漢字（Unicode碼0x3400-0x4db5），一共收錄了27484個漢字。

CJK就是中日韓的意思。Unicode為了節省碼位，將中日韓三國語言中的文字統一編碼。GB13000.1就是ISO/IEC 10646-1的中文版，相當於Unicode 1.1。

GB18030的編碼採用單位元組、雙位元組和4位元組方案。其中單位元組、雙位元組和GBK是完全相容的。4位元組編碼的碼位就是收錄了CJK擴充套件A的6582個漢字。 例如：UCS的0x3400在GB18030中的編碼應該是8139EF30，UCS的0x3401在GB18030中的編碼應該是8139EF31。

微軟提供了GB18030的升級包，但這個升級包只是提供了一套支援CJK擴充套件A的6582個漢字的新字型：新宋體-18030，並不改變內碼。Windows 的內碼仍然是GBK。

這裡還有一些細節：

• GB2312的原文還是區位碼，從區位碼到內碼，需要在高位元組和低位元組上分別加上A0。

• 對於任何字元編碼，編碼單元的順序是由編碼方案指定的，與endian無關。例如GBK的編碼單元是位元組，用兩個位元組表示一個漢字。 這兩個位元組的順序是固定的，不受CPU位元組序的影響。UTF-16的編碼單元是word（雙位元組），word之間的順序是編碼方案指定的，word內部的位元組排列才會受到endian的影響。後面還會介紹UTF-16。

• GB2312的兩個位元組的最高位都是1。但符合這個條件的碼位只有128*128=16384個。所以GBK和GB18030的低位元組最高位都可能不是1。不過這不影響DBCS字元流的解析：在讀取DBCS字元流時，只要遇到高位為1的位元組，就可以將下兩個位元組作為一個雙位元組編碼，而不用管低位元組的高位是什麼。

2、Unicode、UCS和UTF

前面提到從ASCII、GB2312、GBK到GB18030的編碼方法是向下相容的。而Unicode只與ASCII相容（更準確地說，是與ISO-8859-1相容），與GB碼不相容。例如“漢”字的Unicode編碼是6C49，而GB碼是BABA。

Unicode也是一種字元編碼方法，不過它是由國際組織設計，可以容納全世界所有語言文字的編碼方案。Unicode的學名是"Universal Multiple-Octet Coded Character Set"，簡稱為UCS。UCS可以看作是"Unicode Character Set"的縮寫。

根據維基百科全書(http://zh.wikipedia.org/wiki/)的記載：歷史上存在兩個試圖獨立設計Unicode的組織，即國際標準化組織（ISO）和一個軟體製造商的協會（unicode.org）。ISO開發了ISO 10646專案，Unicode協會開發了Unicode專案。

在1991年前後，雙方都認識到世界不需要兩個不相容的字符集。於是它們開始合併雙方的工作成果，併為創立一個單一編碼表而協同工作。從Unicode2.0開始，Unicode專案採用了與ISO 10646-1相同的字型檔和字碼。

目前兩個專案仍都存在，並獨立地公佈各自的標準。Unicode協會現在的最新版本是2005年的Unicode 4.1.0。ISO的最新標準是ISO 10646-3:2003。

UCS只是規定如何編碼，並沒有規定如何傳輸、儲存這個編碼。例如“漢”字的UCS編碼是6C49，我可以用4個ascii數字來傳輸、儲存這個編碼；也可以用utf-8編碼:3個連續的位元組E6 B1 89來表示它。關鍵在於通訊雙方都要認可。UTF-8、UTF-7、UTF-16都是被廣泛接受的方案。UTF-8的一個特別的好處是它與ISO-8859-1完全相容。UTF是“UCS Transformation Format”的縮寫。

IETF的RFC2781和RFC3629以RFC的一貫風格，清晰、明快又不失嚴謹地描述了UTF-16和UTF-8的編碼方法。我總是記不得IETF是Internet Engineering Task Force的縮寫。但IETF負責維護的RFC是Internet上一切規範的基礎。

2.1、內碼和code page

目前Windows的核心已經支援Unicode字符集，這樣在核心上可以支援全世界所有的語言文字。但是由於現有的大量程式和文件都採用了某種特定語言的編碼，例如GBK，Windows不可能不支援現有的編碼，而全部改用Unicode。

Windows使用內碼表(code page)來適應各個國家和地區。code page可以被理解為前面提到的內碼。GBK對應的code page是CP936。

微軟也為GB18030定義了code page：CP54936。但是由於GB18030有一部分4位元組編碼，而Windows的內碼表只支援單位元組和雙位元組編碼，所以這個code page是無法真正使用的。

3、UCS-2、UCS-4、BMP

UCS有兩種格式：UCS-2和UCS-4。顧名思義，UCS-2就是用兩個位元組編碼，UCS-4就是用4個位元組（實際上只用了31位，最高位必須為0）編碼。下面讓我們做一些簡單的數學遊戲：

UCS-2有2^16=65536個碼位，UCS-4有2^31=2147483648個碼位。

UCS-4根據最高位為0的最高位元組分成2^7=128個group。每個group再根據次高位元組分為256個plane。每個plane根據第3個位元組分為256行 (rows)，每行包含256個cells。當然同一行的cells只是最後一個位元組不同，其餘都相同。

group 0的plane 0被稱作Basic Multilingual Plane, 即BMP。或者說UCS-4中，高兩個位元組為0的碼位被稱作BMP。

將UCS-4的BMP去掉前面的兩個零位元組就得到了UCS-2。在UCS-2的兩個位元組前加上兩個零位元組，就得到了UCS-4的BMP。而目前的UCS-4規範中還沒有任何字元被分配在BMP之外。

4、UTF編碼

UTF-8就是以8位為單元對UCS進行編碼。從UCS-2到UTF-8的編碼方式如下：

UCS-2編碼(16進位制)	UTF-8 位元組流(二進位制)
0000 - 007F	0xxxxxxx
0080 - 07FF	110xxxxx 10xxxxxx
0800 - FFFF	1110xxxx 10xxxxxx 10xxxxxx

例如“漢”字的Unicode編碼是6C49。6C49在0800-FFFF之間，所以肯定要用3位元組模板了：1110xxxx 10xxxxxx 10xxxxxx。將6C49寫成二進位制是：0110 110001 001001， 用這個位元流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。

讀者可以用記事本測試一下我們的編碼是否正確。需要注意，UltraEdit在開啟utf-8編碼的文字檔案時會自動轉換為UTF-16，可能產生混淆。你可以在設定中關掉這個選項。更好的工具是Hex Workshop。

UTF-16以16位為單元對UCS進行編碼。對於小於0x10000的UCS碼，UTF-16編碼就等於UCS碼對應的16位無符號整數。對於不小於0x10000的UCS碼，定義了一個演算法。不過由於實際使用的UCS2，或者UCS4的BMP必然小於0x10000，所以就目前而言，可以認為UTF-16和UCS-2基本相同。但UCS-2只是一個編碼方案，UTF-16卻要用於實際的傳輸，所以就不得不考慮位元組序的問題。

5、UTF的位元組序和BOM

UTF-8以位元組為編碼單元，沒有位元組序的問題。UTF-16以兩個位元組為編碼單元，在解釋一個UTF-16文字前，首先要弄清楚每個編碼單元的位元組序。例如“奎”的Unicode編碼是594E，“乙”的Unicode編碼是4E59。如果我們收到UTF-16位元組流“594E”，那麼這是“奎”還是“乙”？

Unicode規範中推薦的標記位元組順序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte Order Mark。BOM是一個有點小聰明的想法：

在UCS編碼中有一個叫做"ZERO WIDTH NO-BREAK SPACE"的字元，它的編碼是FEFF。而FFFE在UCS中是不存在的字元，所以不應該出現在實際傳輸中。UCS規範建議我們在傳輸位元組流前，先傳輸字元"ZERO WIDTH NO-BREAK SPACE"。

這樣如果接收者收到FEFF，就表明這個位元組流是Big-Endian的；如果收到FFFE，就表明這個位元組流是Little-Endian的。因此字元"ZERO WIDTH NO-BREAK SPACE"又被稱作BOM。

UTF-8不需要BOM來表明位元組順序，但可以用BOM來表明編碼方式。字元"ZERO WIDTH NO-BREAK SPACE"的UTF-8編碼是EF BB BF（讀者可以用我們前面介紹的編碼方法驗證一下）。所以如果接收者收到以EF BB BF開頭的位元組流，就知道這是UTF-8編碼了。

Windows就是使用BOM來標記文字檔案的編碼方式的。

6、進一步的參考資料

本文主要參考的資料是 "Short overview of ISO-IEC 10646 and Unicode" (http://www.nada.kth.se/i18n/ucs/unicode-iso10646-oview.html)。

我還找了兩篇看上去不錯的資料，不過因為我開始的疑問都找到了答案，所以就沒有看：

1. "Understanding Unicode A general introduction to the Unicode Standard" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter04a)
2. "Character set encoding basics Understanding character set encodings and legacy encodings" (http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=IWS-Chapter03)

我寫過UTF-8、UCS-2、GBK相互轉換的軟體包，包括使用Windows API和不使用Windows API的版本。以後有時間的話，我會整理一下放到我的個人主頁上(http://fmddlmyy.home4u.china.com)。

我是想清楚所有問題後才開始寫這篇文章的，原以為一會兒就能寫好。沒想到考慮措辭和查證細節花費了很長時間，竟然從下午1:30寫到9:00。希望有讀者能從中受益。

附錄1 再說說區位碼、GB2312、內碼和內碼表

有的朋友對文章中這句話還有疑問：
“GB2312的原文還是區位碼，從區位碼到內碼，需要在高位元組和低位元組上分別加上A0。”

我再詳細解釋一下：

“GB2312的原文”是指國家1980年的一個標準《中華人民共和國國家標準 資訊交換用漢字編碼字符集 基本集 GB 2312-80》。這個標準用兩個數來編碼漢字和中文符號。第一個數稱為“區”，第二個數稱為“位”。所以也稱為區位碼。1-9區是中文符號，16-55區是一級漢字，56-87區是二級漢字。現在Windows也還有區位輸入法，例如輸入1601得到“啊”。（這個區位輸入法可以自動識別16進位制的GB2312和10進位制的區位碼，也就是說輸入B0A1同樣會得到“啊”。）

內碼是指作業系統內部的字元編碼。早期作業系統的內碼是與語言相關的。現在的Windows在系統內部支援Unicode，然後用內碼表適應各種語言，“內碼”的概念就比較模糊了。微軟一般將預設內碼表指定的編碼說成是內碼。

內碼這個詞彙，並沒有什麼官方的定義，內碼表也只是微軟這個公司的叫法。作為程式設計師，我們只要知道它們是什麼東西，沒有必要過多地考證這些名詞。

Windows中有預設內碼表的概念，即預設用什麼編碼來解釋字元。例如Windows的記事本打開了一個文字檔案，裡面的內容是位元組流：BA、BA、D7、D6。Windows應該去怎麼解釋它呢？

是按照Unicode編碼解釋、還是按照GBK解釋、還是按照BIG5解釋，還是按照ISO8859-1去解釋？如果按GBK去解釋，就會得到“漢字”兩個字。按照其它編碼解釋，可能找不到對應的字元，也可能找到錯誤的字元。所謂“錯誤”是指與文字作者的本意不符，這時就產生了亂碼。

答案是Windows按照當前的預設內碼表去解釋文字檔案裡的位元組流。預設內碼表可以通過控制面板的區域選項設定。記事本的另存為中有一項ANSI，其實就是按照預設內碼表的編碼方法儲存。

Windows的內碼是Unicode，它在技術上可以同時支援多個內碼表。只要檔案能說明自己使用什麼編碼，使用者又安裝了對應的內碼表，Windows就能正確顯示，例如在HTML檔案中就可以指定charset。

有的HTML檔案作者，特別是英文作者，認為世界上所有人都使用英文，在檔案中不指定charset。如果他使用了0x80-0xff之間的字元，中文Windows又按照預設的GBK去解釋，就會出現亂碼。這時只要在這個html檔案中加上指定charset的語句，例如：
<meta http-equiv="Content-Type" content="text/html; charset=ISO8859-1">
如果原作者使用的內碼表和ISO8859-1相容，就不會出現亂碼了。

再說區位碼，啊的區位碼是1601，寫成16進位制是0x10,0x01。這和計算機廣泛使用的ASCII編碼衝突。為了相容00-7f的ASCII編碼，我們在區位碼的高、低位元組上分別加上A0。這樣“啊”的編碼就成為B0A1。我們將加過兩個A0的編碼也稱為GB2312編碼，雖然GB2312的原文根本沒提到這一點。

文章二，本文轉載自:http://www.donews.net/holen/archive/2004/11/30/188182.aspx

Unicode:

unicode.org制定的編碼機制, 要將全世界常用文字都函括進去.
在1.0中是16位編碼, 由U+0000到U+FFFF. 每個2byte碼對應一個字元; 在2.0開始拋棄了16位限制, 原來的16位作為基本位平面, 另外增加了16個位平面, 相當於20位編碼, 編碼範圍0到0x10FFFF.

UCS:

ISO制定的ISO10646標準所定義的 Universal Character Set, 採用4byte編碼.

Unicode與UCS的關係:

ISO與unicode.org是兩個不同的組織, 因此最初制定了不同的標準; 但自從unicode2.0開始, unicode採用了與ISO 10646-1相同的字型檔和字碼, ISO也承諾ISO10646將不會給超出0x10FFFF的UCS-4編碼賦值, 使得兩者保持一致.

UCS的編碼方式:

UCS-2, 與unicode的2byte編碼基本一樣.
UCS-4, 4byte編碼, 目前是在UCS-2前加上2個全零的byte.

UTF: Unicode/UCS Transformation Format
----------------------------------------------------------原文------------------------------------------------------------------------------------ UTF-8, 8bit編碼, ASCII不作變換, 其他字元做變長編碼, 每個字元1-3 byte. 通常作為外碼. 有以下優點:
* 與CPU位元組順序無關, 可以在不同平臺之間交流
* 容錯能力高, 任何一個位元組損壞後, 最多隻會導致一個編碼碼位損失, 不會鏈鎖錯誤(如GB碼錯一個位元組就會整行亂碼)
UTF-16, 16bit編碼, 是變長碼, 大致相當於20位編碼, 值在0到0x10FFFF之間, 基本上就是unicode編碼的實現. 它是變長碼, 與CPU字序有關, 但因為最省空間, 常作為網路傳輸的外碼.

----------------------------------------------------------原文------------------------------------------------------------------------------------
----------------------------------------------------------糾正後------------------------------------------------------------------------------------

UTF-8, 8bit編碼, ASCII不作變換, 其他字元做變長編碼, 每個字元1-3 byte. 通常作為外碼. 有以下優點:
* 與CPU位元組順序無關, 可以在不同平臺之間交流
* 容錯能力高, 任何一個位元組損壞後, 最多隻會導致一個編碼碼位損失, 不會鏈鎖錯誤(如GB碼錯一個位元組就會整行亂碼)
UTF-16, 16bit編碼, 是定長碼,  基本上就是unicode編碼的實現. 與CPU字序有關

----------------------------------------------------------糾正後-----------------------------------------------------------------------------------

UTF-16是unicode的preferred encoding.
UTF-32, 僅使用了unicode範圍(0到0x10FFFF)的32位編碼, 相當於UCS-4的子集.

UTF與unicode的關係:

Unicode是一個字符集, 可以看作為內碼.
而UTF是一種編碼方式, 它的出現是因為unicode不適宜在某些場合直接傳輸和處理. UTF-16直接就是unicode編碼, 沒有變換, 但它包含了0x00在編碼內, 頭256位元組碼的第一個byte都是0x00, 在作業系統(C語言)中有特殊意義, 會引起問題. 採用UTF-8編碼對unicode的直接編碼作些變換可以避免這問題, 並帶來一些優點.

中國國標編碼:
GB 13000: 完全等同於ISO 10646-1/Unicode 2.1, 今後也將隨ISO 10646/Unicode的標準更改而同步更改.
GBK: 對GB2312的擴充, 以容納GB2312字符集範圍以外的Unicode 2.1的統一漢字部分, 並且增加了部分unicode中沒有的字元.
GB 18030-2000: 基於GB 13000, 作為Unicode 3.0的GBK擴充套件版本, 覆蓋了所有unicode編碼, 地位等同於UTF-8, UTF-16, 是一種unicode編碼形式. 變長編碼, 用單位元組/雙位元組/4位元組對字元編碼. GB18030向下相容GB2312/GBK.
GB 18030是中國所有非手持/嵌入式計算機系統的強制實施標準.

-------------------------------

什麼是 UCS 和 ISO 10646?

國際標準 ISO 10646 定義了 通用字符集 (Universal Character Set, UCS). UCS 是所有其他字符集標準的一個超集. 它保證與其他字符集是雙向相容的. 就是說, 如果你將任何文字字串翻譯到 UCS格式, 然後再翻譯回原編碼, 你不會丟失任何資訊.

UCS 包含了用於表達所有已知語言的字元. 不僅包括拉丁語,希臘語, 斯拉夫語,希伯來語,阿拉伯語,亞美尼亞語和喬治亞語的描述, 還包括中文, 日文和韓文這樣的象形文字, 以及 平假名, 片假名, 孟加拉語, 旁遮普語果魯穆奇字元(Gurmukhi), 泰米爾語, 印.埃納德語(Kannada), Malayalam, 泰國語, 寮國語, 漢語拼音(Bopomofo), Hangul, Devangari, Gujarati, Oriya, Telugu 以及其他數也數不清的語. 對於還沒有加入的語言, 由於正在研究怎樣在計算機中最好地編碼它們, 因而最終它們都將被加入. 這些語言包括 Tibetian, 高棉語, Runic(古代北歐文字), 衣索比亞語, 其他象形文字, 以及各種各樣的印-歐語系的語言, 還包括挑選出來的藝術語言比如 Tengwar, Cirth 和 克林貢語(Klingon). UCS 還包括大量的圖形的, 印刷用的, 數學用的和科學用的符號, 包括所有由 TeX, Postscript, MS-DOS，MS-Windows, Macintosh, OCR 字型, 以及許多其他字處理和出版系統提供的字元.

ISO 10646 定義了一個 31 位的字符集. 然而, 在這巨大的編碼空間中, 迄今為止只分配了前 65534 個碼位 (0x0000 到 0xFFFD). 這個 UCS 的 16位子集稱為 基本多語言面 (Basic Multilingual Plane, BMP). 將被編碼在 16 位 BMP 以外的字元都屬於非常特殊的字元(比如象形文字), 且只有專家在歷史和科學領域裡才會用到它們. 按當前的計劃, 將來也許再也不會有字元被分配到從 0x000000 到 0x10FFFF 這個覆蓋了超過 100 萬個潛在的未來字元的 21 位的編碼空間以外去了. ISO 10646-1 標準第一次發表於 1993 年, 定義了字符集與 BMP 中內容的架構. 定義 BMP 以外的字元編碼的第二部分 ISO 10646-2 正在準備中, 但也許要過好幾年才能完成. 新的字元仍源源不斷地加入到 BMP 中, 但已經存在的字元是穩定的且不會再改變了.

UCS 不僅給每個字元分配一個程式碼, 而且賦予了一個正式的名字. 表示一個 UCS 或 Unicode 值的十六進位制數, 通常在前面加上 "U+", 就象 U+0041 代表字元"拉丁大寫字母A". UCS 字元 U+0000 到 U+007F 與 US-ASCII(ISO 646) 是一致的, U+0000 到 U+00FF 與 ISO 8859-1(Latin-1) 也是一致的. 從 U+E000 到 U+F8FF, 已經 BMP 以外的大範圍的編碼是為私用保留的.

什麼是組合字元?

UCS裡有些編碼點分配給了 組合字元.它們類似於打字機上的無間隔重音鍵. 單個的組合字元不是一個完整的字元. 它是一個類似於重音符或其他指示標記, 加在前一個字元後面. 因而, 重音符可以加在任何字元後面. 那些最重要的被加重的字元, 就象普通語言的正字法(orthographies of common languages)裡用到的那種, 在 UCS 裡都有自己的位置, 以確保同老的字符集的向後相容性. 既有自己的編碼位置, 又可以表示為一個普通字元跟隨一個組合字元的被加重字元, 被稱為 預作字元(precomposed characters). UCS 裡的預作字元是為了同沒有預作字元的舊編碼, 比如 ISO 8859, 保持向後相容性而設的. 組合字元機制允許在任何字元後加上重音符或其他指示標記, 這在科學符號中特別有用, 比如數學方程式和國際音標字母, 可能會需要在一個基本字元後組合上一個或多個指示標記.

組合字元跟隨著被修飾的字元. 比如, 德語中的母音變音字元 ("拉丁大寫字母A 加上分音符"), 既可以表示為 UCS 碼 U+00C4 的預作字元, 也可以表示成一個普通 "拉丁大寫字母A" 跟著一個"組合分音符":U+0041 U+0308 這樣的組合. 當需要堆疊多個重音符, 或在一個基本字元的上面和下面都要加上組合標記時, 可以使用多個組合字元. 比如在泰國文中, 一個基本字元最多可加上兩個組合字元.

什麼是 UCS 實現級別?

不是所有的系統都需要支援象組合字元這樣的 UCS 裡所有的先進機制. 因此 ISO 10646 指定了下列三種實現級別:

級別1

不支援組合字元和 Hangul Jamo 字元 (一種特別的, 更加複雜的韓國文的編碼, 使用兩個或三個子字元來編碼一個韓文音節)

級別2

類似於級別1, 但在某些文字中, 允許一列固定的組合字元 (例如, 希伯來文, 阿拉伯文, Devangari, 孟加拉語, 果魯穆奇語, Gujarati, Oriya, 泰米爾語, Telugo, 印.埃納德語, Malayalam, 泰國語和寮國語). 如果沒有這最起碼的幾個組合字元, UCS 就不能完整地表達這些語言.

級別3

支援所有的 UCS 字元, 例如數學家可以在任意一個字元上加上一個 tilde(顎化符號,西班牙語字母上面的～)或一個箭頭(或兩者都加).

什麼是 Unicode?

歷史上, 有兩個獨立的, 創立單一字符集的嘗試. 一個是國際標準化組織(ISO)的 ISO 10646 專案, 另一個是由(一開始大多是美國的)多語言軟體製造商組成的協會組織的 Unicode 專案. 幸運的是, 1991年前後, 兩個專案的參與者都認識到, 世界不需要兩個不同的單一字符集. 它們合併雙方的工作成果, 併為創立一個單一編碼表而協同工作. 兩個專案仍都存在並獨立地公佈各自的標準, 但 Unicode 協會和 ISO/IEC JTC1/SC2 都同意保持 Unicode 和 ISO 10646 標準的碼錶相容, 並緊密地共同調整任何未來的擴充套件.

那麼 Unicode 和 ISO 10646 不同在什麼地方?

Unicode 協會公佈的 Unicode 標準 嚴密地包含了 ISO 10646-1 實現級別3的基本多語言面. 在兩個標準裡所有的字元都在相同的位置並且有相同的名字.

Unicode 標準額外定義了許多與字元有關的語義符號學, 一般而言是對於實現高質量的印刷出版系統的更好的參考. Unicode 詳細說明了繪製某些語言(比如阿拉伯語)表達形式的演算法, 處理雙向文字(比如拉丁與希伯來文混合文字)的演算法和 排序與字串比較 所需的演算法, 以及其他許多東西.

另一方面, ISO 10646 標準, 就象廣為人知的 ISO 8859 標準一樣, 只不過是一個簡單的字符集表. 它指定了一些與標準有關的術語, 定義了一些編碼的別名, 幷包括了規範說明, 指定了怎樣使用 UCS 連線其他 ISO 標準的實現, 比如 ISO 6429 和 ISO 2022. 還有一些與 ISO 緊密相關的, 比如 ISO 14651 是關於 UCS 字串排序的.

考慮到 Unicode 標準有一個易記的名字, 且在任何好的書店裡的 Addison-Wesley 裡有, 只花費 ISO 版本的一小部分, 且包括更多的輔助資訊, 因而它成為使用廣泛得多的參考也就不足為奇了. 然而, 一般認為, 用於列印 ISO 10646-1 標準的字型在某些方面的質量要高於用於列印 Unicode 2.0的. 專業字型設計者總是被建議說要兩個標準都實現, 但一些提供的樣例字形有顯著的區別. ISO 10646-1 標準同樣使用四種不同的風格變體來顯示錶意文字如中文, 日文和韓文 (CJK), 而 Unicode 2.0 的表裡只有中文的變體. 這導致了普遍的認為 Unicode 對日本使用者來說是不可接收的傳說, 儘管是錯誤的.

什麼是 UTF-8?

首先 UCS 和 Unicode 只是分配整數給字元的編碼表. 現在存在好幾種將一串字元表示為一串位元組的方法. 最顯而易見的兩種方法是將 Unicode 文字儲存為 2 個 或 4 個位元組序列的串. 這兩種方法的正式名稱分別為 UCS-2 和 UCS-4. 除非另外指定, 否則大多數的位元組都是這樣的(Bigendian convention). 將一個 ASCII 或 Latin-1 的檔案轉換成 UCS-2 只需簡單地在每個 ASCII 位元組前插入 0x00. 如果要轉換成 UCS-4, 則必須在每個 ASCII 位元組前插入三個 0x00.

在 Unix 下使用 UCS-2 (或 UCS-4) 會導致非常嚴重的問題. 用這些編碼的字串會包含一些特殊的字元, 比如 '/0' 或 '/', 它們在 檔名和其他 C 庫函式引數裡都有特別的含義. 另外, 大多數使用 ASCII 檔案的 UNIX 下的工具, 如果不進行重大修改是無法讀取 16 位的字元的. 基於這些原因, 在檔名, 文字檔案, 環境變數等地方, UCS-2 不適合作為 Unicode 的外部編碼.

在 ISO 10646-1 Annex R 和 RFC 2279 裡定義的 UTF-8 編碼沒有這些問題. 它是在 Unix 風格的作業系統下使用 Unicode 的明顯的方法.

UTF-8 有一下特性:

• UCS 字元 U+0000 到 U+007F (ASCII) 被編碼為位元組 0x00 到 0x7F (ASCII 相容). 這意味著只包含 7 位 ASCII 字元的檔案在 ASCII 和 UTF-8 兩種編碼方式下是一樣的.
• 所有 >U+007F 的 UCS 字元被編碼為一個多個位元組的串, 每個位元組都有標記位集. 因此, ASCII 位元組 (0x00-0x7F) 不可能作為任何其他字元的一部分.
• 表示非 ASCII 字元的多位元組串的第一個位元組總是在 0xC0 到 0xFD 的範圍裡, 並指出這個字元包含多少個位元組. 多位元組串的其餘位元組都在 0x80 到 0xBF 範圍裡. 這使得重新同步非常容易, 並使編碼無國界, 且很少受丟失位元組的影響.
• 可以編入所有可能的 2³¹個 UCS 程式碼
• UTF-8 編碼字元理論上可以最多到 6 個位元組長, 然而 16 位 BMP 字元最多隻用到 3 位元組長.
• Bigendian UCS-4 位元組串的排列順序是預定的.
• 位元組 0xFE 和 0xFF 在 UTF-8 編碼中從未用到.

下列位元組串用來表示一個字元. 用到哪個串取決於該字元在 Unicode 中的序號.

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-00200000 - U-03FFFFFF:	111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx
U-04000000 - U-7FFFFFFF:	1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx 的位置由字元編碼數的二進位制表示的位填入. 越靠右的 x 具有越少的特殊意義. 只用最短的那個足夠表達一個字元編碼數的多位元組串. 注意在多位元組串中, 第一個位元組的開頭"1"的數目就是整個串中位元組的數目.

例如: Unicode 字元 U+00A9 = 1010 1001 (版權符號) 在 UTF-8 裡的編碼為:

11000010 10101001 = 0xC2 0xA9

而字元 U+2260 = 0010 0010 0110 0000 (不等於) 編碼為:

11100010 10001001 10100000 = 0xE2 0x89 0xA0

這種編碼的官方名字拼寫為 UTF-8, 其中 UTF 代表 UCS Transformation Format. 請勿在任何文件中用其他名字 (比如 utf8 或 UTF_8) 來表示 UTF-8, 當然除非你指的是一個變數名而不是這種編碼本身.

什麼程式語言支援 Unicode?

在大約 1993 年之後開發的大多數現代程式語言都有一個特別的資料型別, 叫做 Unicode/ISO 10646-1 字元. 在 Ada95 中叫 Wide_Character, 在 Java 中叫 char.

ISO C 也詳細說明了處理多位元組編碼和寬字元 (wide characters) 的機制, 1994 年 9 月 Amendment 1 to ISO C 發表時又加入了更多. 這些機制主要是為各類東亞編碼而設計的, 它們比處理 UCS 所需的要健壯得多. UTF-8 是 ISO C 標準呼叫多位元組字串的編碼的一個例子, wchar_t 型別可以用來存放 Unicode 字元.