Unicode 编码

 

来源：BuquTianya ，

blog.youkuaiyun.com/BuquTianya/article/details/80685437

 

一道经典问题

 

Java里的char类型能不能存储一个中文字符？

 

对于这道题，绝大多数的答案都是“可以存储”。给出的原因包括：

 

1. java中的char是unicode存储，unicode编码字符集中包含了汉字，所以可以存储中文； 

2. java内部其实是使用的UTF-16的编码，所以是支持大部分非生僻汉字的； 

3. 采用Unicode编码集，一个char占用两个字节，而一个中文字符也是两个字节，因此Java中的char是可以表示一个中文字符的； 

4. Java的char只能表示utf­16中的BMP部分中文字符，不能表示扩展字符集里的中文字符；

 

那么，这个问题的终极答案到底是什么？

 

Java API中关于char的说明

 

原文地址:https://docs.oracle.com/javase/7/docs/api/java/lang/Character.html

 

char类型是按照Unicode规范实现的一种数据类型，固定16bit大小。现如今，

Unicode字符集已经进行了扩展，表示的范围已经超过了16bit。Unicode字符集的

数值范围扩大到了[U+0000,U+10FFFF]。

 

也就是说一个char能够存储16bit大小的数值，即2个字节。但是，就常用的UTF-8编码来说，我们都听说过他是用3或者4个字节来表示一个汉字的。就拿3个字节来算的话，一个char也存不下是不是？

 

我们继续看api文档的其他段落：

 

一个char值可以表示BMP范围内的Unicode字符。BMP表示[U+0000, U+FFFF]之间的Unicode字符。

 

而且，绝大部分的中文字符的Unicode范围是[0x4E00, 0x9FBB],恰好是在BMP范围内。

 

是不是说这里出现了破解不了的矛盾呢？UTF-8占用3到4个字节，char只能存2个字节（16bit），然而UTF-8中的几乎所有汉字都是在BMP范围内，也就是在char可存储的范围内，是不是矛盾了？

 

答案是不矛盾！关键点就在于接下来给出总结的第一条！

 

这里先给出总结，后续再给出解释： 

 

1. char字符存储的是Unicode编码的代码点，也就是存储的是U+FF00这样的数值，然而我们在调试或者输出到输出流的时候，是JVM或者开发工具按照代码点对应的编码字符输出的。 

2. 所以虽然UTF-8编码的中文字符是占用3个或者4个字节，但是对应的代码点仍然集中在[0x4E00, 0x9FBB]，所以char是能够存下在这个范围内的中文字符的。 

3. 但是对于超过16bit的Unicode字符集，也就是Unicode的扩展字符集，一个char是放不下的，需要两个char才能放下。

 

Unicode编码

 

Unicode的出现是对混乱的ANSI编码世界的一个大一统，因而也叫做统一码、万国码、单一码。Unicode编码把世界上常用的语言字符都进行了统一的编码，一个数值就代表一个字符，而且世界范围内公认。

 

ANSI的编码世界里，各中语言有自己的编码规范，同一个数值在不同的国家代表不同的字符。所以当文字在不同国家传递的时候（比如发邮件，看国外网页），问题就很大了，我明明写的是“爱我中华”，美国朋友看到的确实”°®ÎÒÖлª”，一定是一脸问号！

 

        //=====模拟文字在不同编码语言间传递的过程=====

        //发帖子

        String s = "爱我中华";

        //编码成字节流，通过网络传入，或者存储到文件

        byte[] bytes = s.getBytes("GB2312");

        System.out.println(s);

        //国外朋友用自己电脑的编码方式解析字节流

        String s2 = new String(bytes, "ISO-8859-1");

        //oh！ shit, wtf!        

        System.out.println(s2);

 

有了Unicode这个统一编码之后，全世界的计算机都能正确的解析到原始的字符，对于国内的文字信息，国外的朋友唯一要做的就是懂中文！

 

UTF-8只是Unicode编码的一种编码转换规范，也就是怎么存储Unicode代码点的方案之一。另外还有UTF-16和UTF-32等编码规范。Unicode为什么需要这么多编码规范？直接存储代码点行不行？

 

当然不行，存储了就需要解析比如”汉字”两个字的Unicode代码点是“0x6c49和0x5b57”也就是”6c495b57”。而且，Unicode的代码点还有3个字节的，比如”10FF3B”,对于一个很长的上述数字串该怎么解析？比如“10FF3B6c495b57”！

 

所以，需要某种编码方案来区分那几个数值是一个Unicode代码点，这种方案就是UTF-8、UTF-16、UTF-32这样的编码方案。

 

UTF-8编码和代码点对应关系

 

UTF-8以字节为单位对Unicode进行编码。从Unicode到UTF-8的编码方式如下：

 

 

有没有发现点什么？当一个字节表示一个字符时，二进制开头是0；当两个字节表示一个字符时，二进制开头是11；当3个字节表示一个字符时，二进制开头是111；依次类推！

 

UTF-8编码加入了多余的标识位来区分一个Unicode代码点！才会出现中文汉字集中在[0x4E00, 0x9FBB]范围的16bit数值内，UTF-8却需要3个字节存储的原因。

 

另一个经典问题

 

怎么判断Java字符串是否包含中文？

 

这个问题也很经典，一般我们可以查到的方法如下：

 

    //代码来自HanLP自然语言处理库，git地址：https://github.com/hankcs/HanLP/blob/master/src/main/java/com/hankcs/hanlp/utility/TextUtility.java

    /**

     * 判断某个字符是否为汉字

     *

     * @param c 需要判断的字符

     * @return 是汉字返回true，否则返回false

     */

    public static boolean isChinese(char c)

    {

        String regex = "[\\u4e00-\\u9fa5]";

        return String.valueOf(c).matches(regex);

    }

 

//来源地址：https://blog.youkuaiyun.com/z69183787/article/details/53162069这里考虑进了CJK的扩展字符集

 

 

// GENERAL_PUNCTUATION 判断中文的“号  

    // CJK_SYMBOLS_AND_PUNCTUATION 判断中文的。号  

    // HALFWIDTH_AND_FULLWIDTH_FORMS 判断中文的，号  

    private static final boolean isChinese(char c) {  

        Character.UnicodeBlock ub = Character.UnicodeBlock.of(c);  

        if (ub == Character.UnicodeBlock.CJK_UNIFIED_IDEOGRAPHS  

                || ub == Character.UnicodeBlock.CJK_COMPATIBILITY_IDEOGRAPHS  

                || ub == Character.UnicodeBlock.CJK_UNIFIED_IDEOGRAPHS_EXTENSION_A  

                || ub == Character.UnicodeBlock.GENERAL_PUNCTUATION  

                || ub == Character.UnicodeBlock.CJK_SYMBOLS_AND_PUNCTUATION  

                || ub == Character.UnicodeBlock.HALFWIDTH_AND_FULLWIDTH_FORMS) {  

            return true;  

        }  

        return false;  

    }  

 

总结一下，一般来说用第一种方法就足够了，扩展字符集用的比较少，另外从HanLP的github星数来说，这种方案的通用度还是可信的。

好了，先到这里。这里也留一个坑，mysql数据库里边的VARCHAR类型和Java的char类型是一种处理方式么？下一篇也会从String源代码的角度对这里的分析进行一个佐证。

 

 

 

 

原文链接:

https://blog.youkuaiyun.com/hezh1994/article/details/78899683

今天，在学习 Node.js 中的 Buffer 对象时，注意到它的 alloc 和 from方法会默认用 UTF-8 编码，在数组中每位对应 1 字节的十六进制数。想到了之间学习 ES6 时关于字符串的 Unicode 表示法，突然就很想知道 UTF-16 是如何进行编码的，我尝试将一些汉字转换成二进制数，然后简单的按 2 个字节一组转换成十六进制，发现对于那些码点较大的汉字，结果并不仅仅是简单的二进制转十六进制。于是，我开始在网上找资料，决心彻底弄明白 Unicode 编码。

ASCII码

在学校学 C 语言的时候，了解到一些计算机内部的机制，知道所有的信息最终都表示为一个二进制的字符串，每一个二进制位有 0 和 1 两种状态，通过不同的排列组合，使用 0 和 1 就可以表示世界上所有的东西，感觉有点中国“太极”的感觉——“太极生两仪，两仪生四象，四象生八卦”。

在计算机种中，1 字节对应 8 位二进制数，而每位二进制数有 0、1 两种状态，因此 1 字节可以组合出 256 种状态。如果这 256 中状态每一个都对应一个符号，就能通过 1 字节的数据表示 256 个字符。美国人于是就制定了一套编码（其实就是个字典），描述英语中的字符和这 8 位二进制数的对应关系，这被称为 ASCII 码。

ASCII 码一共定义了 128 个字符，例如大写的字母 A 是 65（这是十进制数，对应二进制是0100 0001）。这 128 个字符只使用了 8 位二进制数中的后面 7 位，最前面的一位统一规定为 0。

历史问题

英语用 128 个字符来编码完全是足够的，但是用来表示其他语言，128 个字符是远远不够的。于是，一些欧洲的国家就决定，将 ASCII 码中闲置的最高位利用起来，这样一来就能表示 256 个字符。但是，这里又有了一个问题，那就是不同的国家的字符集可能不同，就算它们都能用 256 个字符表示全，但是同一个码
点（也就是 8 位二进制数）表示的字符可能可能不同。例如，144 在阿拉伯人的 ASCII 码中是 گ，而在俄罗斯的 ASCII 码中是 ђ。

因此，ASCII 码的问题在于尽管所有人都在 0 - 127 号字符上达成了一致，但对于 128 - 255 号字符上却有很多种不同的解释。与此同时，亚洲语言有更多的字符需要被存储，一个字节已经不够用了。于是，人们开始使用两个字节来存储字符。

各种各样的编码方式成了系统开发者的噩梦，因为他们想把软件卖到国外。于是，他们提出了一个“内码表”的概念，可以切换到相应语言的一个内码表，这样才能显示相应语言的字母。在这种情况下，如果使用多语种，那么就需要频繁的在内码表内进行切换。

Unicode

最终，美国人意识到他们应该提出一种标准方案来展示世界上所有语言中的所有字符，出于这个目的，Unicode诞生了。

Unicode 当然是一本很厚的字典，记录着世界上所有字符对应的一个数字。具体是怎样的对应关系，又或者说是如何进行划分的，就不是我们考虑的问题了，我们只用知道 Unicode 给所有的字符指定了一个数字用来表示该字符。

对于 Unicode 有一些误解，它仅仅只是一个字符集，规定了符合对应的二进制代码，至于这个二进制代码如何存储则没有任何规定。它的想法很简单，就是为每个字符规定一个
用来表示该字符的数字，仅此而已。

Unicode 编码方案

之前提到，Unicode 没有规定字符对应的二进制码如何存储。以汉字“汉”为例，它的 Unicode 码点是 0x6c49，对应的二进制数是 110110001001001，二进制数有 15 位，这也就说明了它至少需要 2 个字节来表示。可以想象，在 Unicode 字典中往后的字符可能就需要 3 个字节或者 4 个字节，甚至更多字节来表示了。

这就导致了一些问题，计算机怎么知道你这个 2 个字节表示的是一个字符，而不是分别表示两个字符呢？这里我们可能会想到，那就取个最大的，假如 Unicode 中最大的字符用 4 字节就可以表示了，那么我们就将所有的字符都用 4 个字节来表示，不够的就往前面补 0。这样确实可以解决编码问题，但是却造成了空间的极大浪费，如果是一个英文文档，那文件大小就大出了 3 倍，这显然是无法接受的。

于是，为了较好的解决 Unicode 的编码问题， UTF-8 和 UTF-16 两种当前比较流行的编码方式诞生了。当然还有一个 UTF-32 的编码方式，也就是上述那种定长编码，字符统一使用 4 个字节，虽然看似方便，但是却不如另外两种编码方式使用广泛。

UTF-8

UTF-8 是一个非常惊艳的编码方式，漂亮的实现了对 ASCII 码的向后兼容，以保证 Unicode 可以被大众接受。

UTF-8 是目前互联网上使用最广泛的一种 Unicode 编码方式，它的最大特点就是可变长。它可以使用 1 - 4 个字节表示一个字符，根据字符的不同变换长度。编码规则如下：

1. 对于单个字节的字符，第一位设为 0，后面的 7 位对应这个字符的 Unicode 码点。因此，对于英文中的 0 - 127 号字符，与 ASCII 码完全相同。这意味着 ASCII 码那个年代的文档用 UTF-8 编码打开完全没有问题。

2. 对于需要使用 N 个字节来表示的字符（N > 1），第一个字节的前 N 位都设为 1，第 N + 1 位设为0，剩余的 N - 1 个字节的前两位都设位 10，剩下的二进制位则使用这个字符的 Unicode 码点来填充。

编码规则如下：

UNICODE 十六进制码点范围	UTF-8 二进制
0000 0000 - 0000 007F	0xxxxxxx
0000 0080 - 0000 07FF	110xxxxx 10xxxxxx
0000 0800 - 0000 FFFF	1110xxxx 10xxxxxx 10xxxxxx
0001 0000 - 0010 FFFF	11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

根据上面编码规则对照表，进行 UTF-8 编码和解码就简单多了。下面以汉字“汉”为利，具体说明如何进行 UTF-8 编码和解码。

“汉”的 Unicode 码点是 0x6c49（110 1100 0100 1001），通过上面的对照表可以发现，0x0000 6c49 位于第三行的范围，那么得出其格式为 1110xxxx 10xxxxxx 10xxxxxx。接着，从“汉”的二进制数最后一位开始，从后向前依次填充对应格式中的 x，多出的 x 用 0 补上。这样，就得到了“汉”的 UTF-8 编码为 11100110 10110001 10001001，转换成十六进制就是 0xE6 0xB7 0x89。

解码的过程也十分简单：如果一个字节的第一位是 0 ，则说明这个字节对应一个字符；如果一个字节的第一位1，那么连续有多少个 1，就表示该字符占用多少个字节。

UTF-16

在了解 UTF-16 编码方式之前，先了解一下另外一个概念——"平面"。

在上面的介绍中，提到了 Unicode 是一本很厚的字典，她将全世界所有的字符定义在一个集合里。这么多的字符不是一次性定义的，而是分区定义。每个区可以存放 65536 个（$2^{16}$）字符，称为一个平面（plane）。目前，一共有 17 个（$2^{5}$）平面，也就是说，整个 Unicode 字符集的大小现在是 $2^{21}$。

最前面的 65536 个字符位，称为基本平面（简称 BMP ），它的码点范围是从 0 到 $2^{16}-1$，写成 16 进制就是从 U+0000 到 U+FFFF。所有最常见的字符都放在这个平面，这是 Unicode 最先定义和公布的一个平面。剩下的字符都放在辅助平面（简称 SMP ），码点范围从 U+010000 到 U+10FFFF。

基本了解了平面的概念后，再说回到 UTF-16。UTF-16 编码介于 UTF-32 与 UTF-8 之间，同时结合了定长和变长两种编码方法的特点。它的编码规则很简单：基本平面的字符占用 2 个字节，辅助平面的字符占用 4 个字节。也就是说，UTF-16 的编码长度要么是 2 个字节（U+0000 到 U+FFFF），要么是 4 个字节（U+010000 到 U+10FFFF）。那么问题来了，当我们遇到两个字节时，到底是把这两个字节当作一个字符还是与后面的两个字节一起当作一个字符呢？

这里有一个很巧妙的地方，在基本平面内，从 U+D800 到 U+DFFF 是一个空段，即这些码点不对应任何字符。因此，这个空段可以用来映射辅助平面的字符。

辅助平面的字符位共有 $2^{20}$ 个，因此表示这些字符至少需要 20 个二进制位。UTF-16 将这 20 个二进制位分成两半，前 10 位映射在 U+D800 到 U+DBFF，称为高位（H），后 10 位映射在 U+DC00 到 U+DFFF，称为低位（L）。这意味着，一个辅助平面的字符，被拆成两个基本平面的字符表示。

因此，当我们遇到两个字节，发现它的码点在 U+D800 到 U+DBFF 之间，就可以断定，紧跟在后面的两个字节的码点，应该在 U+DC00 到 U+DFFF 之间，这四个字节必须放在一起解读。

接下来，以汉字"

查阅:

http://www.fmddlmyy.cn/text16.html