服务器字符集和客户端字符集必须保持一致，否则必然出现乱码，解决方法是统一为UTF-8编码，并在连接时明确指定字符集。
服务器字符集和客户端字符集不一致怎么办？
乱码问题几乎每个开发者都踩过坑,根源在于字符集不匹配：服务器认为数据是UTF-8，客户端却用GBK解读，结果自然就是问号或乱码，行业共识认为，绝大多数乱码问题都是字符集不一致导致的。
乱码的根源：字符集不匹配
当你在客户端输入数据时,客户端会使用自己的字符集编码传输，如果服务器字符集（如character_set_server）和客户端字符集（如character_set_client）不同，服务器就会按自己的规则存储，最终读取时也会发生错误。这种不一致在数据插入时可能没有明显提示，但查询时就会暴露问题。
两步排查法：查看当前字符集设置
要解决问题,先确认现状，多数情况下，你只需要查看两个地方。
服务端字符集查看命令
登录MySQL后执行：
SHOW VARIABLES LIKE 'character_set_server'; SHOW VARIABLES LIKE 'character_set_database';
前者是服务器默认字符集,后者是当前数据库字符集，如果它们不是utf8或utf8mb4，就需要修改。character_set_server是全局性的，影响所有新建数据库的默认字符集。
客户端字符集查看命令
在客户端连接后,执行：
SHOW VARIABLES LIKE 'character_set_client'; SHOW VARIABLES LIKE 'character_set_connection'; SHOW VARIABLES LIKE 'character_set_results';
character_set_client是客户端发送数据的编码，character_set_connection是连接层使用的编码，character_set_results是服务器返回结果时使用的编码。它们必须一致，且与服务器端兼容。
统一修改为UTF-8的实操步骤
如果发现不一致,按以下步骤统一修改：
- 修改MySQL配置文件
my.cnf（或my.ini），在[mysqld]下添加：character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci - 在
[client]下添加：default-character-set=utf8mb4 - 重启MySQL服务,使配置生效。
- 对于已有数据库,修改库和表的字符集：
ALTER DATABASE dbname CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; ALTER TABLE tablename CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
注意：修改表字符集后，原有数据如果编码不兼容，需要先转换数据。建议在修改前备份数据，不少运维人员反馈，直接修改表字符集导致数据丢失，原因是存储的二进制没有改变，只是改变了元数据，所以转换前一定要确认数据编码与目标字符集兼容。
MySQL字符集设置教程：从服务器到客户端全链路
字符集配置不是单一环节,而是全链路的事情，很多人在修改了my.cnf后，发现网页依旧乱码，就是因为忽略了客户端连接时的字符集指定。
配置文件my.cnf的修改要点
除了前面提到的[mysqld]和[client]，还需要注意[mysql]和[mysqldump]等段。在[mysql]下添加default-character-set=utf8mb4，确保命令行客户端使用正确的编码，在[mysqldump]下添加default-character-set=utf8mb4，防止备份时转码出错。
客户端连接时的字符集指定
在应用程序中,连接MySQL后应立即执行：
SET NAMES 'utf8mb4';
这条命令会同时设置character_set_client、character_set_connection和character_set_results为utf8mb4。这是确保客户端字符集正确的关键一步。
对于PHP的PDO或MySQLi,可以在连接字符串中指定字符集，比如charset=utf8mb4，对于Java JDBC，则需在URL后添加?characterEncoding=utf8mb4
，对于Python的pymysql，可以在连接时传charset='utf8mb4'参数。这些细节容易被忽略，但往往就是乱码的根源。
已有数据的字符集转换注意事项
如果你需要将已有数据从GBK转换为UTF-8，不能直接改表字符集，因为底层存储的二进制没有变，正确的做法：
- 导出数据时指定原字符集：
mysqldump --default-character-set=gbk -u root -p dbname > data.sql - 修改导出的SQL文件,将
SET NAMES gbk改为SET NAMES utf8mb4，并将所有表定义中的字符集改为utf8mb4。 - 导入数据：
mysql --default-character-set=utf8mb4 -u root -p dbname < data.sql
这个过程稍显复杂，但能保证数据不丢失且编码正确，业内专家指出，这种“导出-转码-导入”方式是最稳妥的，尤其是数据量较大时。
数据库字符集UTF8和GBK的区别，如何选择？
这是很多新手纠结的问题。UTF8（尤其是UTF8mb4）是推荐选择，GBK只在特定旧系统中使用。
UTF8的优势：全球通用，避免乱码
UTF8可以编码全球所有文字,包括中文、日文、韩文、阿拉伯文等，而GBK只能编码中文和部分符号，如果你的应用需要支持多语言，甚至只是存储emoji，都必须使用UTF8mb4（UTF8的超集）。近年来，新项目普遍选择UTF8mb4作为默认字符集，因为它完全兼容UTF8，额外支持4字节字符。
GBK的局限：仅支持中文，其他语言乱码
GBK是中文简体扩展编码,只能表示中文和一些特殊字符，如果用户输入了日文或希腊字母，直接存储GBK就会变成问号。从兼容性角度看，GBK已经不再是合理选项，在Windows本地环境中，GBK仍有一定使用场景，但一旦涉及跨平台或互联网，UTF8是唯一保险的选择。
场景推荐：多语言应用选UTF8mb4
| 场景 | 推荐字符集 | 理由 |
|---|---|---|
| 纯中文网站，无特殊字符 | UTF8 | 足够，占用空间小 |
| 支持emoji、多语言评论 | UTF8mb4 | 必须，否则emoji报错 |
| 旧系统迁移，数据量巨大 | GBK（暂保留） | 优先保证数据完整，新表用UTF8mb4 |
| 国际化应用，面向全球 | UTF8mb4 | 唯一选择，避免后续转码麻烦 |
如果你拿不准，选UTF8mb4准没错，这是最通用的方案。
服务器字符集和客户端字符集常见问题
问：我修改了my.cnf，但网页还是乱码，为什么？
答：很可能是因为客户端连接时没有指定字符集，请检查应用程序中是否执行了SET NAMES 'utf8mb4'，或者连接字符串中是否设置了charset=utf8mb4，网页本身的head中也需要声明<meta charset="UTF-8">，确保浏览器正确解码。如果还乱码，排查HTML文件本身的编码格式是否与声明一致。
问：如何查看当前会话的字符集？
答：在MySQL中执行SHOW VARIABLES LIKE 'character_set%';，可以查看所有与字符集相关的变量，包括character_set_client、character_set_connection、character_set_server、character_set_database等，确保它们都是utf8mb4。如果某个变量不是utf8mb4，对应修改配置文件或连接参数即可。
问：服务器字符集和客户端字符集不一致，但数据没有乱码，可能吗？
答：可能性很低，但存在，如果客户端和服务器使用的字符集虽然不同，但都能兼容当前数据的编码（比如都是单字节编码），或者数据本身不包含特殊字符，可能暂时看不出乱码，但一旦插入新字符，问题就会暴露。为了长远稳定，建议保持字符集统一，不要心存侥幸。
回到最开始：服务器字符集和客户端字符集必须一致，否则乱码是必然的，从配置到应用，每一步都确认字符集正确，才能彻底告别乱码烦恼。
首发原创文章，作者：王坚，如若转载，请注明出处：https://test.idctop.com/article/561987.html
