「計算機原理」| Unicode 和 UTF-8是什么關系?

前言

在日常開發過程中,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) 是多個字符與字符編碼組成的系統,由于歷史的原因,曾經發展出多種字符集,例如:

Untitled.png

字符集一多起來,就容易出現兼容問題: 即同一個字符在不同字符集上對應不同的字符編碼。 例如,最早的 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): 這么多字符并不是一次性定義完成的,而是采用了分組的方式。每一個組稱為一個平面,每個平面能夠容納 2^{16} = 65536 個字符。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 個輔助平面總共有 2^{20} 個字符,至少需要 20 位的空間才能區分。UTF-16 將這 20 位拆成 2 半:
    • 高 10 位映射在 U+D800 ~ U+DBFF,稱為高位代理(high surrogate);
    • 低 10 位映射在 U+DC00 ~ U+DFFF,稱為低位代理(low surrogate)。

好復雜,為什么要這么設計?第一條規則比較好理解,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 位作為一組,則有 code point = high << 10 + low + 0x10000
  • 3、highlow 會與基本平面沖突,那么就給它們分別加上一個偏移量,使它們落到基本平面中空出來的代理區(high 偏移 0xD800low 偏移 0xDC00)。

至此,UTF-16 字符編碼完成。計算公式總結:

code point = ((high - 0xD800)<< 10 ) + low - 0xDC00 + 0x10000

high = (codepoint - 0x10000) >>>10 + 0xD800

low = (codepoint\ \& \ 0x3FFF) + 0xDC00w


我們在 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

參考資料

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 230,431評論 6 544
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 99,637評論 3 429
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 178,555評論 0 383
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 63,900評論 1 318
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 72,629評論 6 412
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,976評論 1 328
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,976評論 3 448
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 43,139評論 0 290
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 49,686評論 1 336
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 41,411評論 3 358
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 43,641評論 1 374
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 39,129評論 5 364
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,820評論 3 350
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 35,233評論 0 28
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 36,567評論 1 295
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 52,362評論 3 400
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 48,604評論 2 380