MySQL对JSON类型UTF-8编码导致中文乱码探讨

前言

继上文发表之后，结合评论意见并亲自验证最终发现是编码的问题，但是对于字符编码还是有点不解，于是乎，有了本文，我们来学习字符编码，在学习的过程中，我发现对于MySQL中JSON类型的编码导致数据中文出现乱码还有可深挖之处，接下来我们来分析一下，若有错误之处，还请批评指出。

字符编码

评论中指出任何不在基本多文本平面的Unicode字符，都无法使用MySQL的utf8字符集存储，包括Emoji 表情(Emoji 是一种特殊的Unicode 编码，常见于IOS和Android 手机上)和很多不常用的汉字，以及任何新增的 Unicode 字符等等(utf8的缺点)，然而啥是多文本平面，详情维基百科《https://en.wikipedia.org/wiki/Plane_(Unicode)》。首先我们了解下什么是Unicode，Unicode是通用字符集，它是一种标准，该标准在一处定义了编写在计算机上使用的大多数活动语言所需的所有字符，它的目标是成为并且在很大程度上已经是已编码的所有其他字符集的超集。在计算机或网络中的文本我们通过字符组成，字符代表字母、标点符号或其他符号。不同的组织收集了不同的字符集并为其创建了编码-一个字符集可能仅覆盖基于拉丁语的西欧语言(不包括保加利亚或希腊等欧盟国家)，另一个可能覆盖特定的远东语言(例如(例如日语)，其他语言可能是以特殊方式设计的，代表世界上某处其他语言的众多语言之一。但是我们并不能保证应用程序将支持所有编码，也不能保证给定的编码将满足我们代表给定语言的所有需求，另外，通常不可能在同一网页或数据库中组合不同的编码，因此使用“传统”编码方法来支持多语言页面通常非常困难，所以Unicode协会提供了一个大的，单字节字符集，旨在包括所有需要的世界上任何书写系统，包括古老的脚本(如楔形文字，哥特式和埃及的象形文字)的字符，所以统一字符编码，将其作为Web和操作系统体系结构的基础，并且得到所有主要Web浏览器和应用程序的支持。当前的Unicode字符分为17组编排，每组被称之为一个平面(Plane)，所以将字符划分为0-16号的平面，而每平面拥有65536(即2¹⁶)个代码点即范围区间在0x000到0xFFFF之间，而0号平面就是基本多语言平面(BMP：Basic Mutiingual Plan