核心问题是WPS双击打开时默认用GBK解析UTF-8编码的CSV文件,导致字节错位显示“锟斤拷”;解决方法包括手动导入时选UTF-8编码,或导出时直接选用gb2312字符集以适配WPS。
phpMyAdmin 导出 CSV 乱码,核心问题不是编码选错了,而是 WPS 或 Excel 没按你导出的编码去读——它默认用 GBK 解 UTF-8 文件,字节错位必然出现“锟斤拷”。
双击打开乱码的 CSV 前,先用 VS Code 打开,看右下角状态栏显示的编码;或者终端执行:file -i your_file.csv。常见结果:
charset=utf-8 或 charset=utf-8-with-bom:phpMyAdmin 默认行为,但 WPS 双击不认 BOMcharset=iso-8859-1:导出时误选了 latin1 字符集charset=gbk 或 charset=cp936:少见,但若数据库本身是 gbk 排序规则且导出设为 gb2312,可能刚好匹配 WPSWPS「双击打开」会跳过编码选择,必须走导入流程:
UTF-8(不是“自动检测”,也不是 ANSI)逗号,「字段包围符」勾选 ",再点「加载」这个流程强制 WPS 按 UTF-8 解码,BOM 有无都不影响。如果选成 ANSI 或留空,默认就是 GBK,必然乱码。
与其每次手动选编码,不如让导出文件直接兼容 WPS:
CSV
gb2312(不是 utf-8,也不是 gbk),,「字段包围符」保持 ",「换行符」选 CRLF
选 gb2312 是因为 WPS 对它的兼容性最稳;虽然不能覆盖 emoji 或生僻字,但中文简体场景已足够。若数据含这些字符,才需坚持 UTF-8 + BOM + 手动导入。
如果你用 PHP 的 fgetcsv() 读这个文件再入库,乱码会延续到数据库:
fopen($file, 'r') 不带编码参数,底层按当前 locale 解——Windows 下常是 GBKmb_detect_encoding() 或 file -i 确认源文件编码,再用 iconv() 或 mb_convert_encoding() 转成 UTF-8,再喂给 fgetcsv()
xEFxBBxBF),并在 fopen() 后 fseek($fp, 3) 跳过,避免 fgetcsv() 把 BOM 当字段BOM 处理最容易被忽略:它不是可有可无的装饰,而是解码起点的锚点;漏掉或误判,整行字段都会偏移一格。