写在前面

不知道你在学习字符编码的时候,会不会被网上的文章,书上的教诲搞的晕头转向?有时他们看似自洽,却又自己打自己脸。有些文章中说,Unicode 只要 16 位 (2字节)就可以表示,但是 UTF-8 的长度为 1-3 字节,为什么我们要用更长的 UTF-8 呢?另外一些文章又说,Unicode 扩充为 16 个平面,以表达更多的字符,那扩充之后还是2字节表示吗? Java 的 char 还是 16 位,怎么和 Unicode 的字符兼容呢?Unicode 的 16 平面要怎么表示呢?还有一些问题,比如 UTF-8 3 字符够用吗?为什么 Mysql 要有 utf8mb4 格式呢?Java String 可以表示所有 Unicode 字符吗?这些其实都是我以前学习的时候想过的问题。如果你在互联网翻阅过足够多的文章,那么,很有可能按下葫芦浮起瓢,这个问题没解决,那个问题又出来。我在这篇文章里面试图用简单的自洽的逻辑,来梳理一下字符编码。

字符编码

简单来说,字符编码的本质建立整数和字符的映射。从而使得字符可以在计算机内以整数的形式表示,方便传输。比如,我们可以定义 ‘a’ = 1,’b’ = 2,’c’ = 3,就是在进行字符编码。

当然,我们自己定的标准没人会遵守。国际上对字符编码的标准主要有两个,分别是 ASCII 和 Unicode,由于 Unicode 是 ASCII 的超集,所以 Unicode 是事实上的字符编码国际标准

所以这意味着什么呢?意味着,每个整数都可能代表一个字符,所以对于字符来说,整数本身就是一种资源,开发完就没有了。

ASCII

ASCII(American Standard Code for Information Interchange,美国信息交换标准代码)是最早的通行标准,规定了 0-127 的对应的字符。这里节选了一部分。

image.png | left | 503x293

Unicode

Unicode 中文翻译也叫统一码、万国码、单一码。Unicode 首先承认了 ASCII 占用 0-127 整数资源的合法性,之后又一次占用了 128-65535 的整数资源,有了这么多的整数资源,我们就可以把世界各种文字的每一种字符分配一个整数来表示了。比如‘中’这个字符,Unicode 就把整数 20013(十六进制表示为4E2D) 分配给他了。

之后,Unicode 联盟发现 65536 个整数也不够分配的,于是就索性一次性又把之后的16个65536的数字即 65536-1114111 的整数资源给占了(谁叫他家里有矿呢),然后把多占的16个65536的段分别命名为16个平面,加上原来的 0-65535 平面,Unicode 总共有 17 个平面。比如第1平面就是 65536-131072当然,到目前为止,还只分配了 7 个平面出去。不过保不准将来还有外星人语言加入,可能17个平面也不够用,再申请整数资源也是情理之中。

65535之后分配的字符大多数是 emoji 表情,比如 😺 是 127850(1F36A)

image.png | left | 463x180

所以,重点是什么呢?重点就是 Unicode 没有所谓的占用多少字节一说。因为 Unicode 本质上是整数,问你 Unicode 占用多少个字节,就等于问你存整数占用多少个字节。我们要用多少字节表示整数,完全取决于整数本身是多大。比如现在 int 是 32位,可以存 0 - 2^31 这么多整数。而 long 则可以存 0-2^63 这么多。理论上,对于17个平面的 Unicode 要完整一次性表达,我们需要 20 位就可以了,如果只要表达一个 Unicode 平面,则只要 16 位。如果只要表达前128位,则只需要8位空间。

字符串表达

我们前面知道了字符编码是字符对数字的映射,那么,我们要怎么表达一个字符串呢?

char[]

内存中,一般通过 char数组 来保存字符串的每个字符。每个char就是对应一个 Unicode 整数,然而,不同语言对于 char 的长度规定却不一样,比如 Java 定义 char 只有 16 位,所以只能表达 Unicode 0-65535 之间的字符,后面的字符就无法表示了。

Java 的 String 也是基于 char[] ,那么是不是意味着 Java 的 String 不能含有 65535 之后的 Unicode 字符呢?不是的。Java 在处理字符串 String 时,并不是完全按照原始的 char[] 来保存每个字符,对于65535之后的字符会启用两个 char 对应一个字符。所以,正确遍历 Java String 的方法是用 String#codePoints() ,Java 把所有字符串转换成了一个 IntStream,所以 String 的底层虽然是 char[],但是实际上,你可以把它理解为 int[] 。所以,往 String 里面存取 65535 之后的字符是没有问题的。但是你如果直接用 String#toCharArray 就有大问题,因为有的字符实际上用了两个 char 来表示。

1
2
3
StringBuffer sb = new StringBuffer();
sb.append(Character.toChars(127850));
System.out.println(sb); // 输出 😺

定长组合分割

数组的方式一般只能在内存中使用,我们要传输或保存一个字符串,则需要转成字节流的格式。

我们假设定义一个编码标准 ‘a’ = 0,’b’ = 1,’c’ = 10,那我要表达 abc ,最无误的方法是用数组[0,1,10] 。要转成字节流,一种自然的方法是直接拼成 0110,但是到时候再想变回数组的时候,就无法正确分割了。对于这个问题,有定长和不定长两种思路。

定长的思路就是先规定我一次截取多少个字节作为一个字符,比如对于上面的例子,我规定这个分割长度为2,那么,在组合时,应该拼成 000110 ,就可以直接把原来的 [0,1,10] 读取出来。

UTF-16

UTF-16 直接规定这个分割长度为每字符16位,所以,这意味着只能表示 0-65535 的 Unicode 字符,之后的就不能表达了。
比如 “中国”的 Unicode 分别是 20013 和 22269
我们用 UTF-16 就是把上面的十进制转成16位的二进制,直接拼接在一起,读取的时候一次读16位
01001110 00101101 01010110 11111101

GBK

GBK全称汉字内码扩展规范,和UTF-16很像,也是以16位为单位进行合并和切割,但是,除了 0-127 继承了 ASCII 外,具体的128-65535的数字分配和 Unicode 则完全不一致(毕竟要有中国特色)。所以,只用分配中日韩文字的话,那就随便我们怎么玩都行,只要不超过 65536 个,都没有问题。

比如“中国”,GBK码分别是 54992 47610 ,转换二进制后和 UTF-16 格式一致。

不定长 UTF-8

定长组合分割优点是简单,缺点是需要定义一个单位长度,在表示ASCII的时候会补很多个0浪费空间。而且无法应对将来数字长度扩容时候错误分割的问题。

这就是 UTF-8 为什么诞生的原因。UTF-8 直接用开头几位告诉你这个整数的位数,再把整数自身告诉你,这样就可以应对 Unicode 扩容的问题。同时,又可以减少占位符 0 的使用。

UTF-8 已经事实上成为字符串表达的通用标准。因为他可以适应 Unicode 的变化。提供可伸缩的表达方法。

具体的规则如下:
1)对于单字节的符号,字节的第一位设为0,后面7位为这个符号的unicode码。因此对于英语字母,UTF-8编码和ASCII码是相同的。
2)对于n字节的符号(n>1),第一个字节的前n位都设为1,第n+1位设为0,后面字节的前两位一律设为10。剩下的没有提及的二进制位,全部为这个符号的unicode码。

这还跟 TCP 传输字节流的分片原理有点像。

具体的规则如下:

Unicode 符号范围UTF-8 编码方式 (二进制)
0-1270xxxxxxx
128-2047110xxxxx 10xxxxxx
2048-655351110xxxx 10xxxxxx 10xxxxxx
65536-111411111110xxx 10xxxxxx 10xxxxxx 10xxxxxx

xxx 则是该字符的整数二进制表示。

如:
的 Unicode 是 20005 (4E25)100111000100101),根据上表,可以发现20005处在第三行的范围内,因此的 UTF-8 编码需要三个字节,即格式是1110xxxx 10xxxxxx 10xxxxxx。然后,从的最后一个二进制位开始,依次从后向前填入格式中的x,多出的位补0。这样就得到了,的 UTF-8 编码是11100100 10111000 10100101

对单字符进行转换之后,字符串传输的时候直接拼接即可,切割的时候则先读取第一位的 1 的数量,来判断后面多少字节都是同一个字的,再进行切割。这样,如果中间有漏字符,也可以发现。

比如 “中国”的 UTF-8 表示为:
11100100 10111000 10101101 11100101 10011011 10111101

其实你可以发现,因为 UTF-8 加入了位数提示,所以会占用更多的长度来表达字符串。比如中文通常是 2048-65535 之间,所以一个中文在 UTF-8 会占用 3 个 8 位(3字节)。而更加节约的 UTF-16 只用占用2个字节。但是 UTF-8 可以无误的表达 65535 之后的字符,这是 UTF-16 和 GBK 无法做到的。

在过去的标准里,UTF-8 最多可以用 6 个 8 位(6字节)表示表示一个字符,然而 Unicode 也只能表示到 1114111,所以 UTF-8 也只需 4 位就足够了。

另外,因为用到 65536 之后的机会并不多。一些数据库 ,比如 Mysql,默认储存 UTF-8 时,就只给每个字符留了最多3位的空间。后面 Emoji 兴起后,Mysql 为了兼容之前的版本,不得不新增了一个数据类型 utf8mb4 来支持4位的 UTF8,这个功能在 Mysql 5.5.3 中加入。我们应该优先设定 Mysql 数据类型为 utf8mb4 。

写在后面

本文简单梳理下了各种字符编码和字符串表达的方法。当然,在具体 Socket 传输或者保存为 txt 文件时,仍需要考虑很多因素。比如字节的顺序是大端(从左到右拼接)还是小端(从右到左拼接),存成 txt 文件需不需要文件头部一个字符来表示文件的类型和文件编码等。具体可以参考下面阮一峰老师的文章,我也不再赘述。

参考资料

http://www.ruanyifeng.com/blog/2007/10/ascii_unicode_and_utf-8.html