luda 本文简要介绍字符集、字符编码的概念。还有破裂时常用的诊断技术。
背景：字符集和编码无疑是IT新手乃至各种大神的头痛。遇到复杂复杂的字符集、各种和声文、乱七八糟的文字时，问题的定位往往变得非常困难。
本文原则上介绍了字符集和编码的简单科普介绍，并介绍了几种常见的错误定位方法，以帮助读者今后更从容地找到相关问题。
在正式介绍之前，我先做个小陈述。要非常准确地理解每个名词的解释，请浏览维基百科。大卫亚设，Northern Exposure(美国电视剧)这篇文章是博主在自己理解消化后转换成易于理解的表达后的介绍。
在介绍
什么是字符集
字符集之前，让我们先了解一下为什么要有字符集。我们在计算机屏幕上看到的是实体化的文字，存储在计算机存储介质上的实际上是二进制的比特流。那么两者之间的转换规则需要统一的标准。否则，如果把我们的u盘插入老板的电脑，文档就会被破坏。合伙人QQ上传的文件在我们地区打开后被打破了。因此，为了达到转换标准，出现了多种字符集标准。简而言之，字符集定义了与字符相对应的二进制数字存储方法(编码)和字符串二进制值表示的字符(解码)转换关系。
那么为什么会有那么多字符集标准呢？这个问题实际上很容易回答。问自己为什么我们的插头在英国不能用。为什么显示器会有DVI、VGA、HDMI、DP这么多接口？很多规范和标准在最初制定的时候没有意识到这将是今后全球普遍性的规范，也没有意识到从组织本身的利益来看，本质上想与现有标准区分开来。(威廉莎士比亚，温斯顿，标准名言)结果产生了许多具有相同效果但彼此不兼容的标准。
说了那么多，我来举个真实的例子。下面是各种编码下这个字的十六进制和二进制编码结果。怎么样才能感觉很尴尬？
与字符集十六进制编码相对应的二进制数据utf-80xe 5b 18c 1110 0101 1011 0001 1000 1100 utf-160x 5c 4c 1011 1000 1001 1000 GBK0x 8 cc 51000 1100 1100 0101
什么是字符编码
字符集只是规则集的名称，相当于现实生活，字符集是对某种语言的称呼。例如：英语、汉语、日语。对于字符集，正确编码和编码字符需要三个主要元素：字体表(character repertoire)、编码字符集(coded character set)和字符编码格式。其中字体表是与所有可读或可显示的字符相对应的数据库，字体投票决定了整个字符集可以表示的所有字符的范围。使用编码字符集，即编码值code point，指示字符在字体中的位置。字符编码--对字符集和实际存储的数字之间的转换关系进行编码。通常，code point值直接存储为编码值。例如，在ASCII中，A在表中排名第65位，编码的A的数字是0100 0001，即小数65的二进制转换结果。
你看，很多读者可能和我有同样的疑问。字体表和编码字符集似乎是必需的。字体表中的每个字符都有自己的序列号，因此直接使用序列号作为存储内容即可。(大卫亚设，Northern Exposure(美国电视剧)，Northern Exposure(美国电视剧)为什么要通过字符编码将序列号转换为其他存储格式？
事实上，原因很容易理解。综合字体表的目的是涵盖世界上所有的字符，但在实际使用过程中，实际使用的字符与整个字体表相比，比例非常低。例如，中文区域程序几乎不需要日语字符，但在一些英语国家，简单的ASCII字体表也可以满足基本需求。如果将每个字符存储为字体表中的序列号，则每个字符需要3字节(对于unicode字体)。这对于原本只占一个字符的ASCII编码的英语地区国家来说是额外的费用(存储体积是3倍)。直接算下来，同样的硬盘用ASCII可以存储1500篇文章，用3字节unicode序列号存储的话只能存储500篇。所以会出现UTF-8这样的长编码。在UTF-8编码中，最初只需要一个字节的ASCII字符仍然只占用一个字节。中文和日语等复杂的字符需要2 ~ 3字节。
看完
UTF-8和Unicode的关系
上面的两个概念说明，解释UTF-8和unicode的关系更简单。unicode是上面提到的编码字符集，UTF-8是字符编码，即unicode规则字体的实现形式。随着互联网的发展，对同一书屋的要求越来越迫切，unicode标准也自然出现。它涵盖了几乎所有国家语言中都可能出现的护身符。
号和文字，并将为他们编号。详见：Unicode on Wikipedia。Unicode的编号从0000开始一直到10FFFF共分为16个Plane，每个Plane中有65536个字符。而UTF-8则只实现了第一个Plane，可见UTF-8虽然是一个当今接受度最广的字符集编码，但是它并没有涵盖整个Unicode的字库，这也造成了它在某些场景下对于特殊字符的处理困难（下文会有提到）。
UTF-8编码简介
为了更好的理解后面的实际应用，我们这里简单的介绍下UTF-8的编码实现方法。即UTF-8的物理存储和Unicode序号的转换关系。
UTF-8编码为变长编码。最小编码单位（code unit）为一个字节。一个字节的前1-3个bit为描述性部分，后面为实际序号部分。
- 如果一个字节的第一位为0，那么代表当前字符为单字节字符，占用一个字节的空间。0之后的所有部分（7个bit）代表在Unicode中的序号。
- 如果一个字节以110开头，那么代表当前字符为双字节字符，占用2个字节的空间。110之后的所有部分（7个bit）代表在Unicode中的序号。且第二个字节以10开头
- 如果一个字节以1110开头，那么代表当前字符为三字节字符，占用2个字节的空间。110之后的所有部分（7个bit）代表在Unicode中的序号。且第二、第三个字节以10开头
- 如果一个字节以10开头，那么代表当前字节为多字节字符的第二个字节。10之后的所有部分（6个bit）代表在Unicode中的序号。
具体每个字节的特征可见下表，其中x代表序号部分，把各个字节中的所有x部分拼接在一起就组成了在Unicode字库中的序号
| Byte 1 | Byte 2 | Byte3 |
|---|---|---|
| 0xxx xxxx | ||
| 110x xxxx | 10xx xxxx | |
| 1110 xxxx | 10xx xxxx | 10xx xxxx |
我们分别看三个从一个字节到三个字节的UTF-8编码例子：
| 实际字符 | 在Unicode字库序号的十六进制 | 在Unicode字库序号的二进制 | UTF-8编码后的二进制 | UTF-8编码后的十六进制 |
| $ | 0024 | 010 0100 | 0010 0100 | 24 |
| ¢ | 00A2 | 000 1010 0010 | 1100 0010 1010 0010 | C2 A2 |
| € | 20AC | 0010 0000 1010 1100 | 1110 0010 1000 0010 1010 1100 | E2 82 AC |
细心的读者不难从以上的简单介绍中得出以下规律：
- 3个字节的UTF-8十六进制编码一定是以E开头的
- 2个字节的UTF-8十六进制编码一定是以C或D开头的
- 1个字节的UTF-8十六进制编码一定是以比8小的数字开头的
为什么会出现乱码
先科普下乱码的英文native说法是mojibake。
简单的说乱码的出现是因为：编码和解码时用了不同或者不兼容的字符集。对应到真实生活中，就好比是一个英国人为了表示祝福在纸上写了bless（编码过程）。而一个法国人拿到了这张纸，由于在法语中bless表示受伤的意思，所以认为他想表达的是受伤（解码过程）。这个就是一个现实生活中的乱码情况。在计算机科学中一样，一个用UTF-8编码后的字符，用GBK去解码。由于两个字符集的字库表不一样，同一个汉字在两个字符表的位置也不同，最终就会出现乱码。
我们来看一个例子：假设我们用UTF-8编码存储很屌两个字，会有如下转换：
| 字符 | UTF-8编码后的十六进制 |
|---|---|
| 很 | E5BE88 |
| 屌 | E5B18C |
于是我们得到了E5BE88E5B18C这么一串数值。而显示时我们用GBK解码进行展示，通过查表我们获得以下信息：
| 两个字节的十六进制数值 | GBK解码后对应的字符 |
|---|---|
| E5BE | 寰 |
| 88E5 | 堝 |
| B18C | 睂 |
解码后我们就得到了寰堝睂这么一个错误的结果，更要命的是连字符个数都变了。
如何识别乱码的本来想要表达的文字
要从乱码字符中反解出原来的正确文字需要对各个字符集编码规则有较为深刻的掌握。但是原理很简单，这里用最常见的UTF-8被错误用GBK展示时的乱码为例，来说明具体反解和识别过程。
第1步 编码
假设我们在页面上看到寰堝睂这样的乱码，而又得知我们的浏览器当前使用GBK编码。那么第一步我们就能先通过GBK把乱码编码成二进制表达式。当然查表编码效率很低，我们也可以用以下SQL语句直接通过MySQL客户端来做编码工作：
mysql [localhost] {msandbox} > select hex(convert('寰堝睂' using gbk)); +-------------------------------------+ | hex(convert('寰堝睂' using gbk)) | +-------------------------------------+ | E5BE88E5B18C | +-------------------------------------+ 1 row in set sec)第2步 识别
现在我们得到了解码后的二进制字符串E5BE88E5B18C。然后我们将它按字节拆开。
| Byte 1 | Byte 2 | Byte 3 | Byte 4 | Byte 5 | Byte 6 |
|---|---|---|---|---|---|
| E5 | BE | 88 | E5 | B1 | 8C |
然后套用之前UTF-8编码介绍章节中总结出的规律，就不难发现这6个字节的数据符合UTF-8编码规则。如果整个数据流都符合这个规则的话，我们就能大胆假设乱码之前的编码字符集是UTF-8
第3步 解码
然后我们就能拿着E5BE88E5B18C用UTF-8解码，查看乱码前的文字了。当然我们可以不查表直接通过SQL获得结果：
mysql [localhost] {msandbox} ((none)) > select convert(0xE5BE88E5B18C using utf8); +------------------------------------+ | convert(0xE5BE88E5B18C using utf8) | +------------------------------------+ | 很屌 | +------------------------------------+ 1 row in set sec)常见问题处理之Emoji
所谓Emoji就是一种在Unicode位于\u1F601-\u1F64F区段的字符。这个显然超过了目前常用的UTF-8字符集的编码范围\u0000-\uFFFF。Emoji表情随着IOS的普及和微信的支持越来越常见。下面就是几个常见的Emoji:
那么Emoji字符表情会对我们平时的开发运维带来什么影响呢？最常见的问题就在于将他存入MySQL数据库的时候。一般来说MySQL数据库的默认字符集都会配置成UTF-8（三字节），而utf8mb4在5.5以后才被支持，也很少会有DBA主动将系统默认字符集改成utf8mb4。那么问题就来了，当我们把一个需要4字节UTF-8编码才能表示的字符存入数据库的时候就会报错：ERROR 1366: Incorrect string value: '\xF0\x9D\x8C\x86' for column 。
如果认真阅读了上面的解释，那么这个报错也就不难看懂了。我们试图将一串Bytes插入到一列中，而这串Bytes的第一个字节是\xF0意味着这是一个四字节的UTF-8编码。但是当MySQL表和列字符集配置为UTF-8的时候是无法存储这样的字符的，所以报了错。
那么遇到这种情况我们如何解决呢？有两种方式：升级MySQL到5.6或更高版本，并且将表字符集切换至utf8mb4。第二种方法就是在把内容存入到数据库之前做一次过滤，将Emoji字符替换成一段特殊的文字编码，然后再存入数据库中。之后从数据库获取或者前端展示时再将这段特殊文字编码转换成Emoji显示。第二种方法我们假设用-*-1F601-*-来替代4字节的Emoji，那么具体实现python代码可以参见Stackoverflow上的回答。
本文为转载，如需再次转载，请查看源站 “cenalulu.gi” 的要求。如果我们的工作有侵犯到您的权益，请及时联系我们。
文章仅代表作者的知识和看法，如有不同观点，请楼下排队吐槽:D