1、引言
IM等社交应用的开发工作中，乱码问题也很常见，比如:
1）IM聊天消息中的Emoji表情为什么发给后端后MySQL数据库里会乱码；
2）文件名中带有中文的大文件聊天消息发送后，对方看到的文名是乱码；
3）Http rest接口调用时，后端读取到APP端传过来的参数有中文乱码问题；
... ...
那么，对于乱码这个看似不起眼，但并不是一两话能讲清楚的问题，是很有必要从根源了解字符集和编码原理，知其然知其所以然显然是一个优秀码农的基本素养，所以，便有了本文，希望能帮助到你。
* 推荐阅读：关于字符编码知识的详细讲解请见《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》。
学习交流：
- 即时通讯/推送技术开发交流5群： 215477170 [推荐]
- 移动端IM开发入门文章：《 新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-2868-1-1.html）
2、关于作者
卢钧轶：爱捣腾Linux的DBA。曾任职于大众点评网DBA团队，主要关注MySQL、Memcache、MMM等产品的高性能和高可用架构。
个人微博：米雪儿侬好的cenalulu
Github地址： https://github.com/cenalulu
3、系列文章
本文是IM开发干货系列文章中的第21篇，总目录如下：
《 IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《 IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《 如何保证IM实时消息的“时序性”与“一致性”？》
《 IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《 IM群聊消息如此复杂，如何保证不丢不重？》
《 一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
《 移动端IM登录时拉取数据如何作到省流量？》
《 通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《 浅谈移动端IM的多点登陆和消息漫游原理》
《 IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
《 IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《 IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《 IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《 IM群聊消息的已读回执功能该怎么实现？》
《 IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》
《 IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《 一个低成本确保IM消息时序的方法探讨》
《 IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《 IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
《 IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
《 IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》（本文）
4、正文概述
字符集和编码无疑是IT菜鸟甚至是各种大神的头痛问题。当遇到纷繁复杂的字符集，各种火星文和乱码时，问题的定位往往变得非常困难。
本文内容就将会从原理方面对字符集和编码做个简单的科普介绍，同时也会介绍一些通用的乱码故障定位的方法以方便读者以后能够更从容的定位相关问题。
在正式介绍之前，先做个小申明：如果你希望非常精确的理解各个名词的解释，那么可以详细阅读这篇《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》。
本文是博主通过自己理解消化后并转化成易懂浅显的表述后的介绍，会尽量以简单明了的文字来从要源讲解字符集、字符编码的概念，以及在遭遇乱码时的一些常用诊断技巧，希望能助你对于“乱码”问题有更深地理解。
5、什么是字符集
在介绍字符集之前，我们先了解下为什么要有字符集。
我们在计算机屏幕上看到的是实体化的文字，而在计算机存储介质中存放的实际是二进制的比特流。那么在这两者之间的转换规则就需要一个统一的标准，否则把我们的U盘插到老板的电脑上，文档就乱码了；小伙伴QQ上传过来的文件，在我们本地打开又乱码了。
于是为了实现转换标准，各种字符集标准就出现了。
简单的说：字符集就规定了某个文字对应的二进制数字存放方式（编码）和某串二进制数值代表了哪个文字（解码）的转换关系。
那么为什么会有那么多字符集标准呢？
这个问题实际非常容易回答。问问自己为什么我们的插头拿到英国就不能用了呢？为什么显示器同时有DVI、VGA、HDMI、DP这么多接口呢？很多规范和标准在最初制定时并不会意识到这将会是以后全球普适的准则，或者处于组织本身利益就想从本质上区别于现有标准。于是，就产生了那么多具有相同效果但又不相互兼容的标准了。
说了那么多我们来看一个实际例子，下面就是“屌”这个字在各种编码下的十六进制和二进制编码结果，怎么样有没有一种很屌的感觉？
6、什么是字符编码
字符集只是一个规则集合的名字，对应到真实生活中，字符集就是对某种语言的称呼。例如：英语，汉语，日语。
对于一个字符集来说要正确编码转码一个字符需要三个关键元素：
1）字库表（character repertoire）：是一个相当于所有可读或者可显示字符的数据库，字库表决定了整个字符集能够展现表示的所有字符的范围；
2）编码字符集（coded character set）：即用一个编码值code point来表示一个字符在字库中的位置；
3）字符编码（character encoding form）：将编码字符集和实际存储数值之间的转换关系。
一般来说都会直接将code point的值作为编码后的值直接存储。例如在ASCII中“A”在表中排第65位，而编码后A的数值是_ 0100 0001 _也即十进制的65的二进制转换结果。
看到这里，可能很多读者都会有和我当初一样的疑问：字库表和编码字符集看来是必不可少的，那既然字库表中的每一个字符都有一个自己的序号，直接把序号作为存储内容就好了。为什么还要多此一举通过字符编码把序号转换成另外一种存储格式呢？
其实原因也比较容易理解：统一字库表的目的是为了能够涵盖世界上所有的字符，但实际使用过程中会发现真正用的上的字符相对整个字库表来说比例非常低。例如中文地区的程序几乎不会需要日语字符，而一些英语国家甚至简单的ASCII字库表就能满足基本需求。而如果把每个字符都用字库表中的序号来存储的话，每个字符就需要3个字节（这里以Unicode字库为例），这样对于原本用仅占一个字符的ASCII编码的英语地区国家显然是一个额外成本（存储体积是原来的三倍）。算的直接一些，同样一块硬盘，用ASCII可以存1500篇文章，而用3字节Unicode序号存储只能存500篇。于是就出现了UTF-8这样的变长编码。在UTF-8编码中原本只需要一个字节的ASCII字符，仍然只占一个字节。而像中文及日语这样的复杂字符就需要2个到3个字节来存储。
关于字符编码知识的详细讲解请见：《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》。
7、UTF-8和Unicode的关系
看完上面两个概念解释，那么解释UTF-8和Unicode的关系就比较简单了。
Unicode就是上文中提到的编码字符集，而UTF-8就是字符编码，即Unicode规则字库的一种实现形式。
随着互联网的发展，对同一字库集的要求越来越迫切，Unicode标准也就自然而然的出现。它几乎涵盖了各个国家语言可能出现的符号和文字，并将为他们编号。详见：Unicode百科介绍。
Unicode的编号从 _0000_ 开始一直到_10FFFF_ 共分为17个Plane，每个Plane中有65536个字符。而UTF-8则只实现了第一个Plane，可见UTF-8虽然是一个当今接受度最广的字符集编码，但是它并没有涵盖整个Unicode的字库，这也造成了它在某些场景下对于特殊字符的处理困难（下文会有提到）。
8、UTF-8编码简介
为了更好的理解后面的实际应用，我们这里简单的介绍下UTF-8的编码实现方法。即UTF-8的物理存储和Unicode序号的转换关系。
UTF-8编码为变长编码，最小编码单位（code unit）为一个字节。一个字节的前1-3个bit为描述性部分，后面为实际序号部分：
- 1）如果一个字节的第一位为0，那么代表当前字符为单字节字符，占用一个字节的空间。0之后的所有部分（7个bit）代表在Unicode中的序号；
- 2）如果一个字节以110开头，那么代表当前字符为双字节字符，占用2个字节的空间。110之后的所有部分（5个bit）加上后一个字节的除10外的部分（6个bit）代表在Unicode中的序号。且第二个字节以10开头；
- 3）如果一个字节以1110开头，那么代表当前字符为三字节字符，占用3个字节的空间。110之后的所有部分（5个bit）加上后两个字节的除10外的部分（12个bit）代表在Unicode中的序号。且第二、第三个字节以10开头；
- 4）如果一个字节以10开头，那么代表当前字节为多字节字符的第二个字节。10之后的所有部分（6个bit）和之前的部分一同组成在Unicode中的序号。
具体每个字节的特征可见下表，其中“x”代表序号部分，把各个字节中的所有x部分拼接在一起就组成了在Unicode字库中的序号。如下图所示。
我们分别看三个从一个字节到三个字节的UTF-8编码例子：
细心的读者不难从以上的简单介绍中得出以下规律：
1）3个字节的UTF-8十六进制编码一定是以E开头的；
2）2个字节的UTF-8十六进制编码一定是以C或D开头的；
3）1个字节的UTF-8十六进制编码一定是以比8小的数字开头的。
9、为什么会出现乱码
乱码也就是英文常说的mojibake（由日语的文字化け音译）。
简单的说乱码的出现是因为：编码和解码时用了不同或者不兼容的字符集。
对应到真实生活中：就好比是一个英国人为了表示祝福在纸上写了bless（编码过程）。而一个法国人拿到了这张纸，由于在法语中bless表示受伤的意思，所以认为他想表达的是受伤（解码过程）。这个就是一个现实生活中的乱码情况。
在计算机科学中一样：一个用UTF-8编码后的字符，用GBK去解码。由于两个字符集的字库表不一样，同一个汉字在两个字符表的位置也不同，最终就会出现乱码。
我们来看一个例子，假设我们用UTF-8编码存储“很屌”两个字，会有如下转换：
于是我们得到了E5BE88E5B18C这么一串数值，而显示时我们用GBK解码进行展示，通过查表我们获得以下信息：
解码后我们就得到了“寰堝睂”这么一个错误的结果，更要命的是连字符个数都变了。
10、如何识别乱码的本来想要表达的文字
要从乱码字符中反解出原来的正确文字需要对各个字符集编码规则有较为深刻的掌握。但是原理很简单，这里用以MySQL数据库中的数据操纵中最常见的UTF-8被错误用GBK展示时的乱码为例，来说明具体反解和识别过程。
10.1 第1步：编码
假设我们在页面上看到“寰堝睂”这样的乱码，而又得知我们的浏览器当前使用GBK编码。那么第一步我们就能先通过GBK把乱码编码成二进制表达式。
当然查表编码效率很低，我们也可以用以下SQL语句直接通过MySQL客户端来做编码工作：
mysql [localhost] {msandbox} > selecthex(convert('寰堝睂'using gbk)); hex(convert('寰堝睂'using gbk)) E5BE88E5B18C 1 row inset(0.01 sec)
10.2 第2步：识别
现在我们得到了解码后的二进制字符串E5BE88E5B18C。然后我们将它按字节拆开。
然后套用之前UTF-8编码介绍章节中总结出的规律，就不难发现这6个字节的数据符合UTF-8编码规则。如果整个数据流都符合这个规则的话，我们就能大胆假设乱码之前的编码字符集是UTF-8。
10.3 第3步：解码
然后我们就能拿着 _E5BE88E5B18C _用UTF-8解码，查看乱码前的文字了。
当然我们可以不查表直接通过SQL获得结果：
mysql [localhost] {msandbox} ((none)) > selectconvert(0xE5BE88E5B18C using utf8); convert(0xE5BE88E5B18C using utf8) 很屌 1 row inset(0.00 sec)
11、常见的IM乱码问题处理之MySQL中的Emoji字符
所谓Emoji就是一种在Unicode位于 _\u1F601-\u1F64F_ 区段的字符。这个显然超过了目前常用的UTF-8字符集的编码范围 _\u0000-\uFFFF_。Emoji表情随着IOS的普及和微信的支持越来越常见。
下面就是几个常见的Emoji（IM聊天软件中经常会被用到）：
那么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的时候是无法存储这样的字符的，所以报了错。
那么遇到这种情况我们如何解决呢？
有两种方式：
- 1）升级MySQL到5.6或更高版本，并且将表字符集切换至utf8mb4；
- 2）在把内容存入到数据库之前做一次过滤，将Emoji字符替换成一段特殊的文字编码，然后再存入数据库中。之后从数据库获取或者前端展示时再将这段特殊文字编码转换成Emoji显示。
第二种方法我们假设用 _-*-1F601-*- _来替代4字节的Emoji，那么具体实现python代码可以参见Stackoverflow上的回答。
12、参考文献
[1] 如何配置Python默认字符集
[2] 字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8
[3] Unicode中文编码表
[4] Emoji Unicode Table
[5] Every Developer Should Know About The Encoding
附录：更多IM开发方面的文章
[1] IM开发综合文章：
《 新手入门一篇就够：从零开发移动端IM》
《 移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《 移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《 从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《 现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《 腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《 小白必读：闲话HTTP短连接中的Session和Token》
《 IM开发基础知识补课：正确理解前置HTTP SSO单点登陆接口的原理》
《 移动端IM开发需要面对的技术问题》
《 开发IM是自己设计协议用字节流好还是字符流好？》
《 请问有人知道语音留言聊天的主流实现方式吗？》
《 一个低成本确保IM消息时序的方法探讨》
《 完全自已开发的IM该如何设计“失败重试”机制？》
《 通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《 微信对网络影响的技术试验及分析（论文全文）》
《 即时通讯系统的原理、技术和应用（技术论文）》
《 开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《 QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《 QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《 腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《 腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《 腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《 如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《 基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》
《 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《 腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《 字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》
《 全面掌握移动端主流图片格式的特点、性能、调优等》
《 子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《 自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《 融云技术分享：解密融云IM产品的聊天消息ID生成策略》
《 适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
《 拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
>> 更多同类文章 ……
[2] 有关IM架构设计的文章：
《 浅谈IM系统的架构设计》
《 简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《 一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《 一套原创分布式即时通讯(IM)系统理论架构方案》
《 从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《 蘑菇街即时通讯/IM服务器开发之架构选择》
《 腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《 微信后台基于时间序的海量数据冷热分级架构设计实践》
《 微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《 如何解读《微信技术总监谈架构：微信之道——大道至简》》
《 快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《 17年的实践：腾讯海量产品的技术方法论》
《 移动端IM中大规模群消息的推送如何保证效率、实时性？》
《 现代IM系统中聊天消息的同步和存储方案探讨》
《 IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《 IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《 IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《 WhatsApp技术实践分享：32人工程团队创造的技术神话》
《 微信朋友圈千亿访问量背后的技术挑战和实践总结》
《 王者荣耀2亿用户量的背后：产品定位、技术架构、网络方案等》
《 IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《 腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《 以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《 快速理解高性能HTTP服务端的负载均衡技术原理》
《 子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《 知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《 IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《 微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《 微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《 新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《 阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《 阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《 社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《 社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《 社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《 社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《 社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《 社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《 社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《 社交软件红包技术解密(八)：全面解密微博红包技术方案》
《 社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《 即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《 即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《 多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《 从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《 从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《 IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《 瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《 阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2868-1-1.html）