答案是乱码根源在MySQL连接层字符集错配，而非导出设置；导出前需执行SET NAMES utf8mb4并确认character_set_client/connection/results均为utf8mb4，Language设为zh-utf-8才能确保正确读取与导出。
phpMyAdmin 导出查询结果乱码，**不是文件保存错了，而是导出前 MySQL 连接层用错字符集读取数据，导致字节流被错误转义后写进文件**。只要连接层字符集和数据库实际编码不一致，哪怕你手动选“UTF-8”导出，照样乱码。
导出前先确认当前连接的字符集是否匹配数据真实编码
乱码根源往往不在导出界面，而在执行查询那一刻——phpmyadmin 用什么字符集从 mysql 拿数据，决定了导出内容的字节形态。
- 在
phpMyAdmin的 SQL 标签页中运行：SHOW VARIABLES LIKE 'character_set%'; - 重点关注
character_set_client、character_set_connection、character_set_results三项值 - 如果其中任意一项是
latin1或utf8（即 utf8mb3），而你的表字段实际是utf8mb4，那导出结果必然错位 - 临时验证：执行
SET NAMES utf8mb4;后再查再导，看是否恢复；若恢复，说明问题就卡在这儿
Language 设置决定 SET NAMES，不是导出页下拉框
phpMyAdmin 导出 SQL 或 CSV 时插入的 SET NAMES 命令，由顶部「Language」菜单决定，跟导出页里那个「Export character set」下拉框无关——后者只影响注释和元数据。
- 要导出正确 UTF-8 数据，必须先把 Language 设为
Chinese simplified (zh-utf-8)（注意后缀是-utf-8，不是-gb2312） - 设成 English 默认触发
SET NAMES latin1，哪怕你数据库全是utf8mb4，也会把中文当成拉丁字母解，导出一堆ä¸Âæ‘‹ - 导出后立刻用
head -n 3 your_export.sql查第一行，确认是不是SET NAMES utf8mb4;；不是就白调了 - 若没看到
zh-utf-8选项，说明语言包被裁剪，需修改libraries/database_interface.lib.php第 168 行附近过滤逻辑
导出 CSV 时中文仍乱码？重点检查 BOM 和 WPS 打开方式
CSV 导出乱码常被误判为 phpMyAdmin 问题，实则是 WPS 双击打开时自动按 GBK 解析 UTF-8 文件（且忽略 BOM），属于工具链兼容性问题。
- 别双击打开 CSV：WPS 默认跳过编码选择，强制用系统编码（Windows-936/GBK）解析，
EF BB BF（UTF-8 BOM）被当普通字符吞掉，首列偏移 - 正确做法：WPS 表格 → 「数据」→ 「从文本/CSV」→ 手动选「文件原始格式」为
UTF-8（不是“自动检测”或“ANSI”） - 更稳方案：导出时在 phpMyAdmin 选「文字字符集」为
gb2312（不是 UTF-8，也不是 GBK），WPS 双击即可正常识别 - 注意：
gb2312不支持 emoji 和生僻字，若数据含这些，必须坚持 UTF-8 + 手动导入流程
fgetcsv() 读导出 CSV 也乱码？PHP 层要主动对齐编码
如果你用 PHP 脚本读取 phpMyAdmin 导出的 CSV 再入库，乱码会延续到应用层——fopen() 默认按系统 locale（Windows 下常是 GBK）解码，根本没考虑文件真实编码。
- 不要直接
fopen($file, 'r')：它不带编码参数，底层行为不可控 - 先确认文件真实编码：
file -i your.csv或 VS Code 右下角状态栏 - 读取前做转换：
$content = file_get_contents($file); $utf8 = mb_convert_encoding($content, 'UTF-8', 'GB2312');，再用str_getcsv()或写入临时 UTF-8 文件 - 若导出含 BOM，
fgetcsv()可能误把\xEF\xBB\xBF当字段开头，建议fseek($fp, 3)跳过
