ref:http://cenalulu.github.io/linux/character-encoding/
什么是字符集 和编码
在计算机存储介质中存放的实际是二进制的比特流，为了实现各种文件的转换标准，各种字符集标准就出现了，简单说字符集 规定了某个文字对应的二进制数字存放方式(编码)和某串二进制数值代表了哪个文字(解码)的转换关系。
什么是字符编码
字符集是一个规则集合的名字，对应真实生活中，字符集就是对某种语言的称呼，例如：英语，汉语，日语。对于一个字符集来说要正确编码转码一个字符需要三个关键元素：
字库表(character repertorie)
编码字符集(coded character set)
字符编码(character encoding form)
字库表
相当于所有可读与可显示字符的数据库，字库表决定了整个字符集能够展现表示的所有字符的范围
编码字符集
用一个编码值code point 来表示一个字符在字库中的位置。
字符编码
存储 编码字符集 和 实际存储数值 之间的转换关系，一般说都会直接将code point值作为编码后的值存储，例如ascii 中的A 在表中排65位，编码后的二进制位0100 0001 表示十进制的65
Question?
通过字库表和编码字符集，既然每个字符都有一个自己的序号，将序号作为存储内容就ok?，为什么需要个字符编码，将序号转换为另一种存储格式呢？
Answer: 字库表中的目的是涵盖世界上所有的字符，但实际使用中会发现不同语言国家使用别的字符的几率非常低(例如中文语言不会使用法语字符等)而一些英语国家明明能使用一个字节表达一个英文字符，你不能让它用三个字节表达一个英文字符吧，这样会造成浪费。
于是乎，出现了UTF-8这样的变长编码。在utf-8中一个英文依然使用1个字节，而中文需要2到3个字节。
可以明白，通过不同的字符编码，各个语言字符能更好的优化各语言的存储等。
UTF-8 和 Unicode的关系
回答了上面的Question后，就很好的解释了UTF-8和Unicode的关系，Unicode 是上面提到的编码字符集，而UTF-8是字符编码。UTF-8 是Unicode规则字库的一种实现形式，Unicode几乎涵盖了各个国家语言可能出现的符号和文字，并将它们编号。
Unicode 的编码从0000 开始 一直 到 10FFFF 共17 * 65536(Plane) 个字符。而UTF-8 则只是实现了第一个Plane，可以明白，虽然UTF-8是接受度最广的字符编码，但是它并没有涵盖整个Unicode的字库，这也造成了某些场景下对于特殊字符的处理具有困难。
2^4 = 16
2^8 = 256
2^16 = 65536
UTF-8 编码简介
UTF-8编码为变长编码，最小编码单位1个字节，一个字节的前1-3个bit为描述性部分，后面为实际序号部分。
1> 如果一个字节的第一位为0， 那么表示当前字符为单字节，后面的7的bit 代表Unicode中的序号(表示1-128)
2> 如果字节以110开头那么表示当前字符为双字节字符，占用2个字节空间（后面的 5个bit加后面的除10开头外的6个bit） 11个bit代表在Unicode中的序号，注意第二个字节以10开头
3> 如果一个字节以1110 开头，那么代表当前字符为三字节字符，占用3个字节空间。1110之后的所有部分(4bit)加上后两个字节出去开头的10外部分(12bit)代表在Unicode中的序号。
4> 如果一个字节以10开头，那么代表当前字节为多字节字符的第二个字节。10之后的所有部分(6bit)和之前的部分一同组成在Unicode中的序号。
以下直观反映：
可以看出以下规律
> 3个字节的UTF-8十六进制编码一定是以E开头的
> 2个字节的UTF-8十六进制编码一定是以C或D开头的
> 1个字节的UTF-8十六进制编码一定是以比8小的数字开头的
乱码原因
编码和解码时用了不同或者不兼容的字符集
在计算机科学中一样，一个用UTF-8编码后的字符，用GBK去解码。由于两个字符集的字库表不一样，同一个汉字在两个字符表的位置也不同，最终就会出现乱码
例如 UTF-8 表示的两个中文字符的16进值为 E5BE88 E5B18C (三个字节一个汉字)
而使用GBK解码时(2个字节一个汉字) E5BE 88 E5 B18C 导致乱码
解决乱码 的方式也可以明确，将乱码的字符 按相关错误的编码转换为字节，得到原始字节，再按正确的字符编码进行解码
常见的乱码 是Emoji 表情，该字符的位置不在UTF-8字符集编码范围。而当我们要存储这样的字符时出现了问题，通常来说数据库的字符集会被设置成UTF-8(三字节，110开头，四字节1111 0000(f0))，所以当数据库中遇到有F开头的16进制时，意味着4字节编码想要存放到3字节编码的库中，这显然是行不通的。
那么如何解决how?
1 升级mysql 到5.6+ 以使用能支持4字节的字符集utf8mb4
2 在内容存储前做一次过滤，将Emoji字符替换为一段特殊的文字编码，然后持久化，在获取数据时再按相关规则转换Emoji显示。