MySQL字符集那些坑和乱码问题，教你快速搞懂怎么设置不出错

很多人刚开始用MySQL的时候，都遇到过一串问号“？？？”或者一些根本看不懂的奇怪字符，这就是让人头疼的乱码问题，这个问题十有八九都和字符集的设置有关，今天我们就来把这件事彻底搞明白,让你以后再也不怕乱码。

要理解乱码，首先得知道什么是字符集，简单打个比方，字符集就像一本密码本，计算机本身只认识0和1，它需要一本密码本来规定哪个编号对应哪个字，在经典的gbk编码这本“密码本”里，两个特定的字节组合在一起，计算机就知道你要显示的是一个汉字“中”；而在utf8mb4这本更全的“密码本”里，则需要三个字节来代表“中”，如果存数据和读数据的时候，用的不是同一本“密码本”，计算机就会搞错,显示出来的自然就是乱码了。

解决乱码问题的核心就一句话：保证从始至终都使用同一种字符集。

在MySQL里，字符集设置不是一个地方，而是层层递进的，有“继承”关系，根据一些网络技术社区的总结，比如博客园、CSDN上很多开发者的经验分享，这个关系通常是：数据库服务器 -> 数据库 -> 数据表 -> 表字段 -> 客户端连接，如果上一级设置了字符集，下一级没有单独设置，就会自动沿用上一级的设置，理想情况下,我们应该让所有层级都统一。

你需要检查并确保以下几个关键点都设置正确：

第一，数据库本身的字符集。 这是最基础的，在创建数据库的时候，就应该指定好，现在强烈推荐使用utf8mb4，而不是老的utf8，这里有个经典的坑：MySQL里的“utf8”其实是个“阉割版”，它最多只支持3个字节的字符，而像一些emoji表情符号（）需要4个字节来存储，如果你用老的“utf8”字符集，尝试存emoji就会报错，而utf8mb4才是真正的“完全体”，支持所有Unicode字符，包括emoji，创建数据库的语句最好是这样：CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; 这里的COLLATE指的是排序规则，utf8mb4_unicode_ci是比较通用的一种,对大小写不敏感。

第二，数据表和字段的字符集。 只要数据库设置好了，创建表和字段时不指定，它们也会自动继承为utf8mb4，但为了保险起见，尤其是使用像Navicat这种图形化工具时,最好在建表时也显式地指定一下字符集。

第三，也是最最容易被忽略的一点：客户端的连接字符集。 这是导致乱码的最高发地带！想象一下，你的数据库是utf8mb4这本密码本，但你的应用程序（比如一个PHP脚本或Java程序）连接上来的时候，却告诉数据库：“我跟你说话用的是gbk密码本”，这时候，即使你存进去的数据没错,在传输和显示环节也已经乱套了。

必须在你的应用程序建立数据库连接之后，立刻执行一条命令来通知服务器本次连接使用的字符集，对于utf8mb4，这条命令是：SET NAMES 'utf8mb4';，这样，服务器、客户端、返回结果三方的字符集就统一了，很多现代的数据库连接库（如PHP的PDO）可以在连接字符串里直接设置字符集参数,这样就更加方便了。

如果已经出现了乱码怎么办？

别慌张，不要盲目地进行任何写操作，以免破坏原始数据,按照以下步骤排查：

1. 确认当前数据的真实编码：这有点像侦探工作，你需要先搞清楚现在数据库里存的那些乱码，当初到底是用什么字符集存进去的,可以通过一些工具或SQL语句进行猜测和验证。
2. 修复数据：如果确认是连接字符集不一致导致的，比如数据本身是utf8mb4，但被用gbk的方式误读了，那么修复的思路是：先用错误的字符集（gbk）把数据“读”出来（此时在内存里是乱码），然后再用正确的字符集（utf8mb4）重新“写”回去,这个过程可能需要编写临时的脚本来完成。
3. 统一设置：修复好数据后，务必按照上面说的，把数据库、连接字符集等所有环节都统一到utf8mb4,防止问题再次发生。

避免MySQL乱码的关键在于“防患于未然”，在新项目开始时就规划好，全程使用utf8mb4字符集，并且在应用程序连接数据库时，务必通过SET NAMES或等效方式明确指定连接字符集，只要你把这几个环节打通，统一起来，乱码问题基本上就和你无缘了，统一是根本，而utf8mb4是目前最推荐的选择。