前言
在日常開發過程中,Unicode & UTF-8 并不是很受關注的知識,但在閱讀源碼或文章時,出現頻率很高。如果你沒有理解清楚 Unicode、UTF-8、UTF-16 和 UTF-32 之前的關系,會帶來閱讀障礙。在這篇文章里,我將帶你理解 Unicode 字符集的原理,希望能幫上忙。
1. 什么是字符編碼
1.1 什么是字符?
字符(Character) 是對文字和符號的總稱,例如漢字、拉丁字母、emoji 都是字符。在計算機中,一個字符由 2 部分組成:
- 1、用戶看到的圖畫
- 2、字符的編碼
你經常會在很多詞語上看到 “編碼” 這個單詞,對初學者來說很容易混淆。今天我列舉出 “編碼” 常見的 3 層解釋,希望能幫助你以后在閱讀文章時快速理解作者的意思。
- 含義 1 - 作為動詞: 表示把一個字符轉換為一個二進制機器數的過程,這個機器數才是字符在計算機中真實存儲/傳輸的格式。例如把 A 轉換為 65(ASCII) 的動作,就是一個編碼動作;
- 含義 2 - 作為名詞: 表示經過編碼動作后得到的那個機器數,對于 A 來說,65(ASCII) 就是 A 的編碼(值),有時會稱為編號;
- 含義 3 - 作為名詞: 表示把字符轉換為機器數的編碼方案,例如 ASCII 編碼、GBK 編碼、UTF-8 編碼。
1.2 什么是字符集
字符集(Character Set) 是多個字符與字符編碼組成的系統,由于歷史的原因,曾經發展出多種字符集,例如:
字符集一多起來,就容易出現兼容問題: 即同一個字符在不同字符集上對應不同的字符編碼。 例如,最早的 emoji 在日本的一些手機廠商創造并流行起來,使得 emoji 在不同廠商的設備間無法兼容。要想正確解析一個字符編碼,就需要先知道它使用的字符編碼集,否則用錯誤的字符集解讀,就會出現亂碼。想象以下,你發送的一個在女朋友的手機上看到的是另一個 emoji,是一件多么可怕的事情。
2. 認識 Unicode 字符集
2.1 為什么要使用 Unicode 字符集?
為了解決字符集間互不兼容的問題,包羅萬象的 Unicode 字符集出場了。Unicode(統一碼)由非營利組織統一碼聯盟負責,整理了世界上大部分的字符系統,使得計算機可以用更簡單統一的方式來呈現和處理文字。
Unicode 字符集與 ASCII 等字符集相比,在概念上相對復雜一些。我們需要從 2 個維度來理解 Unicode 字符集:編碼標準 + 編碼格式。
2.2 Unicode 編碼標準
關鍵理解 2 個概念:碼點 + 字符平面映射:
-
碼點(Code Point): 從 0 開始編號,每個字符都分配一個唯一的碼點,完整的十六進制格式是
U+[XX]XXXX
,具體可表示的范圍為U+0000 ~ U+10FFFF
(所需要的空間最大為 3 個字節的空間),例如U+0011
。這個范圍可以容納超過 100 萬個字符,足夠容納目前全世界已創造的字符。
-
字符平面(Plane): 這么多字符并不是一次性定義完成的,而是采用了分組的方式。每一個組稱為一個平面,每個平面能夠容納
個字符。Unicode 一共定義了 17 個平面:
- 基本多文種平面(Basic Multilingual Plane, BMP): 第一個平面,包含最常用的通用字符。當然,基本平面并不是填滿的,而是刻意空出一段區域,這個我們下文再說。
- 輔助平面(Supplementary Plane): 剩下的 16 個平面,包含多種語言的字符。
完整的 unicode 碼點列表可以參考:unicode.org
2.3 Unicode 編碼格式
Unicode 本身只定義了字符與碼點的映射關系,相當于定義了一套標準,而這套標準真正在計算機中落地時,則有多種編碼格式。目前常見到的有 3 種編碼格式:UTF-8、UTF-16 和 UTF-32。UTF ****是英文 Unicode Transformation Format 的縮寫,意思是 Unicode 字符轉換為某種格式。
別看編碼格式五花八門,本質上只是出于空間和時間的權衡,對同一套字符標準使用不同的編碼算法而已。 舉個例子,字符 A 的 Unicode 碼點和編碼如下:
- 1、圖像:A
- 2、碼點:U+0041
- 3、UTF-8 編碼:0X41
- 4、UTF-16 編碼:0X0041
- 5、UTF-32 編碼:0X00000041
當你根據 UTF-8、UTF-16 和 UTF-32 的編碼規則進行解碼后,你將得到什么結果呢?是的,它們的結果都是一樣的 —— 0x41。懂了嗎?
3. Unicode 的三實現方式
這一節,我們來討論 Unicode 最常見的三種編碼格式。
3.1 UTF-32 編碼
UTF-32 使用 4 個字節的定長編碼, 前面說到 Unicode 碼點最大需要 3 個字節的空間,這對于 4 個字節 UTF-32 編碼來說就綽綽有余。
- 缺點: 任何一個碼點編碼后都需要 4 個字節的空間,每個字符都會浪費 1~3 個字節的存儲空間;
- 優點: 編解碼規則最簡單,編解碼效率最快。
UTF-32 編碼舉例
U+0000 => 0x00000000
U+6C38 => 0x00006C38
U+10FFFF => 0x0010FFFF
3.2 UTF-16 編碼
UTF-16 是 2 個字節或 4 個字節的變長編碼,結合了 UTF-8 和 UTF-32 兩者的特點。 前面提到 Unicode 碼點最大需要 3 個字節,那么當 UTF-16 使用 2 個字節空間時,豈不是不夠用了?
先說 UTF-16 的編碼規則:
-
規則 1: 基本平面的碼點(編號范圍在
U+0000 ~ U+FFFF
)使用 2 個字節表示。輔助平面的碼點(編號范圍在U+10000 ~ U+10FFFF
的碼點)使用 4 個字節表示; -
規則 2: 16 個輔助平面總共有
個字符,至少需要 20 位的空間才能區分。UTF-16 將這 20 位拆成 2 半:
- 高 10 位映射在
U+D800 ~ U+DBFF
,稱為高位代理(high surrogate); - 低 10 位映射在
U+DC00 ~ U+DFFF
,稱為低位代理(low surrogate)。
- 高 10 位映射在
好復雜,為什么要這么設計?第一條規則比較好理解,1 個平面有最大的編碼是 U+FFFF
,需要用 16 位表示,用 2 個字節表示正好。第二條規則就不好理解了,我們重點說一下。
輔助平面最大的字符是 U+10FFFF
,需要使用 21 位表示,用 4 個字節表示就綽綽有余了,例如說低 16 位 放在低 16 位,高 5 位放在高 16 位(不足位補零)。這樣不是很簡單也很好理解?
不行,因為前綴有歧義。 這種方式會導致輔助平面編碼的每 2 個字節的取值范圍都與基本平面的取值范圍重復,因此,解碼程序在解析一段 UTF-16 編碼的字符流時,就無法區分這 2 個字節是屬于基本平面字符,還是屬于輔助平面字符。
為了解決這個問題,必須實現前綴無歧義編碼(PFC 編碼,類似的還有哈弗曼編碼)。UTF-16 的方案是將用于基本平面字符編碼的取值范圍與輔助平面字符編碼的取值范圍錯開,使得兩者不會出現歧義(沖突)。這么做的前提,就需要在基本平面中提前空出一段區域,這就是上文提到基本平面故意空出一段區域的原因。
如下圖所示,在基礎平面中,淺灰色的 D8 ~ DF
為 UTF-16 代理區:
—— 圖片引用自維基百科
UTF-16 編碼舉例
到這里,UTF-16 的設計思路就說完了,下面就會解釋具體的計算規則,不感興趣可以跳過。
- 1、輔助平面字符的范圍是
U+10000 ~ U+10FFFF
,換句話說,第一個輔助平面字符是U+10000
。那么就可先把每個碼點減去0x10000
,映射到U+0000 ~ U+0AFFFF
,這樣的好處是只需要 20 位就能表示所有輔助平面字符(否則需要 21 位); - 2、20 位正好可以拆分為 2 組:高 10 位作為一組,低 10 位作為一組,則有
- 3、
和
會與基本平面沖突,那么就給它們分別加上一個偏移量,使它們落到基本平面中空出來的代理區(
偏移
0xD800
,low
偏移0xDC00
)。
至此,UTF-16 字符編碼完成。計算公式總結:
w
我們在 Java 源碼中尋找一下這套計算規則,具體在 String 和 Character 中:
String.java
public String(int[] codePoints, int offset, int count) {
// 0. 前處理:參數不合法的情況
final int end = offset + count;
// 1. 計算總共需要的char數組容量
int n = count;
for (int i = offset; i < end; i++) {
int c = codePoints[i];
// 分析點 1.1
if (Character.isBmpCodePoint(c))
continue;
// 分析點 1.2
else if (Character.isValidCodePoint(c))
n++; // 每個輔助平面字符需要多一個char
else throw new IllegalArgumentException(Integer.toString(c));
}
// 2. 分配數組并填充數據
final char[] v = new char[n];
for (int i = offset, j = 0; i < end; i++, j++) {
int c = codePoints[i];
// 分析點 2.1
if (Character.isBmpCodePoint(c))
v[j] = (char)c;
else
// 分析點 2.2
Character.toSurrogates(c, v, j++);
}
// 結束
this.value = v;
}
編碼計算:
Character.java
// 分析點 1.1:判斷碼點是否處于基本平面
public static boolean isBmpCodePoint(int codePoint) {
return codePoint >>> 16 == 0;
}
// 分析點 1.2:判斷碼點是否處于輔助平面
public static boolean isValidCodePoint(int codePoint) {
int plane = codePoint >>> 16;
return plane < ((0x10FFFF + 1) >>> 16);
}
// 分析點 2.2:輔助平面字符 - 規則2
static void toSurrogates(int codePoint, char[] dst, int index) {
// high在高位,low在低位,是大端序
dst[index+1] = lowSurrogate(codePoint);
dst[index] = highSurrogate(codePoint);
}
// 計算高位代理
public static char highSurrogate(int codePoint) {
return (char) ((codePoint >>> 10) + (0xDBFF - (0x010000 >>> 10)));
}
// 計算低位代理
public static char lowSurrogate(int codePoint) {
return (char) ((codePoint & 0x3ff) + 0xDC00);
}
解碼計算:
Character.java
public static int toCodePoint(char high, char low) {
// 源碼有算術表達式優化,此處為等價邏輯
return ((high - 0xD800) << 10) + (low - 0xDC00) + 0x010000;
}
3.3 UTF-8 編碼
UTF-8 是 1~4 個字節的變長編碼,相對來說最節省空間。 下述規則表述與你在任何文章 / 百科里看到的規則表述不一樣,但是邏輯上是一樣的。因為我認為按照 “前綴無歧義” 的概念來理解最易懂。
- 規則 1: 不同范圍的碼點值使用不同長度的編碼;
-
規則 2: 字節編碼總長度為 1 時前綴為
0
、總長度為 2 時前綴為110
、總長度為 3 時前綴為1110
、總長度為 4 時前綴為11110
; -
規則 3: 除了首個字節,字符編碼中其余字節的前綴為
10
。
可以看到,這種編碼方式是不會存在前綴歧義的,也比較好理解。
UTF-8 編碼舉例
因為 UTF-8 編碼相對來說是最節省空間的,因此在很多存儲和傳輸的場景中,都會選擇使用 UTF-8 編碼。例如:
-
1、XML文件的編碼: 在文件頭定義了編碼格式。
<?xml version="1.0" encoding="utf-8"?>
2、Java 字節碼中字符串常量的編碼: 可以看到,Class 文件中的字符串常量是 UTF-8 編碼的,并且長度最大只支持 u2(65535 個字符),這就是在 Java 中定義的變量名標識符或方法名標識符過長(超過 64 KB)將無法通過編譯的根本原因。
類型 | 標識 | 描述 |
---|---|---|
CONSTANT_Utf8_info | 1 | UTF-8 編碼的字符串 |
CONSTANT_String_info | 8 | 字符串類型字面量 |
其中CONSTANT_Utf8_info
常量的結構:
名稱 | 類型 | 數量 |
---|---|---|
tag | u1 | 1 |
length | u2 | 1 |
bytes | u1 | length |
- 3、HTTP報文主體的編碼: ****HTTP 報文首部字段
Content-Type
可以指定字符編碼方式。在 OkHttp 源碼中,當響應報文首部字段 Content-Type 缺省時,默認按 UTF-8 解碼,看源碼:
Http 報文示例
HTTP/1.1 200 OK
... 省略
Content-Type:text/html; charset=UTF-8
[報文主體]
OkHttp 源碼摘要:
ResponseBody.java
public final String string() throws IOException {
BufferedSource source = source();
try {
// 分析點 1
Charset charset = Util.bomAwareCharset(source, charset());
return source.readString(charset);
} finally {
Util.closeQuietly(source);
}
}
// 分析點1:獲得解碼需要的charset
private Charset charset() {
// contentType為null時,使用 UTF_8
MediaType contentType = contentType();
return contentType != null ? contentType.charset(UTF_8) : UTF_8;
}
4. 總結
用一張表總結一下 3 種編碼格式:
ASCII | UTF-8 | UTF-16 | UTF-32 | |
---|---|---|---|---|
編碼空間 | 0~7F | 0~10FFF | 0~10FFF | 0~10FFF |
最小存儲占用 | 1 | 1 | 2 | 4 |
最大存儲占用 | 1 | 4 | 4 | 4 |
參考資料
- Unicode —— 維基百科
- UTF-8, a transformation format of ISO 10646 —— 互聯網工程任務組(IETF)
- UTF-16, a transformation format of ISO 10646 —— 互聯網工程任務組(IETF)
- Unicode Format for Network Interchange —— 互聯網工程任務組(IETF)
- 《編碼·隱匿在計算機軟硬件背后的語言》(第23章) —— [美] Charles Petzold 著
- 隔空傳情: emoji 簡史 —— Google Play
- 字符編碼筆記:ASCII,Unicode 和 UTF-8 —— 阮一峰 著
- Unicode 與 JavaScript詳解 —— 阮一峰 著
- 阮一峰老師文章的常識性錯誤之 Unicode 與 UTF-8 —— 劉志軍 著