UTF-8 编码与 MySQL 中的 utf8、utf8mb4

UTF-8编码

UTF-8 是一种变长字节编码方式。对于某一个字符的 UTF-8 编码，如果只有一个字节则其最高二进制位为 0；如果是多字节，其第一个字节从最高位开始，连续的二进制位值为 1 的个数决定了其编码的位数，其余各字节均以10开头。UTF-8 在设计上最多可用到6个字节。

如表：

UTF-8 中可以用来表示字符编码的实际位数最多有 31 位，即上表中 x 所表示的位。除去控制位（每字节开头的10等），这些 x 表示的位与 UNICODE 编码是一一对应的，位高低顺序也相同。

将 UNICODE 转换为 UTF-8 编码时应先去除高位 0，然后根据所剩编码的位数决定所需最小的 UTF-8 编码位数。

UNICODE 兼容 ASCII，只需要一个字节的 UTF-8 编码便可以表示。

示例

以“9月”为例，展示如何实现 UTF-8 编码。

• UTF-8 编码：00111001——UNICODE：39——“9”
• UTF-8 编码：11100110 10011100 10001000——UNICODE：E6 9C 88——“月”

UNICODE 与 UTF-8 转换

汉字“严”为例，已知“严”的 Unicode是 4E25（100 111000 100101），根据上表，4E25 处在第三行的范围内（07FF-FFFF），因此“严”的 UTF-8 编码需要三个字节，即格式是“1110xxxx 10xxxxxx 10xxxxxx”。然后，从“严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。因此“严”的UTF-8编码是“11100100 10111000 10100101”，转换成十六进制就是 E4B8A5。

MySQL 中的 utf8

MySQL 从 4.1 版本开始支持 utf8 编码，而标准的 UTF-8 编码在其之后才正式发布。准确地说，MySQL 中 utf8 的全名应该叫——utf8mb3（max byte 3），其编码的最大字符长度为 3 字节，而三个字节的 UTF-8 最大能编码的 Unicode 字符是 0xFFFF，也就是 Unicode 中的基本多文平面（BMP）。也就是说，任何不在基本多文平面的 Unicode字符，都无法使用MySQL原有的 utf8 字符集存储。

中文基本汉字+基本汉字补充的 Unicode 编码范围为：4E00-9FCB，共计收录 20940个汉字，而扩展 B 编码范围为 20000-2A6D6，扩展 C 为2A700-2B734，扩展 D为 2B740-2B81D，共计 47082 个汉字，以及其他的兼容扩展等。这些编码范围大于 FFFF 的不常用汉字、我们常见的 Emoji 表情（Emoji 是一种特殊的 UNICODE 编码）、任何新增的 Unicode 字符等等，在 MySQL 中并不会完整地存储下来，并导致了整个字段的乱码。

于是在 5.5.3 版本中，MySQL 添加了对 utf8mb4 编码的支持，最大字符长度为四字节，也就是说 utf8mb4 才是我们传统意义上的 UTF-8。然而遗憾的是，在 MySQL 的众多分支版本中，只有 8.0.x 分支中默认开启的是 utfmb4，其他分支默认依然是 utf8 编码。

所以，永远不要在MySQL中使用 utf8，改用 utf8mb4。

MySQL 简史

为什么 MySQL 开发者会让“utf8”失效?我们或许可以从提交日志中寻找答案。

MySQL 从4.1版本开始支持 UTF-8，也就是2003年，而今天使用的 UTF-8 标准(RFC 3629)是随后才出现的。

旧版的 UTF-8 标准(RFC 2279)最多支持每个字符6个字节。2002年3月28日，MySQL开发者在第一个MySQL 4.1预览版中使用了RFC 2279。

同年9月，他们对 MySQL 源代码进行了一次调整：『UTF8 现在最多只支持 3 个字节的序列』。

是谁提交了这些代码?他为什么要这样做?这个问题不得而知。在迁移到 Git 后(MySQL最开始使用的是 BitKeeper)，MySQL 代码库中的很多提交者的名字都丢失了。2003 年 9 月的邮件列表中也找不到可以解释这一变更的线索。

不过我可以试着猜测一下。

2002 年，MySQL 做出了一个决定：如果用户可以保证数据表的每一行都使用相同的字节数，那么 MySQL 就可以在性能方面来一个大提升。为此，用户需要将文本列定义为CHAR，每个CHAR列总是拥有相同数量的字符。如果插入的字符少于定义的数量，MySQL 就会在后面填充空格，如果插入的字符超过了定义的数量，后面超出部分会被截断。

MySQL 开发者在最开始尝试 UTF-8 时使用了每个字符 6 个字节，CHAR(1) 使用 6 个字节，CHAR(2) 使用 12 个字节，并以此类推。

应该说，他们最初的行为才是正确的，可惜这一版本一直没有发布。但是文档上却这么写了，而且广为流传，所有了解 UTF-8 的人都认同文档里写的东西。

不过很显然，MySQL 开发者或厂商担心会有用户做这两件事：

1. 使用 CHAR 定义列(在那时，在 MySQL 中使用 CHAR 会更快，不过从 2005 年以后就不是这样子了)；
2. 将 CHAR 列的编码设置为utf8。

我们猜测是 MySQL 开发者本来想帮助那些希望在空间和速度上双赢的用户，但他们搞砸了 utf8 编码。

所以结果就是没有赢家。那些希望在空间和速度上双赢的用户，当他们在使用utf8的 CHAR 列时，实际上使用的空间比预期的更大，速度也比预期的慢。而想要正确性的用户，当他们使用“utf8”编码时，却无法保存像『😀』这样的字符。

在这个不合法的字符集发布了之后，MySQL 就无法修复它，因为这样需要要求所有用户重新构建他们的数据库。最终，MySQL 在 2010 年重新发了utf8mb4来支持真正的 UTF-8。