Navicat中文乱码的根本原因是文件编码、连接声明编码与服务端存储编码不一致；需统一设为utf8mb4，手动指定SQL文件编码，连接初始化命令设SET NAMES utf8mb4，并导出时勾选UTF-8编码。

Navicat 编辑器中文乱码的根本原因 Navicat 本身不直接决定 SQL 编辑器里文字是否乱码，真正起作用的是它加载文件时所用的**字符编码检测逻辑**和**当前连接的数据库字符集配置**。常见现象是：新建查询窗口打中文正常，但打开本地 .sql 文件后全是问号或方块——这说明 Navicat 没猜对文件编码；而执行 INSERT 中文时报 Incorrect string value，那基本是服务端表/列的 CHARACTER SET 和 COLLATION 不支持 utf8mb4。

关键判断点就两个：文件保存时用的编码 和 Navicat 连接时声明的编码 必须一致，且服务端要能承接。

手动指定 SQL 文件编码（最常踩坑环节） Navicat 默认用系统 locale 猜测文件编码，Windows 中文版常误判 UTF-8 无 BOM 文件为 GBK，一打开就乱码。

• 右键已打开的 SQL 文件标签 → “重新以编码打开…” → 选 UTF-8 或 GBK（看原始文件真实编码）
• 永久生效：菜单栏 文件 → 工具 → 选项 → 常规 → 默认编码，改成 UTF-8（推荐）
• 新建文件默认编码不会自动同步该设置，需额外勾选 “新建查询时使用默认编码”
• 如果文件是别人发来的，先用 VS Code 或 Notepad++ 查看真实编码，别凭感觉选

连接层编码必须显式设为 utf8mb4 即使编辑器里中文显示正常，执行时仍可能报错。这是因为 Navicat 在建立 MySQL 连接时，默认发送的 SET NAMES latin1（旧版行为），导致服务端按 latin1 解析后续语句。

• 编辑连接 → 高级 → “初始化命令” 栏填入：SET NAMES utf8mb4;
• 确保目标数据库、表、字段的 CHARACTER SET 是 utf8mb4，不是 utf8（MySQL 的 utf8 实为 utf8mb3，不支持 emoji 和部分生僻汉字）
• 连接测试成功后，执行 SELECT @@character_set_client, @@collation_connection; 确认返回值含 utf8mb4

导出 SQL 文件时的编码陷阱 用 Navicat 导出数据为 .sql 文件时，若未指定编码，生成的文件很可能带 BOM 或用系统默认编码，下次再导入/编辑就又乱。

• 导出向导最后一步 → 勾选 “导出为 UTF-8 编码”（不是“Unicode”，也不是留空）
• 避免勾选 添加 CREATE DATABASE 语句，除非你确认建库语句里明确写了 CHARACTER SET = utf8mb4
• 导出的文件若在其他工具里打开仍乱码，用 file -i filename.sql（Linux/macOS）或 chcp + 记事本另存为验证实际编码

Navicat 不会自动帮你对齐所有编码环节，尤其是「文件编码」「连接声明编码」「服务端存储编码」这三层，漏掉任何一层都可能让中文在某个环节突然变问号。最稳妥的做法是：统一用 utf8mb4，所有地方显式指定，不依赖自动探测。