前言

在日常开发过程中，Unicode & UTF-8 并不是很受关注的知识，但在阅读源码或文章时，出现频率很高。如果你没有理解清楚 Unicode、UTF-8、UTF-16 和 UTF-32 之前的关系，会带来阅读障碍。在这篇文章里，我将带你理解 Unicode 字符集的原理，希望能帮上忙。

1. 什么是字符编码

1.1 什么是字符？

字符（Character） 是对文字和符号的总称，例如汉字、拉丁字母、emoji 都是字符。在计算机中，一个字符由 2 部分组成：

• 1、字符的编码： 字符在计算机上的存储格式。例如在 ASCII 字符集中，字符 A 的编码就是 65；
• 2、用户看到的图画： 字符的编码经过软件渲染后，呈现给用户的图画。同一个编码，在不同的软件渲染后呈现的图画可以是不同的。披萨的 Unicode 编码是 U+1F355，而在不同的软件渲染的图片可能是不同的。

你经常会在很多词语上看到 “编码” 这个单词，对初学者来说很容易混淆。今天我列举出 “编码” 常见的 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）： 这么多字符并不是一次性定义完成的，而是采用了分组的方式。每一个组称为一个**平面，**每个平面能够容纳 216=655362^{16} = 65536216=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 个辅助平面总共有 2202^{20}220 个字符，至少需要 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 位作为一组，则有 codepoint=high<<10+low+0x10000code point = high << 10 + low + 0x10000codepoint=high<<10+low+0x10000
• 3、highhighhigh 和 lowlowlow 会与基本平面冲突，那么就给它们分别加上一个偏移量，使它们落到基本平面中空出来的代理区（highhighhigh 偏移 0xD800，low 偏移 0xDC00）。

至此，UTF-16 字符编码完成。计算公式总结：

我们在 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常量的结构：

• 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. UTF 的字节序问题

上一节，我们讨论了 Unicode 三种编码格式的编码规则，在实际中还需要考虑多字节数据的排列顺序的因素， 即字节序（Byte Order）：字节序考虑的是多字节编码单元内的字节排列顺序问题，存在大端序和小端序两种，大端序更适合人类解读，而小端序更适合计算机解读。对于以单个字节作为编码单元的数据，不存在字节序问题，例如 ASCII 编码就没有字节序问题。

• 大端字节序（Big Endian）： 高位字节在前，低位字节在后；
• 小端字节序（Little Endian）： 高位字节在后，低位字节在前。

我一开始以为字节序是描述整块数据的排列顺序，比如大端序就是整个文件从头到尾正向排序，而小端序就是整个文件从头到尾逆向排序，这显然是错误的。 字节序描述的是一个编码单元内部的字节顺序，而编码单元永远是正向排序（即大端序）。

举个例子，有数据 0x1122 3344 以每两个字节为一个编码单元，则有：

• 大端序：0x1122 3344
• 小端序：0x2211 4433（不管怎么排列，3344 单元永远在 1122 单元后）

可以看到，大端序这种从高到低（或者从左到右）的排列方式，是更加符合人类的阅读习惯的。相较之下小端序简直反人类，我们要把编码单位内部的数据逆序才能读出正确的数值。那么为什么要设计小端序呢，统一使用大端序不行吗？可以，但是有点反机器：） 因为计算机内部的奇偶校验、加减乘除、比较大小等操作，都是小端序效率更高。 具体我们就展开了，你可以看这篇文章：理解字节序

理解了字节序后，回过头再来看 UniCode 编码加上字节序的要素后，则会存在以下几种分类：

UTF-16 和 UTF-32 不难理解，它们在文件开头使用一个特殊的字符 U+FEFF 作为 BOM（Byte Order Mark）标示文件使用字节序：

• 文件头部的 BOM 是 FEFF ：大端序；
• 文件头部的 BOM 是 FFFE： 小端序；
• 文件头部无 BOM： 默认视为大端序。

U+FEFF 是一个特殊的字符，叫作 Zero With No-Bread Space 零宽度无间断字符 ，它在显示时是看不到的空白字符，但会确保词语在换行时不会中断。例如在 +1 中间插入 U+FEFF，则渲染时可以保证 + 和 1 不会换行，但中间也不会有空格出现，所以叫零宽度无间断字符。

不过， U+FEFF 也不是一直作为零宽度无间断字符使用，如果它处于文件头部，则它会作为 BOM 来标示文本使用的字节序，而不会被当作文本的一部分。只有 U+FEFF 出现在文本中间时，才会被当作零宽度无间断字符使用。为了确保在文件的头部也能够使用零宽度不间断空间，Unicode 3.2 添加了一个新的 U+2060 字符 "WORD JOINER"，具有完全相同的语义，但不会被当作 BOM。

最后一个问题，为什么 UTF-8 不需要区分字节序，而 UTF-16 和 UTF-32 需要区分字节序呢？网上能看到的观点都是说 UTF-16 和 UTF-32 以多字节为编码单元所以需要区分字节序，而 UTF-8 是以单字节作为编码单元，所以不需要区分字节序。 这显然是睁眼说瞎话：），UTF-8 怎么会是单字节编码呢？

我的观点是： 无论使用大端序还是小端序，UTF-16 和 UTF-32 最多只需要解读首个字节就可获得当前字符的编码长度，而 UTF-8 在使用小端序时无法通过首个字节获得当前字符的编码长度。 具体来说，UTF-32 是定长编码，编码长度是固定的；UTF-16 表示 2 字节编码和 4 字节编码使用字节取值范围是错开的，因此只要看一个字节就知道编码长度；而 UTF-8 需要通过首个字符的前缀才能知道编码长度，如果使用小端序的话，计算机需要继续往后读取最多 3 个字节才能知道编码长度，所以小端序就没有意义了，因此 UTF-8 不会存在小端序。

UTF-8 编码使用 BOM EF BB BF 只是标记该文本是 UTF-8 编码，并不是标记字节序。

5. 总结

用一张表总结一下 3 种编码格式：