phpMyAdmin 5.2不支持带BOM的UTF-8文件，必须清除BOM：用head -c 6 file | xxd或HxD确认EF BB BF，再通过VS Code另存为UTF-8（无BOM）或iconv -f UTF-8 -t UTF-8//IGNORE修复。
phpMyAdmin 5.2不支持带BOM的UTF-8文件，必须先清除BOM
phpMyAdmin 5.2在解析上传的CSV或SQL文件时，会把UTF-8 BOM（\xEF\xBB\xBF）当作普通字节吞掉，导致首字段错位、表名/库名开头多出不可见字符、SET NAMES语句被截断等静默错误。它没有“跳过BOM”逻辑，也不提供编码自动探测——所谓“选utf8mb4编码导入”对带BOM文件完全无效。
怎么快速确认并清除BOM
别信编辑器右下角写的“UTF-8”，那是误导。真实依据只有两个：
- Linux/macOS运行：
head -c 6 your_file.csv | xxd，输出含ef bb bf即确认有BOM - Windows用HxD打开，看前3字节是否为
EF BB BF
清除方法要分场景：
- VS Code打开 → 右下角点击编码名（如“UTF-8 with BOM”）→ 选“Save with Encoding” →
UTF-8（注意不是“UTF-8 with BOM”） - Linux/macOS命令行（仅限纯ASCII表名/字段名）：
sed -i '1s/^\xEF\xBB\xBF//' your_file.sql - 更稳妥通用（含中文内容）：
iconv -f UTF-8 -t UTF-8//IGNORE your_file.csv > clean.csv
临时绕过BOM失败的导入法：用latin1骗过解析层
仅限紧急救急，且只对CSV有效（SQL文件不行）。原理是让phpMyAdmin不转码，原样传给MySQL，再靠MySQL内部按utf8mb4解释：
立即学习“PHP免费学习笔记（深入）”；
- 确保CSV已是UTF-8无BOM（否则这步也失败）
- 导入页面中，“Character set of the file”下拉框选
latin1（不是空着，也不是auto） - 目标表字段必须已设为
CHARSET=utf8mb4，否则MySQL收到字节后仍当latin1存
这个技巧不能修复已带BOM的文件，只是规避BOM被误读——前提是BOM已被清除，否则latin1模式下BOM三字节会变成三个乱码字符，写进第一列值里。
为什么“另存为UTF-8”不一定管用
很多编辑器（如旧版Notepad++、Sublime Text默认配置）标称“UTF-8”，实际保存的是UTF-8 with BOM。PHP写文件时file_put_contents($f, "\xEF\xBB\xBF" . $content)也会主动加BOM，而phpMyAdmin对这种文件毫无容错能力。真正关键的不是“有没有UTF-8”，而是“有没有那三个开头字节”。一旦BOM存在，后续所有字符集设置、分隔符选择、字段映射都可能偏移一位——这点在首行为字段名的CSV里尤其致命，会导致user_id被识别成 user_id（前面多一个空格），进而触发Unknown column 'user_id '报错。
