navicat导出报“unknown character set: 'utf8mb4'”说明调用的mysqldump版本过旧（如≤5.1），需升级系统mysqldump至5.5.3+或在navicat中手动指定新版路径；导出含emoji数据乱码则因连接字符集未设为utf8mb4，应执行set names utf8mb4或勾选“使用自定义字符集”。
Navicat 导出时直接报错“Unknown character set: 'utf8mb4'”
这说明你本地 Navicat 调用的 mysqldump 是旧版 MySQL 客户端（比如 5.1 或更早），它根本不认识 utf8mb4。Navicat 在导出时会自动调用系统 PATH 下的 mysqldump，而不是它自带的版本。
验证方式：终端里执行 mysqldump --version，如果显示低于 5.5.3，就是根源。
解决办法只有两个：
- 升级系统全局的 MySQL 客户端到 5.5.3+（推荐）；
- 在 Navicat 导出设置里手动指定完整路径，指向新版
mysqldump（例如/usr/local/mysql/bin/mysqldump或 Windows 下的C:\Program Files\MySQL\MySQL Server 8.0\bin\mysqldump.exe）。
导出 SQL 文件里 Emoji 变成问号或乱码
不是数据坏了，是 Navicat 在读取结果集时用了错误的连接字符集。即使数据库、表、字段全是 utf8mb4，只要连接初始化没设对，查询出来的二进制流就会被错误解码。
关键变量有三个：character_set_client、character_set_connection、character_set_results。只要其中任意一个是 utf8 或 latin1，Emoji 就会变成 ?。
临时修复（每次连接都要做）：
- 在 Navicat 查询窗口执行
SET NAMES utf8mb4;，再点「导出」； - 或者右键连接 → 「编辑连接」→ 「高级」→ 勾选「使用自定义字符集」→ 选
utf8mb4。
注意：这个设置只影响当前连接，不改变 Navicat 启动时默认行为。
用命令行 mysqldump 替代 Navicat 导出更可靠
Navicat 的图形化导出逻辑复杂，容易在编码协商环节出错；而原生命令行工具可控性高、行为确定。
导出带 Emoji 的库，必须显式加参数：
mysqldump -uroot -p --default-character-set=utf8mb4 mydb > backup.sql- 别漏掉
--default-character-set=utf8mb4—— 没它，mysqldump默认用utf8（即utf8mb3）连接，Emoji 会被截断； - Windows 下避免用 cmd，改用 Git Bash 或 PowerShell，否则 cmd 的 GBK 代码页会在读取/写入文件时二次污染字节流。
备份文件本身含乱码，但 Navicat 显示正常？
这种情况很常见：你用 Navicat 导出的 .sql 文件用记事本打开全是问号，但用 VS Code 或 Sublime 打开却正常。这不是备份失败，是编辑器默认编码不对。
根本原因是：Navicat 导出的文件实际是 UTF-8 编码，但 Windows 记事本看到 BOM 缺失就强行当 ANSI（GBK）打开，导致显示异常。
验证方法：用 file -i backup.sql（Linux/macOS）或用 VS Code 查看右下角编码标识；
真正要关心的，是导入后数据能否正确读出 —— 只要导入时也用 utf8mb4 连接，哪怕导出文件看着是乱码，数据也不会丢。
最易被忽略的一点：计划任务（crontab）里自动执行 mysqldump，环境变量缺失（LANG=C）会导致即使加了 --default-character-set=utf8mb4 也无效。必须显式设置 export LANG=en_US.UTF-8 再运行。
