在 Unicode 普及之前

要了解現實中遇到的各種鳥事，還是得回顧歷史緣由。但歷史遺留下來的東西很多，本文無法花太大的篇幅介紹，只能大略介紹一般人可能會面對的現存字元編碼方式。

文字編碼中影響最深遠的里程碑非 ASCII 莫屬，雖然只是美國自己的國家標準，只因計算機軟硬體基礎建設都出自於美國，所以後來出現的編碼多多少少得考慮一下 ASCII，否則就是自找麻煩（和 ASCII 過不去編碼方式也確實存在，所以 C/C++ 必須提供 digraphs、trigraphs 之類的替代寫法）。

標準的 ASCII 字集可以塞到 7 bit 中，對於一般英語系國家來說夠用了。但是歐洲有很多語言需要在字母上畫撇畫點，東歐和希臘甚至使用完全不同的字母系統，所以後來發展出一些 8 bit 的編碼方式，前 127 碼與 ASCII 相容，但 128 ~ 255 則定義成不同語言的字集，例如 ISO-8859-n 系列。對了，以下講到 byte 都是設定為 8-bit。

中文編碼比起歐美字母文字複雜許多，其中一個很大的問題是中文字集沒有明確的邊界。一般人常用的字不超過五六千、康熙字典收錄四萬七千餘字、各地方言和命理師還可以翻出康熙字典之外的字、發現新化學元素又需要造新字.....　因此也有一派觀點認為，中文採用列舉式字集在大方向上根本錯誤，不過這不是主流意見，現實中使用的字集都還是窮舉。決定字集之後，如何排字序、編字碼又是另一門學問。

正體中文早期在缺乏主導力量的情況下曾呈現「萬碼奔騰」的狀態，各系統內部以自己的「內碼」儲存資料，必須另外公訂「交換碼」以便在不同系統之間交換資訊，台灣的標準交換碼為 CNS 11643（其實還有一個 CCCII，不過生不逢時且遭政治干預，所以使用者多半是圖書館和國外機構）。

在因緣際會之下，Big5 變成了業界公認的內碼，一般情況已經沒有必要刻意使用交換碼了。但 Big5 收錄字集不足一直是個很大的問題，甚至連重要機關首長的名字都必須尷尬地表示成「方方土」、「火宣」。又因 Big5 在很長的一段時間裡只是業界公認，並沒有專責維護機構，當 Big5 字集不敷使用的時候，大抵是廠商或政府機關自行擴充，彼此並不相容。也因 Big5 的侷限性，有些政府單位仍然在使用非 Big5 的內碼，例如戶政和健保使用 EUC-TW，只是一般人不太有機會碰到。

大多數字元編碼在發展的時候，都沒有考慮到與其他編碼相容的問題。隨著時代演進，許多軟體終究要面對不同的文字編碼。一般作業系統的解決之道就是提供不同的內碼表，到底一個碼要代表哪一個字符，取決於該環境採用哪一個內碼表。

Windows 的內碼表稱為 code page，每個內碼表都有個魔術數字代號。大部分內碼表字元都是固定單 byte 寬，例如西歐字母用的 1252。至於亞洲文字的內碼表，微軟使用了一種 Multi-byte character set（MBCS）內碼表。如果一個 byte 值小於 128 則視同 ASCII；若為 128 以上則根據某些規則決定是否要和下一個 byte 合在一起當成一個字。總之就是某些字元使用單 byte，某些字元使用多 byte。微軟支援了若干種 MBCS 內碼表，例如正體中文使用 950，和 Big5 相容；簡體中文使用 936，和 GBK 相容；日文為 932。

MBCS 每個字長度並不統一，對程式設計造成了一些困擾。例如無法直接從 byte 數得知一個字串中有多少字，也不能從任意位置隨機存取字串，只能靠剖析字串來完成這類工作。由於文字處理的基本單位仍然是 byte，有些程式設計師沒注意到 MBCS 組合的規則，往往會把雙 byte 字的一部分看成控制字元或逸出字元；舉例來說，假如有人的名字叫做「許功蓋」，那麼很多程式將無法正常的顯示出他的名字。

基於一些我不太清楚的歷史因素，這類以 byte 為單位、依賴本地內碼表的編碼方式，被某些視窗軟體開發者稱為「ANSI」，儘管這不是 ANSI 規定的。

Unicode

內碼表或許在單一語言的環境下運作良好，但只要在不同語言之間轉換資料許多問題就會浮現。除非知道一段文字使用哪一個內碼表，否則無法保證能正確顯示出來。相信大家應該都有這樣的經驗：開啟了一份怪里怪氣的網頁、電子郵件，然後瘋狂的從十幾種內碼表當中猜測到底該用哪一個。

同一個字碼在不同的內碼表往往代表著不同的字符，但因一次只能使用一個內碼表，所以很難在同一份文件裡顯示多國語言。之前有出現過一些權宜措施，例如某些 Big5 擴充版本利用造字區編入日文假名，雖然表面上看起來是日文，但是和日本人真正使用的內碼完全不同，只能在自己圈子內流通。

終極的解決之道就是建立一個涵蓋所有字符的編碼方式，著手進行這個工作的有 ISO 和 Unicode 兩個組織，最後雙方決定互相合作。

這件浩大的工程始於列舉所需的字集，然後賦予每個字元一個數值碼。光是列舉字集就不是一件容易的事，前面已經提過中文字在列舉上的難處，如果再考慮兩岸三地加日韓使用的漢字，彼此間看起來很像但又有一點點不同，到底要不要視為同一個字符呢？同樣的事情在拉丁語系也有，只不過他們需要吵的字符和我們根本不是同一個數量級。經過一番敲敲打打，最後大家得出了 ISO 10646 通用字符集（Universal Character Set, UCS），而 Unicode 自 2.0 版起，編碼方式完全與 ISO 10646 相對應。

原始的 UCS 設計了 31-bit 的編碼空間，相當於可編 21 億個字碼，但目前 Unicode 只計畫使用 0x10FFFF 以內的範圍，大約為 111.4 萬個字碼。其中每 65,536 個字碼被劃分為一個「平面（Plane）」，總共分為 17 組平面。實際上只有少數平面真正被使用，已編的字碼約在十萬之譜。在 Unicode 中，每個數值碼被稱為「Unicode point」，通常被記作U+<16進制數字>。

現實流通的文字大都落在第 0 平面，也就是 U+0000 ~ U+FFFF 之間，這個範圍剛好可以塞到 2 byte 內。這個平面被稱為「基本多語言平面」，其他的平面則稱為「輔助平面」。

顧名思義，基本多語言平面劃分為多種不同的語言區段，其中 ASCII 順理成章佔據了前 127 個碼。至於東亞國家共用的漢字，也就是所謂的「中日韓越統一表意符號（CJKV Unified Ideographs）」，主要使用 U+4E00 ~ U+9FF；另外 U+3400 ~ U+4DFF 之間做為 CJKV 擴展 A 區，兩區加起來可用的 Unicode point 有 27,648 個，目前兩區都沒有編滿，自 Unicode 推出以來又陸續增補數次。此外還有一些未共用的方塊字，則另外安排。

至於一些極罕用或是還在整理中的漢字，則被安排到第 2 平面的 CJKV 擴展 B、C、D 區。第 1 平面主要放一些現在很少用的拼音文字，包括的古埃及象形文、亞蘭文等等，甚至還有麻將牌。請注意一件事，這些平面的字碼已經超出 16 bit 的表達範圍。

以上所述只是「數值碼」和「符號」如何對應，至於字碼如何儲存、傳輸之類的問題則另外以 Unicode transformation formats（UTF） 規定。在可預見的未來，Unicode/UCS 所有的數值碼都不超過 0x10FFFF，所以最簡單的做法就是直接用一個 32 bit 整數來存放一個字碼，剛好一個蘿蔔一個坑，這個方法稱為 UTF-32 或者 UCS-4。由於一般人不常使用 U+FFFF 外的字，UTF-32 顯得大而不當。

面對現實

前面說了這麼多只是要傳達一件事，Unicode 只是一個編碼方案而不是具體的儲存格式，現實中的 Unicode 會以各種 UTF 和正規形式存在。Windows 和 Java 在一開始選擇了 16-bit 寬字元，因此（不得不）踏上了 UTF-16 之路；Linux 社群大致上選擇了 UTF-8；網路世界幾乎是 UTF-8 的天下。

UTF-8 最大的好處在於使用 8-bit 作為儲存單位，同時對 ASCII 保持良很好的相容性。這表示以標準 ASCII 製作的文件都會自動成為合法的 UTF-8 檔案；既存的 API 都可以繼續用 char* 當介面，只要在內部修改解釋的方式即可。

雖然 UTF-8 表面上會讓其他語言的儲存空間膨脹，但事實上各種檔案格式、傳輸協定都有相當比例的資料量是耗在格式標記上，而這些格式標記多由 ASCII 構成。所以就現實應用來說，UTF-8 整體耗用的空間甚至可能比 UTF-16 還少。如果讀者感興趣的話，可以隨便 unzip 一個 MS Office 2007 或者 LibreOffice 文件，你會得到一群以 UTF-8 編碼的 XML 檔案，觀察一下其中 XML 標籤和實質內容所佔的比例。

UTF-8 的每個字碼可能佔用 1 ~ 4 byte 不等的長度，對程式設計是一件很麻煩的事。和前述的 MBCS 一樣，諸如「計算字數」或者「存取第 n 個字」之類的工作都沒辦法簡單完成。現有的 C/C++ 字串程式庫大都假設一個儲存單位對應一個字碼，更是與此格格不入。

以現在的後見之明看來，採用 UTF-16 似乎也沒有好到哪裡去。早期 16-bit 寬字元確實具有一個儲存單位對應一個字碼的便利性，然而隨著 Unicode 輔助平面啟用、UTF-16 標準化之後，這項優勢漸漸落空了。現在 UTF-16 的優勢勉強可以這麼說：如果你假裝每個字都固定佔 16-bit 寬，那麼有非常高的機率不會遇到意外，我相信很多軟體終其生命周期都不會碰到（很不巧的是，正體中文使用者大概是這個世界上最容易遇到意外的一群人）。

為了實作 UTF-16 而引入的 16-bit 寬字元與既存的程式碼幾乎都不相容，因此所有與文字相關的基礎建設都必須生出一套寬字元版，特別是 C/C++ 這類程式語言（Java 當時是全新設計，所以沒差）。微軟花了十幾年的時間，仍然很難讓所有人都使用寬字元，而且所有 C/C++ 書籍還是從 char 和 std::string 談起。微軟必須同時提供 A 版和 W 版兩套 API，搭配 TCHAR 之類的玩意作為過渡。