系统环境：

操作系统：MAC OS 10.11.6

MySQL：Server version: 5.6.21 MySQL Community Server (GPL)

Navicat for MySQL: version 9.3.1 - standard

1、问题发现

    在客户端执行用户注册，用户名包括 emoji 表情符号，注册完成后，在 APP 客户端以及网页前端都可以正常显示带 emoji 符号的用户昵称，说明数据在数据库内部的存储是正常的，为什么在 Navicat for mysql 客户端里打开“用户表 tb_user”，显示的“用户昵称 nick_name”是乱码呢？

mysql> select nick_name from tb_user where id = 91;
+---------------+
| nick_name     |
+---------------+
| 涛声依旧? |
+---------------+
1 rows in set (0.03 sec)

    如上，查询结果的的用户昵称【涛声依旧?】，出现了一个问号，这里本应该是一个 emoji 表情符号。 该字段的字符集已经设置为 utf8mb4，可以兼容 4 个字节的 emoji 符号，所以不是数据存储的问题。初步猜测是从数据库查询获取到数据后返回给客户端的过程中出了问题？！

2、问题分析

    MySQL 采用的是 C/S 架构，所以它有服务端和客户端（如：MySQL 自带的客户端、Navicat for MySQL等）, 如果两端分布在不同的的主机上，那么两端通常需要通过 TCP/IP 或其它协议建立连接，然后实现通信或数据传输。跟 HTTP 协议有些类似，HTTP 发起请求时会在 Header 里附上客户端「信息体」采用的字符集。同理，MySQL 两端也需要提前沟通好通信采用的字符集，否则服务器端不知道客户端要的是什么，客户端也不知道服务端给的是什么，也就是鸡同鸭讲，乱码就会出现了。

    MySQL提供了 character_set_client、character_set_connection 和 character_set_results 三个字符集变量来辅助客户端与服务端的通信。

• character_set_client：服务器会将请求（如：一条 SQL 查询语句）的字节序列当作采用 character_set_client 字符集进行编码的字节序列。假如客户端请求的 mysql 语句的编码是UTF8, character_set_client 的值为 GBK，那么服务器按 GBK 编码来接收，两者编码不一致，请求的 where  nick_name = "A" 被错误认为是 where  nick_name = "B" 了，自然返回的数据就不正确或者查询数据为空。
• character_set_connection：连接数据库时的字符集。
• character_set_results：数据库给客户端返回数据时使用的字符集。

    一般显示出现乱码，通常和字符集变量设置有关，我们知道字符集与数据库存储数据有关系，但客户端（Navicat）和服务端之间的交互也受到字符集影响。客户端发起请求的查询语句与返回客户端的结果都与字符集（编码）有关。

    上面提过，APP客户端以及网页前端都正常显示，表字段的字符集设置也是正确的。说明数据存储是没问题的，问题很可能出在 Nacatcat 客户端与 MySQL 服务端的交互上，也就说跟上面三个字符集变量有关系。

    现在我们在 Navicat 客户端打开 console 窗口查询下这三个变量的值：

show variables like "character_set%";

    结果：

    可以看到，这三个变量的字符集都是 utf8,，mysql 里的 utf8 字符集并不是真正的 utf8, 而是阉割版的，最长只有3个字节。utf8 字符集存储简体中文没有问题，但是存储 4 个字节的 emoji 字符就不够用了。

    从上面查询结果的情况来看，返回了正确的结果（只是格式不对），客户端和服务器两端在发送请求和接受请求的过程中没有因为字符集不匹配导致出错，所以 character_set_client 的字符集变量的值没有问题。

    排除了 character_set_client 的嫌疑，接着来看 character_set_results = utf8,  表示查询结果会按这个字符集进行编码。查询的字段（nick_name）包含 emoji 表情符号，在数据库内部以 ut8mb4 字符集存储，在读取后会被转成了 utf8  字符传给 Navicat 客户端，由于两个字符集的字符编码并不一致，所以 Navicat 客户端这边显示出来就成了乱码。

    既然发现问题，就好办了，我们把这三个变量（其实只需要设置 character_set_results ）设置为可以兼容 emoji 表情的的字符集 utf8mb4 即可。

# 等效于将三个变量同时设置为utf8mb4字符集
set names utf8mb4# 单独设置一个变量
set character_set_results=utf8mb4;

    修改后再次查询，可以看到，这个 emoji 表情已经可以正常显示了。

3、问题解决

    注意：上面提到的三个字符集变量是受作用域限制的，都属于同一个 Session 作用域，我们打开 Console 窗口，相当于在客户端与服务器新建了连接，这三个字符集变量的值只在当前 Session 作用域有效。当我们重新打开一个新的窗口或连接，仍然会恢复之前的字符集（UTF8）设置。

    Navicat 客户端打开数据表查看数据的操作与在 Console 窗口执行查询语句是一样的道理，表格里的数据都是查询后返回的数据，所以也同跟上面三个字符集变量有直接关系。那么怎么才能让 Navicat 客户端打开数据表始终可以看到正常的 emoji 表情呢？

    其实 Navicat for Mysql 客户端有个数据库的「连接属性」设置面板，在里面可以设置「客户端字符集」，这个与在 MySQL 安装目录 my.conf | my.ini 进行配置效果是一样的，可以实现让客户端和服务器每次连接都根据这里的配置预先设置好上面三个字符集变量。

4、结语

    这里只是抛砖引玉，分析了 emoji 字符乱码出现的场景，其他类似的在任何客户端出现「字符乱码」的情况都可以参考这个思路去分析，也就是说从字符的「存储」和「传输/交互」两个角度去分析，总会找到问题的根源。

    以上出现了一些关于「字符集」的术语，其实 MySQL 的一些莫名其妙的「乱码」都与它密切相关。 所以有必要对 MySQL 字符集有清晰透彻的理解。如果你想真正理解  MySQL 字符集，可以参考笔者另外一篇文章：

MySQL 字符集概念、原理及配置之图文详解