用 file -i 查真实编码，输出含 charset=utf-8 才算真正 UTF-8；若为 charset=gbk 或 charset=iso-8859-1 需转码，charset=us-ascii 表明中文未存入，charset=binary 可能文件损坏，BOM（ef bb bf）须用 sed 或 VS Code 保存为无 BOM 的 UTF-8。
用 file -i 查真实编码（Linux/macOS）
编辑器里显示“utf-8”不等于文件真是 utf-8 编码。vs code 或 sublime 可能默认存成 utf-8 with bom，而 mysql 会把 bom（ef bb bf）当非法字符报错；记事本更常存成 gbk 或 iso-8859-1。
执行命令确认：
file -i dump.sql
输出含 charset=utf-8 才算靠谱；若显示 charset=iso-8859-1 或 charset=gbk，就得转码。
- 看到
charset=utf-8但导入仍乱码？再检查是否带 BOM（见下一条） - 看到
charset=us-ascii：说明文件纯英文，中文根本没存进去，别导入了 - 输出含
charset=binary：文件可能损坏或混入不可见控制字符
用 hexdump -C 检查 BOM 头（所有平台通用）
中文乱码但英文正常，八成是 UTF-8 with BOM 搞的鬼。BOM 会让 MySQL 把建表语句开头解析错位，导致后续中文字段值被截断或解码失败。
运行：
hexdump -C dump.sql | head -n 1
如果前三个字节是 ef bb bf，就坐实了 BOM 问题。
- Linux/macOS 快速清除：
sed -i '1s/^\xEF\xBB\xBF//' dump.sql - Windows 下别信记事本“另存为 UTF-8”，用 VS Code 打开 → 右下角点编码名 → “Save with Encoding” → 选
UTF-8（注意不是UTF-8 with BOM） - 别手动删文件开头的空格或换行——BOM 是不可见字节，删错位置反而破坏结构
Windows 用户绕过记事本陷阱的实操路径
记事本对编码的命名有严重误导：“UTF-8”选项实际存的是 UTF-8 with BOM；“ANSI”通常是 GBK（取决于系统区域设置），且不提示。
安全做法只有两个：
- 用 VS Code 打开 SQL 文件 → 右下角看当前编码（如显示
UTF-8 with BOM）→ 点击它 → 选Save with Encoding→ 选UTF-8（无 BOM） - 或用 PowerShell 一行转码：
Get-Content dump.sql -Encoding Default | Set-Content -Encoding UTF8 dump_utf8.sql（注意：PowerShell 的UTF8默认无 BOM） - 转完务必再用
file -i或hexdump验证，不能只信编辑器右下角显示
phpMyAdmin 导入页里选错编码的后果
即使文件本身是干净的 UTF-8 without BOM，如果在 phpMyAdmin 导入页底部把 Character set of the file 误选成 utf8 或 latin1，MySQL 会强行用该字符集去解码文件内容，结果就是 INSERT 语句里的中文字符串被当成乱码传入，最终存进数据库的是损坏数据。
- 必须选
utf8mb4：MySQL 的utf8是阉割版，最多存 3 字节，不支持 emoji 和部分汉字 - 这个下拉框控制的是“SQL 文件内字符串字面量”的解析方式，和数据库本身的 collation 是两回事
- 如果选错后点了「执行」，导入过程可能不报错，但查出来的中文是问号或方块——数据已损，只能重导
DEFAULT CHARSET=utf8mb4，结果表建出来还是 latin1，中文照样存不进去。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
