深入理解「字符編碼模型」

2022 年 8 月 28 日
筆記
CCS, CEF, CES, 字符編碼, 字符編碼模型, 抽象字符集, 軟件開發

深入理解「字符編碼模型」

作者：哲思

時間：2022.8.28

郵箱：[email protected]

GitHub：zhe-si (哲思) (github.com)

前言

最近踩坑了後端的文檔生成，本想寫篇相關的實踐總結，忽然感悟到電子文檔的魅力，尤其以「字符編碼模型」為最，特此進行研究並寫下此文。

不了解Unicode、UTF-8、UTF-16、GBK，搞不清楚碼位、碼元等概念，或者經常遇到亂碼問題的小夥伴都可以在本文找到答案。

簡述字符編碼

相信大家一定對上面的場景不陌生(„ಡωಡ„)，這是一個經典的字符編碼錯誤導致的亂碼問題。而解決的方法也很簡單，在打開文件的時候指定正確的編碼方式即可。如圖中的文本文件 a.txt 採用 utf-8 編碼，指定該編碼方式打開並讀取文本內容如下圖。

解決方案很簡單，但方案背後所蘊含的知識可不簡單，這就是「字符編碼」。眾所周知，一個字符類型(char)長度為 1 位元組，由多個 char 組成的數組（約定以 \0 結尾）就是字符串。問題來了，一個位元組只能表示 \(2^8\) （256）個數字，如何表示百倍於它的漢字呢？上面用到的 utf-8 又是什麼？為什麼不指定它就會亂碼呢？

想要表示漢字很簡單，一個位元組不夠，那再來個位元組呀。用多個位元組表示字符，又涉及具體用幾個位元組、如何高效利用空間、要表示範圍足夠大同時靈活可拓展等問題，因此提出了以 utf-8 為代表的字符編碼的方法來告訴計算機如何解析位元組流並將其轉化為字符流。由於大部分字符編碼的方法不互相兼容，用與編碼時不同的編碼方案解析它自然就會出錯或者解析成錯誤的內容。

下面給出維基百科中的定義：字符編碼（英語：Character encoding）是把字符集中的字符編碼為指定集合中某一對象（例如：比特模式、自然數序列、8位組或者電脈衝），以便文本在計算機中存儲和通過通信網絡的傳遞。

概念可能不夠具體，狹義來說，字符編碼就是將字符（包括英文字母、漢字等）編碼為計算機可以存儲與解析的位元組流形式，同時也支持從位元組流解析回字符的形式。這是對現實生活中用到的文字與符號的建模，將它們用一種計算機可以理解的方式表示，來方便計算機處理。

為了標準化字符編碼的過程，人們對編碼設計的過程進行劃分，提出了字符編碼的抽象架構模型，共有 5 層，分別解決了字符編碼流程中的五個具體細節問題，接下來進行詳細介紹。

字符編碼模型

設計字符編碼，根據先後順序可以分為以下五個步驟：

定義字符集：解決包含的字符範圍的問題，聲明都有哪些字符
編碼字符集：解決如何用數字信號唯一的表示字符集中的每個字符
設計計算機保存字符編碼用哪種數據類型以哪種規則保存：解決如何用某種數據類型描述字符編碼後的數字信號
確定保存字符編碼所用的數據類型如何映射到位元組序列：解決數據類型（用來描述字符編碼的數字信號）在計算機中（用位元組序列）的表示方法
選擇傳輸時合適的位元組序列編碼與壓縮方案：解決描述字符串的位元組序列在傳輸過程中的編碼與壓縮問題

基於上述五個步驟，定義：

\[字符編碼模型 = 抽象字符表+編碼字符集（CCS）+字符編碼表（CEF）+字符編碼方案（CES）+傳輸編碼語法
\]

五層模型

1. 抽象字符表（Abstract character repertoire）

抽象字符表定義了當前的字符編碼所支持的所有抽象字符的集合。

抽象字符是指人從視覺上認為不同而從含義邏輯上認為相同的一組實際字符的集合，可認為該集合中的字符表示的含義相同。一層含義是，一個漢字有楷、行、草、隸等多種形體，但都表示同一個漢字，如下圖。另一層含義是，在 Unicode 中西班牙語的 ñ 由 n 和 ~ 兩個字符組成，雖然看上去是一個，但是兩種不同的含義。

抽象字符表有些標準是封閉性的，抽象字符集合不會改變（包括： ASCII、ISO 8859 系列等）；有些標準是開放性的，可以不斷將新的字符添加到標準中（比如：Unicode）。

2. 編碼字符集（CCS: Coded Character Set）

編碼字符集在第一層抽象字符集的基礎上，為每一個字符分配一個唯一的數字編碼，讓抽象的字符通過數字的方式表示出來。

編碼字符集是一個映射過程，將抽象字符集中的每一個字符一對一的映射到一個坐標（若是一維就是單個整數）上，而每一個映射到的坐標（也就是數字編碼）稱為碼位（也稱碼點），每個字符所佔的碼位稱為碼位值。所以，也可以稱：編碼字符集就是把抽象字符集中的每個抽象字符映射為碼位值。

用來表示碼位的坐標空間的維度稱之為編碼空間，可用一組數字、存儲單元尺寸或者一些特殊形式表示。例如：GB 2312 漢字編碼空間可表示為 94 × 94；ISO-8859-1的編碼空間可表示為 8 比特或 256；Unicode 採用行、列、面的三維描述表示碼位值。

這裡特別講解一下 Unicode（統一碼）的編碼字符集。每個 Unicode 字符編碼可以表示為：U + 6個十六進制數字，比如：’0′ 表示為 ‘\U000030’。Unicode 採用平面 + 16-bit 編碼方式，每個平面的編碼空間為 2^16（用’\U000030‘的後四位表示，使用兩個位元組），共 17 個平面（用’\U000030’的前兩位表示，使用一個位元組），理論上能表示的字符數 = 平面數(17) × 平面編碼空間大小(2^16) = 1114112。17個平面編號為0-16（0x00-0x10），如下圖。

日常中常用的字符都定義在 0 號平面，該平面的碼點表示時可以省略前兩個十六進制位的平面號。平面中不是每個位置都定義了對應的字符，還有不少空間保留或作特殊用途。

每個抽象字符在 Unicode 中採用唯一且不可變的字符名稱來表示，如：拉丁字母 K 在 Unicode 中的字符名稱是「Latin Capital Letter K」，碼點是 004B。

3. 字符編碼表（CEF: Character Encoding Form）

字符編碼表將數字表示的碼位值轉換為整型值序列（由多個固定有限長度的整形數據類型組成）表示。

用來表示碼位的有限長度整形，是計算機表達字符編碼（碼位值）的單位，稱為編碼單元，簡稱碼元。

定義字符編碼表有兩步：

定義碼元
定義如何使用多個碼元表示碼點值的規則

定義碼元通常採用 8 bit（位元組）的倍數。碼元的存在，規整了表示不同字符的存儲方式，避免在一串字符中用各種長度的整形混合表示。在計算機中採用位元組的倍數存儲與處理也匹配其存儲、傳輸和處理的單位，對應計算機中的數據類型。

定義用碼元表示碼位值的規則，分為定長編碼和變長編碼。定長編碼就是自身到自身的映射，如 ASCII 的編碼 0-127，對應 7 bit，直接用 1 位元組表示。UTF-32是 Unicode 對應的定長編碼方案，位元組內容一一對應碼點。

變長編碼基於某種規則將碼位值根據需要映射到不同個數的碼元序列上。

UTF-8

此處以 Unicode 最通用的字符編碼表 UTF-8 進行說明。UTF-8 是 Unicode 的一種邊長編碼，碼元為 8 bit，採用 1 – 4 個碼元（位元組）表示一個字符，根據字符碼位值的不同變換表示長度。編碼規則如下：

Unicode 十六進制碼點範圍	UTF-8 二進制
0000 0000 – 0000 007F	0xxxxxxx
0000 0080 – 0000 07FF	110xxxxx 10xxxxxx
0000 0800 – 0000 FFFF	1110xxxx 10xxxxxx 10xxxxxx
0001 0000 – 0010 FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

對於單個位元組的字符，第一位設為 0，後面的 7 位對應這個字符的 Unicode 碼點。因此，對於英文中的 0 – 127 號字符，與 ASCII 碼完全相同。這意味着 UTF-8 完全兼容過去用 ASCII 編碼的文檔。
對於需要使用 N 個位元組來表示的字符（N > 1），第一個位元組的前 N 位都設為 1，第 N + 1 位設為 0，剩餘的 N – 1 個位元組的前兩位都設位 10，剩下的二進制位則使用這個字符的 Unicode 碼點來填充。

UTF-16

UTF-16 則採用 16bit（兩個位元組）碼元，編碼規則為：基本平面的字符佔用 2 個位元組，輔助平面的字符佔用 4 個位元組。而確定是用一個碼元還是兩個碼元是通過基本平面中 U+D800 – U+DFFF 的編碼留白實現的。

輔助平面的字符位共有 2^20 個，因此表示這些字符至少需要 20 個二進制位。UTF-16 將這 20 個二進制位分成兩半，前 10 位映射在 U+D800 到 U+DBFF（空間大小 2^10），稱為高位（H），後 10 位映射在 U+DC00 到 U+DFFF（空間大小 2^10），稱為低位（L）。這意味着，一個輔助平面的字符，被拆成兩個基本平面的字符表示。

第二層的編碼字符集和該層字符編碼表是多對多關係，一種編碼方式也可應用多種字符集，如：EUC 編碼方式可以用於 GB 2312，也可以用於 JIS X 0208（一種日語字符集編碼標準）；一種字符集何以對應多種編碼方式，如：Unicode 對應UTF-8、UTF-16、UTF-32等編碼方法，如下圖所示。

例如，「漢字」這兩個中文字符的 Unicode 碼位值是 0x6C49 和 0x5B57，可用碼元對應整數類型的數組表示為

4. 字符編碼方案（CES: Character Encoding Scheme）

字符編碼方案將碼元映射到位元組序列。

抽象字符的碼位值可以通過具體數據類型的碼元表示了，但由於這些數據類型可能需要多個位元組才能表示，我們還沒有解決碼元如何用位元組序列表示。碼元映射為位元組序列，也就是將特定的整數類型映射到對應的位元組序列。一般講的就是位元組序，也就是大端和小端（當然，還有一些更複雜的）。

大端：低位地址存放高位數據，高位地址存放低位數據。與人的一般書寫習慣一致，網絡位元組序要求使用大端。

小端：低位地址存放低位數據，高位地址存放高位數據。

如：數字 0x0102，大端存儲為 [0x01, 0x02]，小端存儲為 [0x02, 0x01]。

在編程中，我們大多時候無需關係位元組序，而是直接使用具體的數據類型，位元組序作為操作系統或硬件的內部實現對用戶透明。但是文本不僅需要在本地內存中讀寫，還要再磁盤中存儲並在多個異構系統中傳閱，這就需要保證位元組序一致或者讀取到文本所使用的位元組序。因此，為了表示碼元的位元組序列在讀寫時的一致性，需要定義字符編碼方案。

解決位元組序問題，一般有兩種方案：

強制規定使用某種位元組序。如網絡傳輸強制要求網絡位元組序使用大端序。
使用位元組序標記說明當前使用的位元組序。字符集編碼一般採用這種方案。Unicode 編碼方案中有個叫 BOM（Byte Order Mark）的東西，就是用來做這事的。

當然，對於碼元為單位元組的情況下，不存在位元組序問題，如 UTF-8，這也是 UTF-8 廣泛使用的原因之一。但一些 UTF-8 文件也存在 BOM 頭，但這不是必須的，只是用來標識該文件採用 UTF-8 編碼。

5. 傳輸編碼語法（transfer encoding syntax）

傳輸編碼語法用於處理第四層字符編碼方案提供的位元組序列，主要包括變換傳輸形式和壓縮位元組序列。

變換傳輸形式指將位元組序列的值映射到一套更受限制的值域內，來滿足傳輸環境限制。如：Email傳輸採用Base64或者quoted-printable，都是把8位的位元組編碼為7位長的數據。

壓縮位元組序列就是指一些無損位元組序列壓縮技術。如：LZW或者行程長度編碼。

模型綜述

從整體上看，字符編碼模型是對人類理解的抽象字符到計算機實際表示、存儲和傳輸字符的數據形式的建模過程。

第一層抽象字符表是對人類理解的抽象字符的總結，明確了抽象字符範圍。每個抽象字符可能字形不同（寫法不同），在不同語境下字符表示的含義不同，但從字符本身的角度邏輯相同，並採用字符名稱等方式唯一的標識該字符。

第二層編碼字符集則為抽象字符編號，將抽象字符表示成數學形式，類似模電和數電的關係，因為只有數字才能進一步保存到計算機。但注意，這一層並不涉及計算機，數學編號也是人類意義上的編號，但將形式上的符號抽象為數學編號表示，是用計算機建模現實事務的關鍵一步。

第三層字符編碼形式是真正用計算機表示字符的第一步，這裡採用計算機的抽象數據類型（碼元）來表示人類對字符的抽象描述（數學編碼）。

第四層字符編碼方案則進一步將用計算機的抽象數據類型表示的字符映射到計算機真正的底層表示——位元組流上。到這一層，字符已經完全轉化為計算機的表示方式，計算機可以基於上述模型棧（其順序處理的形式可以理解為棧）對字符進行讀寫或其他操作，並在計算機底層表示和人類的抽象字符間相互轉化。

第五層傳輸編碼語法是對計算機底層數據流額外的附加處理，來提升傳輸效率或滿足傳輸要求。

上述字符編碼模型可以進一步總結為一種計算機建模的通用思想：明確現實事物、建模事物、用計算機數據類型表示、用計算機底層位元組序列表示、對位元組序列的優化處理。

字符與字形

在前面的學習中，我們已經知道了通過字符編碼模型將抽象字符轉換為計算機底層數據結構的過程，好像已經圓滿了。但請你重新審視你正在讀的文字中的字符，並回憶剛剛所學，字符編碼模型是否是完整的一條從你所見的字符到計算機底層表示的鏈路？

沒錯，缺少了字形。在抽象字符集中我們強調，字符集中的字符是邏輯上的抽象字符，而不是我們直接看到的字符，每個字符在不同的書寫方式下都有多種字形表示。那麼，現在是如何表示字形的呢？

字形描述，就是字體。字體描述了字符的形狀，告訴了計算機如何「畫出」某個字符，描述方式一般有散點和矢量。

由於本文重點在字符編碼模型，所以在此不進行更詳細的介紹。

舉個實踐例子

s := "hi你好 "
fmt.Println("runes: ")
for _, r := range s {
	fmt.Printf("%v ", r)
}

fmt.Println("\nbytes: ")
for i := 0; i < len(s); i++ {
	fmt.Printf("%v ", s[i])
}
fmt.Println("\n\nlen(s): ", len(s))

提問，上述 go 代碼的輸出結果是什麼？

runes:
104 105 20320 22909 32             
bytes:                             
104 105 228 189 160 229 165 189 32 
                                   
len(s):  9

你猜對了嗎？😏

這就是一個字符的碼位（rune）和位元組序列的對比使用場景。for-range 遍歷的是字符串中每一個字符的碼位值。而字符串實際採用 byte 數組存儲，通過 len 函數獲取長度已經根據下標的索引都是讀取字符底層的位元組序列表示。也就是說，go 中字符串本質上就是個 byte 數組，正好存儲字符的底層位元組表示，但提供了一個解析 byte 數組為字符的視圖，讓我們可以遍歷讀取字符串中的字符。

python 中，也可以通過編碼和解碼，在字符串和 bytes（位元組數組）間轉換。

後記

字符編碼是電子文檔的基礎，也是編程的基礎。只有了解了字符編碼，才能對最常用的數據類型之一——字符串使用的遊刃有餘。

之後會繼續研究電子文檔，並寫兩篇 pdf、word、xlsx 等場景文檔的生成、修改和底層格式設計的文章。

Tags: CCS CEF CES 字符編碼字符編碼模型抽象字符集軟件開發