Java 字元編碼入門（一）：Unicode 與 UCS 歷史恩怨與標準演進

從 ASCII 到 Unicode/UCS：字元編碼標準演進完整史

理解 Unicode 與 UCS 歷史淵源、16 位元限制與 Surrogate Pair 妥協方案、ISO 10646 31 位元雄心、最終合併統一的過程，建立字元編碼領域的歷史深度視野。

ASCII 與 ISO 擴展家族

• ASCII (ISO-646)：7-bit，128 碼位 (0-127)，英文字母、數字、控制字元
• ISO-8859-* 系列：利用第 8 位擴展 128 碼位 (128-255)
  • ISO-8859-1 (Latin-1)：西歐語言
  • ISO-8859-7：希臘語
  • ... 共 15 部份，各自獨立不相容

Unicode 起源與 16 位元承諾

• 發起：1980 年代多家軟體/出版公司聯盟
• 目標 1：收錄全球所有字元 (漢字、日文、符號、甲骨文...)
• 目標 2：**全採 16 位元編碼** (65,536 碼位) — 此決策深遠影響至今
• 現實打擊：65,536 遠不夠收錄全球字元，但規範已定型普及，無法推倒重來
• 遺留問題：催生 Surrogate Pair 這「蹩腳補丁方案」

ISO 10646 (UCS) 另闢蹊徑

• 1984 年啟動：ISO 標準化組織獨立推動
• 31 位元編碼空間：2^31 碼位，真正容納古今所有字元
• 代號：ISO-10646 (呼應 ASCII 的 ISO-646)
• 後續調整：2^31 過大，雙方協商限制為 ~110 萬碼位

歷史性合併：1991 年統一協議

合併後現況

• Unicode 碼空間擴展至 U+10FFFF
• UCS 永不使用 U+110000 以上碼位
• 「Unicode 只有 65,536 字元」為**過時錯誤認知**
• 現今提及 Unicode 即指代合併後統一標準 (含 UCS)

關鍵歷史遺產

1. UTF-16 為核心編碼：Java、Windows、JavaScript、Qt 等內部採用
2. Surrogate Pair 機制：U+D800-DBFF (高) + U+DC00-DFFF (低) 表示補充字元
3. BMP 特權：前 65,536 字元單一 code unit 表示，效能最佳

結語

Unicode 非完美設計，乃歷史妥協產物。理解其 16 位元承諾破產、Surrogate Pair 補丁、與 UCS 合併統一的演進脈絡，才能深刻掌握現代字元編碼體系的優缺點與陷阱。

1. 上一篇文章： Java 字元編碼入門（二）：編碼字元集與字元集編碼的本質區別
2. 下一篇文章： 即時 Java 第 5 部分：編寫與部署即時 Java 應用程式 - WebSphere Real Time 實戰

Java 相關知識

Java 深度研究：LinkedList 源碼解析 - 雙向循環鏈表核心機制全揭秘

LinkedList 是 Java 集合框架中基於雙向循環鏈

打造 Java 桌面應用原型 (一)：架構設計、封裝部署與需求分析

前言：為何從原型開始？ 大型桌面應用開發常以原型起步，三大核

JVM 類加載機制深度解析：原理、實現與自定義 ClassLoader 實戰

類加載三階段七步驟 加載：查找並導入類二進制數據 (字節碼

JMS 消息傳遞系統構建指南：核心模型、API 與實戰代碼

JMS 核心概念 JMS (Java Message Ser