phpMyAdmin导出字段乱码多为编码错位而非数据损坏，需先用SELECT HEX()验证数据库中是否仍存正确UTF-8字节，再据文件真实编码（如VS Code右下角或file -i）选择对应导出与解析方式。
phpmyadmin 导出后字段乱码，不是数据丢了，而是编码错位导致字节被误读。恢复的前提是：原始数据在数据库里仍是正确的 utf-8 字节（这是最常见情况），只是导出时用了错误的 set names 或文件保存编码，让中文变成乱码字符串写进了 csv/sql 文件。直接改文件内容只会雪上加霜。
先确认乱码是“假乱码”还是“真损坏”
别急着转码或重导，先验证数据本身是否完好：
- 在 phpMyAdmin 中执行
SELECT HEX(字段名) FROM 表名 LIMIT 1，如果返回类似E4B8ADE69687（即“中文”的 UTF-8 十六进制），说明数据库里存的是对的，乱码只发生在导出环节 - 如果返回的是
C4E3BAC3这类短十六进制（对应 GBK 编码），说明数据入库时就被当 GBK 解过一次，属于连接层错配，需回溯导入前的 SET NAMES 设置 - 用 VS Code 打开导出的 CSV 或 SQL 文件，右下角看真实编码；或终端运行
file -i your_file.csv，结果为charset=utf-8-with-bom但 WPS 显示乱码，基本可判定是解析错位，不是数据损坏
CSV 导出字段乱码：绕过 phpMyAdmin 编码陷阱
phpMyAdmin 默认按语言设置发 SET NAMES，但 CSV 导出不走这条路径，它直接按当前连接字符集 dump 字节 —— 如果连接是 latin1，哪怕表是 utf8mb4，CSV 里也会是乱码字节。
- 导出前，在 phpMyAdmin 的 SQL 标签页手动执行
SET NAMES utf8mb4，再点「导出」→「CSV」→「自定义」 - 「文字字符集」必须选
gb2312（不是 UTF-8，也不是 GBK）：WPS 对 gb2312 的兼容性最稳，且能覆盖绝大多数简体中文，避免 BOM 识别失败 - 如果必须用 UTF-8（比如含 emoji），导出后不要双击打开，而要用 WPS 「数据」→「从文本/CSV」→「文件原始格式」选
UTF-8（不能选自动检测） - 导出时勾选「包含列名称」，并确保「字段包围符」为
"、「换行符」为CRLF，减少 fgetcsv() 解析错位风险
SQL 导出字段乱码：Language 设置决定一切
导出 SQL 文件时，SET NAMES 指令由顶部 Language 下拉框决定，跟数据库实际字符集无关。选错语言，INSERT 语句里的中文字符串就是错的字节。
- 导出前，顶部菜单 Language 必须选
Chinese simplified (zh-utf-8)—— 注意后缀是-utf-8，不是-gb2312，也不是没后缀的 English - 导出后立刻用
head -n 3 your.sql检查第一行是否为SET NAMES utf8mb4；如果不是，说明 Language 没生效，可能版本太旧，需修改libraries/database_interface.lib.php第 168 行附近过滤逻辑 - 「自定义导出」里的
Export character set下拉框无效，它只影响注释，不影响 INSERT 值的编码，别在这儿浪费时间 - 导出文件若被记事本二次保存，会悄悄加 BOM 或转成 ANSI，务必用 VS Code/Notepad++ 保存为
UTF-8 without BOM
fgetcsv() 读取后仍乱码：PHP 层要主动对齐
即使 CSV 文件编码正确，PHP 的 fgetcsv() 默认按系统 locale 解码（Windows 常是 GBK），不会自动识别 UTF-8 BOM，导致读出来还是乱码。
立即学习“PHP免费学习笔记（深入）”；
- 不要直接
fopen($file, 'r')，先用mb_detect_encoding(file_get_contents($file), ['UTF-8', 'GB2312', 'GBK'], true)探测真实编码 - 读取前转码：
$content = iconv('GB2312', 'UTF-8//IGNORE', file_get_contents($file))，再写入临时文件或用str_getcsv()解析 - 更稳妥做法：导出时手动加 BOM（
\xEF\xBB\xBF），fopen后先fseek($fp, 3)跳过，再喂给fgetcsv() - 数据库写入前，确保 PDO 或 mysqli 连接已执行
SET NAMES utf8mb4，否则INSERT时又会错解一遍
真正难恢复的是那些已被多次转码、HEX 值已不可逆错乱的字段 —— 比如原先是 UTF-8，被当 latin1 读出再存进另一个 latin1 字段，再导出成 GBK，这种链式错位基本无法自动还原。所以每次导出前，务必先验证 HEX() 和 file -i，比事后补救可靠十倍。
