（转自知乎）Unicode编码

很多人都把Unicode编码挂在嘴边&＃xff0c;其实咱们现实生活中遇到的编码基本都是Unicode的

因为Unicode兼容了大多数老版本的编码规范例如 ASCII

Unicode编码定义了这个世界上几乎所有字符&＃xff08;就是你眼睛看到的长那个样子的符号&＃xff09;的数字表示

也就是说Unicode为每个字符发了一张身份证&＃xff0c;这张身份证上有一串唯一的数字ID确定了这个字符

在这个纷乱世界上存在的唯一性。Unicode给这串数字ID起了个名字叫&＃xff3b;码点&＃xff3d;&＃xff08;Code Point&＃xff09;

而很多人说的编码其实是想表达&＃xff3b;Unicode转换格式&＃xff3d;&＃xff08;即UTF&＃xff0c;Unicode Transformation Formats&＃xff09;

有没有觉得眼前一亮豁然开朗&＃xff1f;没错 这就是我们看到的UTF-8/UTF-16/UTF-32的前缀来源

这个&＃xff3b;Unicode转换格式&＃xff3d;的存在是为了解决&＃xff3b;码点&＃xff3d;在计算机中的二进制表现形式而设计的

毕竟我们的机内表示涉及存储位宽&＃xff0c;兼容古老编码格式&＃xff0c;码点是数值过大的罕见字符等问题

&＃xff3b;码点&＃xff3d;经过映射后得到的二进制串的转换格式单位称之为&＃xff3b;码元&＃xff3d;&＃xff08;Code Unit&＃xff09;。也就是说如果有一种UTF的码点二进制表示有n字节&＃xff0c;其码元为8位&＃xff08;1个byte&＃xff09;&＃xff0c;那么其拥有码元n个。每种UTF的码元都不同&＃xff0c;其宽度被作为区分写在了UTF的后缀——这就是UTF-8/UTF-16/UTF-32的由来。UTF-8的码元是8位的&＃xff0c;UTF-16的码元是16位的。大部分的编程语言采用16位的码元作为机内表示。这就是我们在各种语言中调用获取一个字符串中character的数量时会出现这么多混乱的原因。事实上我们调用这些方法时取得的不是字符个数&＃xff0c;而是码元个数&＃xff01;一旦我们的字符串中包含了位于基本平面之外的码点&＃xff0c;那么就会需要更多的码元来表示&＃xff0c;这个时候就会出现测试时常见的困惑——为何return的字符数比实际字符数要多&＃xff1f;所以实际写代码时要特别注意这个问题。

采取不同的映射方式可以得到不同格式的二进制串&＃xff0c;但是他们背后所表示的&＃xff3b;码点&＃xff3d;永远是一致的就好像你换身份证但是身份证号不变一样。由于平时人们误把&＃xff3b;转换格式&＃xff3d;也称为&＃xff3b;编码&＃xff3d;&＃xff0c;所以造成今天Unicode&＃xff0f;UTF傻傻分不清楚且遣词造句运用混乱的悲桑局面。

Unicode 编码 发展到今天 扩展到了 21 位&＃xff08;从 U&＃43;0000 到 U&＃43;10FFFF &＃xff09;。这一点很重要&＃xff1a; Unicode 不是 16 位的编码&＃xff0c; 它是 21 位的。这 21 位提供了 1,114,112 个码点&＃xff0c;其中&＃xff0c;只有大概 10% 正在使用&＃xff0c;所以还有相当大的扩充空间。

编码空间被分成 17 个平面&＃xff08;plane&＃xff09;&＃xff0c;每个平面有 65,536 个字符&＃xff08;正好填充2个字节&＃xff0c;16位&＃xff09;。0 号平面叫做「基本多文种平面」&＃xff08;BMP, Basic Multilingual Plane &＃xff09;&＃xff0c;涵盖了几乎所有你能遇到的字符&＃xff0c;除了 emoji&＃xff08;emoji位于1号平面 - -&＃xff09;。其它平面叫做补充平面&＃xff0c;大多是空的。

总结一下各种编码格式的特质&＃xff1a;

UTF-32

 

UTF-16 以及「代理对」&＃xff08; Surrogate Pairs &＃xff09;的概念

UTF-16要常见得多&＃xff0c;它是根据有 16 位固定长度的码元&＃xff08; code units &＃xff09;定义的。UTF-16 本身是一种长度可变的编码。基本多文种平面&＃xff08;BMP&＃xff09;中的每一个码点都直接与一个码元相映射。鉴于 BMP 几乎囊括了所有常见字符&＃xff0c;UTF-16 一般只需要 UTF-32 一半的空间。其它平面里很少使用的码点都是用两个 16 位的码元来编码的&＃xff0c;这两个合起来表示一个码点的码元就叫做代理对&＃xff08; surrogate pair &＃xff09;。

UTF-8

UTF-8 使用一到四个字节来编码一个码点。从 0 到 127 的这些码点直接映射成 1 个字节&＃xff08;对于只包含这个范围字符的文本来说&＃xff0c;这一点使得 UTF-8 和 ASCII 完全相同&＃xff09;。接下来的 1,920 个码点映射成 2 个字节&＃xff0c;在 BMP 里所有剩下的码点需要 3 个字节。Unicode 的其他平面里的码点则需要 4 个字节。UTF-8 是基于 8 位的码元的&＃xff0c;因此它并不需要关心字节顺序&＃xff08;不过仍有一些程序会在 UTF-8 文件里加上多余的 BOM&＃xff09;。

我们的JVM中保存码点是UTF16的转换格式&＃xff0c;从char的位宽为16位也可以看得出来。由于绝大部分编码的码点位于基本平面&＃xff0c;所以使用16位可以几乎表示所有常用字符。这就是许多语言编译器或运行时都使用UTF16的原因。英文在使用UTF16时也是2字节表示的。当我们想要使用其他平面的字符时&＃xff0c;码元超过2个字节&＃xff0c;就需要使用代理对在语言中的特定表示方式&＃xff0c;譬如‘\U112233’之类的。

使用UTF8时&＃xff0c;常用的Alphabet和Numeric都在前127字节&＃xff0c;被有效率地用一个字节表示。而我们的中文由于排在1920个码点之后&＃xff0c;所以使用3个字节表示&＃xff0c;这方面就比UTF16转换格式耗费更多空间。

最后&＃xff0c;不论使用哪种UTF转换格式&＃xff0c;都是程序员自己可以选择的一种表达方式而已。我们可以通过Java方便的API进行自如转换。