phpMyAdmin 导出 SQL 中文乱码需在 Custom 导出中选 gbk 编码、替换文件头 SET NAMES utf8mb4 为 SET NAMES gbk，并确保 MySQL 服务端支持或导入时指定 --default-character-set=gbk。
导出时选错编码导致中文乱码
phpmyadmin 导出 sql 文件时，默认用 utf-8 编码保存，但如果你后续要在旧版 mysql 客户端、某些 windows 工具（比如老版本 navicat 或 excel）里直接执行或查看，遇到 gbk 环境，就会显示问号或乱码。这不是数据丢了，是编码声明和实际字节不匹配。
关键不是“转换”，而是导出时让 phpMyAdmin 用目标环境能正确读取的编码生成文件，并确保 SQL 头部声明一致：
- 导出格式选
Custom（不是快速导出），展开Format-specific options - 找到
Export character set下拉框，选gbk（不是gb2312或gb18030，除非你明确知道目标环境只认那个） - 勾选
Enclose export in a transaction和Add DROP TABLE / VIEW / PROCEDURE / FUNCTION / EVENT statement这类选项跟编码无关，别被带偏 - 导出后，用记事本或 VS Code 打开，确认文件开头没有
SET NAMES utf8mb4这类语句——如果有，手动替换成SET NAMES gbk，否则导入时 MySQL 仍按 UTF-8 解析字节
导入前必须确认 MySQL 服务端的字符集配置
光导出为 gbk 不够。如果 MySQL 服务端的 character_set_server 是 utf8mb4，且连接时没指定 charset=gbk，那即使 SQL 文件里写了 SET NAMES gbk，也可能被忽略或覆盖。
检查方法：登录 MySQL 后执行 SHOW VARIABLES LIKE 'character_set%';，重点关注三处：
-
character_set_client：客户端发来的语句按什么编码解析 -
character_set_connection：连接层转码用的中间编码 -
character_set_database：当前库默认编码，影响新建表字段
若要安全导入 gbk 编码的 SQL，建议在导入命令前加 SET NAMES gbk;，或者用命令行导入时加参数：mysql --default-character-set=gbk -u root -p db_name
UTF-8 和 GBK 字段内容混存时不能简单替换编码
如果数据库里已有部分字段是 UTF-8 存的中文，另一部分是 GBK 存的（比如早期不同程序写入），导出时统一选 gbk 会导致后者正常、前者全乱——因为 phpMyAdmin 不做内容检测，它只是把字段值原样按指定编码写进文件。
这种场景下，导出前得先确认数据来源和存储一致性：
- 查某字段是否真为 GBK 编码：用十六进制工具看该字段值的原始字节，对照 GBK 编码表验证
- 不要依赖
SHOW CREATE TABLE的CHARSET声明，它只表示字段定义，不保证历史数据真实编码 - 真有混合情况，得先用 PHP 或 Python 脚本逐行 decode/encode 转换内容，再导出，而不是靠 phpMyAdmin 一键解决
用 mysqldump 替代 phpMyAdmin 更可控
phpMyAdmin 的编码选项藏得深、行为不透明（比如有时忽略 Export character set 设置），遇到批量或生产环境导出，直接用命令行更稳。
例如导出为 GBK：
mysqldump --default-character-set=gbk -u root -p --skip-set-charset --skip-triggers database_name > dump_gbk.sql
注意两个关键参数：
-
--default-character-set=gbk：告诉 mysqldump 用 GBK 读取数据并写入文件 -
--skip-set-charset：防止它自动插入SET NAMES utf8mb4这类语句，避免覆盖你的意图
导出后用 file -i dump_gbk.sql（Linux/macOS）或 VS Code 编码识别功能确认文件真是 GBK 编码，而不是 UTF-8 BOM 伪装
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
