说实话，遇到Navicat还原后中文字符全部变成问号的情况，大多数用户的第一反应往往是备份文件损坏了。但真相其实很简单——问题不在文件本身，而是Navicat在还原过程中跳过了字符集协商环节，直接将utf8mb4的字节按照latin1或gbk编码“硬解”写入。换句话说，它根本没有询问数据库“你使用的是哪种编码”，就自作主张地执行了写入操作。

还原前必须执行 SET NAMES utf8mb4

Navicat的「还原」功能（无论是.sql文件还是备份集）不会自动执行连接初始化命令。它直接读取文件中的字节流，原封不动地发送给服务端。此时如果当前连接的character_set_client是latin1，即使数据库和表全部设置为utf8mb4，也会被错误解析为乱码。如何避免？

• 打开Navicat，连接目标数据库，在还原操作之前，先在任意查询窗口中执行：SET NAMES utf8mb4;
• 然后点击「工具 → 数据传输」或「文件 → 还原」，确保刚才的查询窗口保持激活状态——还原操作必须发生在同一连接上下文中，否则设置等于无效
• 如果还原的是SQL文件，还需要手动确认文件编码。右键文件 →「编辑」→ 查看左下角状态栏是否显示UTF-8；如果显示ANSI或GBK，使用记事本另存为UTF-8（带BOM更稳妥）

检查并修正三级字符集：库、表、字段

还原只是写入动作，真正决定能否正确显示中文的关键在于目标库、表、字段是否真正使用了utf8mb4。仅修改其中一层无效，必须逐级验证。

• 查看库级默认字符集：SHOW VARIABLES LIKE 'character_set_database'; —— 如果不是utf8mb4，新建的表会继承错误编码
• 查看表字符集：SHOW CREATE TABLE `your_table`; —— 重点关注末尾是否有DEFAULT CHARSET=utf8mb4
• 查看字段实际字符集：SHOW FULL COLUMNS FROM `your_table`; —— 每个字段的Collation列必须为utf8mb4_unicode_ci类型，不能是latin1_swedish_ci
• 修复字段时需注意：TEXT、MEDIUMTEXT等类型不会被CONVERT TO覆盖，需要单独执行MODIFY。例如：ALTER TABLE `t` MODIFY `content` TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

连接设置中必须勾选「使用 MySQL 字符集」并设为 utf8mb4

即使你执行了SET NAMES utf8mb4，如果Navicat连接本身的字符集配置没有对齐，后续新建查询或自动重连时仍会回落到错误值。这一步很容易被忽略。

• 右键连接 →「编辑连接」→「高级」选项卡
• 务必勾选「使用 MySQL 字符集」，并在下方下拉框中选择utf8mb4（不是utf8）
• 点击「测试连接」成功后，一定要点击「确定」保存——只点「测试」不保存，设置等于没有修改
• 保存后重新连接，再执行：SHOW VARIABLES LIKE 'character_set%'; 确认character_set_client、character_set_connection、character_set_results全部为utf8mb4

最容易忽视的一点是：还原操作本身不会触发任何字符集自动适配，它完全信任当前连接的客户端编码。即使你数据库、表、字段全部设置正确，只要还原时连接使用的是latin1，写入的就是错误的字节，后续查询都会显示为问号。因此，还原前的连接字符集准备，才是真正一步到位的关键所在。