phpMyAdmin 导入 SQL 文件乱码的根本原因是编码层级未对齐：文件编码、phpMyAdmin 手动指定的“Character set of the file”（必须选 utf8mb4）、MySQL 会话层（需 SET NAMES utf8mb4）、数据库、表及字段默认字符集均须统一为 utf8mb4，任一环节错配即导致中文变乱码或问号。
phpMyAdmin 无法识别 SQL 文件的编码，不是它“读不懂”，而是它根本没按你期望的方式去读——它不自动探测编码，只依赖你手动指定或配置默认值。一旦你选错、漏选、或文件本身带 BOM，它就会把 UTF-8 字节当 latin1 解，中文立刻变 æ–‡ 或 ???。
为什么“文件显示正常”不代表编码正确
VS Code 或记事本显示中文没问题，只说明编辑器猜对了编码，不代表文件真实编码就是 UTF-8。尤其 Windows 记事本“另存为 UTF-8”默认带 BOM，而 phpMyAdmin 把 BOM 当非法字符直接拒收，报错可能静默（页面空白）或提示语法错误（ERROR 1064 开头乱码）。
- 用
file -i dump.sql（Linux/macOS）或 VS Code 右下角编码标识确认真实编码，别信文件名或编辑器标题栏 - Windows 用户务必用 VS Code 打开 → 右下角点编码名 → Save with Encoding → 选
UTF-8（不是UTF-8 with BOM） - 如果
file输出含charset=us-ascii，大概率是 GBK/GB18030 文件被误标，需用iconv -f gbk -t utf8mb4 dump.sql > dump_fixed.sql转换
phpMyAdmin 的“Character set of the file”选项必须手动选对
这个下拉框默认常为空或 auto，但 auto 在 phpMyAdmin 里基本等于“按 latin1 解析”。哪怕文件是 UTF-8，不手动选 utf8mb4，它就绝不会主动切过去。
- 导入前必须在
Import页面找到 Character set of the file，明确选utf8mb4 - 不要选
utf8：MySQL 的utf8是阉割版，不支持 emoji，且与utf8mb4排序规则不兼容 - 如果选了
utf8mb4还乱码，回头检查 SQL 文件开头是否含SET NAMES utf8mb4;—— 没这句，会话层编码仍可能 fallback 到库默认值（常为latin1）
目标库字符集不匹配，文件再准也白搭
SQL 文件是 UTF-8，phpMyAdmin 也选了 utf8mb4，但如果数据库、表、字段的默认字符集仍是 latin1 或旧版 utf8，插入时 MySQL 会强制转码，中文秒变问号。
- 导入前执行：
ALTER DATABASE your_db_name CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci; - 检查已有表：
SHOW CREATE TABLE your_table;，若没DEFAULT CHARSET=utf8mb4，补上：ALTER TABLE your_table CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 新建库时显式指定：
CREATE DATABASE your_db_name CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
真正卡住人的从来不是“怎么转编码”，而是“哪一层没对齐”——文件编码、phpMyAdmin 声明、MySQL 会话层、数据库默认值、表定义、字段定义，六层里只要断一环，乱码就必然出现。别跳步，一层层验证。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
