数据库utf8显示乱码为啥会变成GNK，字符集到底咋回事儿分析下

这个问题其实非常典型,它不是一个错误，而是一连串环节中某个地方“对不上号”导致的，要理解它，我们得把数据从进入数据库到显示在网页或软件上的整个过程拆开来看，你说的“GNK”很可能是个笔误或显示错误，更常见的乱码形式是“锟斤拷”或“黑方块”等，但其核心原理是相通的，我们就以最常见的“UTF-8乱码变成奇怪汉字”为例来深入分析。

核心矛盾：编码和解码用的“字典”不一致

要把字符集想象成一本本不同的“字典”，一本叫“GBK”的字典是中国人常用的，里面收录了所有简体中文汉字，每个汉字对应一个编号，另一本叫“UTF-8”的字典是国际通用的，它雄心勃勃地想要收录全世界所有语言的字符，所以它的编号规则更复杂，能表示的字符也多得多。

乱码的根本原因就是：存数据的时候用的是A字典，但取数据的时候，却错误地用了B字典去查，你拿着UTF-8字典里某个字的编号，却去GBK字典里找这个编号对应的字，找到的当然是一个毫不相干的字，这就是乱码。

乱码产生的具体环节分析

我们跟踪一段中文数据“你好”的旅程，看看它在哪个环节会出问题。

1. 理想情况（正确流程）：

   • 应用程序处理： 你在一个网页表单里输入“你好”，这个网页的代码声明了使用UTF-8编码（<meta charset="UTF-8">），浏览器用UTF-8规则将“你好”转换成二进制序列，准备发送给服务器。
   • 数据库连接： 服务器的程序（如PHP、Java）通过数据库连接器连接MySQL，这个连接器必须明确告诉数据库：“我接下来发给你的数据，都是UTF-8格式的”，通常这需要通过一条类似SET NAMES 'utf8'的命令来完成。
   • 数据库存储： 数据库收到指令后，确认连接通道是UTF-8的，于是它正确地接收了“你好”的UTF-8二进制数据，并将其存入一个本身也是UTF-8编码的数据库表中。
   • 数据读取与显示： 当需要显示数据时，程序再从数据库取出二进制数据，通过同样是UTF-8设置的连接通道传回给网页，网页也以UTF-8方式解码，最终完美显示出“你好”。

2. 问题情况（产生乱码的常见场景）： 乱码通常发生在第2步“数据库连接”和第3步“数据库存储”的设置不匹配上，根据参考资料中的常见情况分析，主要有以下两种：

   • 场景A：连接声称是GBK，但数据实际是UTF-8（产生“锟斤拷”）。 这是最经典的一种，假设你的应用程序在发送“你好”的UTF-8二进制数据时，没有正确设置连接编码，或者错误地将连接编码设置成了GBK。

     

     • 发生了什么：数据库连接器对数据库说：“喂，我接下来发给你的数据是GBK格式的哦！”然后它就把“你好”的UTF-8编码的二进制流送了过去。
     • 数据库的反应：数据库一听是GBK，就忠实地把这些二进制数据当作GBK编码来解读，但UTF-8和GBK的编码规则天差地别，数据库会错误地将这段UTF-8字节流“翻译”成一组在GBK字典里存在的、但完全错误的汉字，当这些错误数据被存回数据库，之后再被正确读取时，就会显示出一堆莫名其妙的汉字，其中非常典型的就是“锟斤拷”，这是因为某些特定的UTF-8字节序列恰好对应GBK中的“锟”、“斤”、“拷”这些字。

   • 场景B：连接声称是UTF-8，但数据库表是GBK（显示为黑方块或问号）。 另一种情况是，连接通道设置是正确的UTF-8，但数据库或那张表的字符集本身被设置成了GBK或其他非UTF-8编码。

     • 发生了什么：程序正确发送了“你好”的UTF-8数据，连接也正确声明了是UTF-8，数据库接收后，试图将这些数据存入一个GBK编码的表中。
     • 数据库的反应：问题来了，GBK字库的容量远小于UTF-8，虽然“你好”这两个常见字在GBK里有，但很多其他UTF-8字符（如生僻字、emoji表情）在GBK里根本找不到对应，数据库在存储时可能会进行一种“有损”转换：如果这个字在GBK里有，就存下去；如果没有，它可能会被替换成一个问号“？”或一个黑色方块“□”，表示“无法识别”，这种情况下，数据本身已经受损，即使以后用UTF-8读取，丢失的字也找不回来了。

结论与解决办法

“数据库UTF8显示乱码”根本原因在于整个链条的字符集不统一，所谓的“变成GNK”或奇怪汉字，是错误解码的直观体现。

要解决这个问题,必须保证“三码合一”：

1. 源头的编码：确保你的应用程序（网页、软件）生成数据时使用UTF-8。
2. 传输的通道：确保你的程序连接数据库时，明确指定使用UTF-8字符集（例如在连接字符串中加入characterEncoding=UTF-8，或执行SET NAMES 'utf8mb4'命令，注意MySQL的utf8是阉割版，最好用utf8mb4）。
3. 终端的存储：确保你的MySQL数据库、甚至具体到表、字段的字符集都设置为utf8mb4。

乱码就像一场传话游戏,只要中间有一个人用错了字典，最后听到的意思就全变了，解决之道就是让所有参与方——从应用程序、数据库连接到数据库本身——都统一使用同一本最全的“国际字典”，也就是UTF-8（具体为utf8mb4）。