应手动指定编码而非依赖自动检测：右键SQL文件标签选“重新以编码打开…”，据真实编码选UTF-8或GBK；永久设默认编码为UTF-8，并在连接高级设置中配置SET NAMES utf8mb4。
打开本地.sql文件时中文变问号，怎么选对编码
navicat 不会自动识别文件真实编码，windows 下常把 utf-8（无 bom）误判为 gbk，一打开就乱码。关键不是猜，而是确认后手动指定。
- 右键已打开的 SQL 文件标签 →「重新以编码打开…」→ 选
UTF-8或GBK（取决于文件真实编码） - 永久生效：菜单栏「工具」→「选项」→「常规」→「默认编码」设为
UTF-8，并勾选「新建查询时使用默认编码」 - 不确定文件编码？用 VS Code 打开 → 右下角看当前编码（如显示
UTF-8或UTF-8 with BOM），别凭感觉选 - 记事本另存为时默认带 BOM，VS Code/Sublime 默认无 BOM —— 导入前必须匹配，否则 Navicat 仍可能读错
运行SQL文件时中文插入失败，初始化命令写不对
即使文件是 UTF-8，Navicat 运行脚本时仍按连接层声明的字符集解析语句。如果没显式设 SET NAMES utf8mb4，MySQL 会默认用 latin1 解析中文字符串，报 Incorrect string value。
- 右键连接 →「运行 SQL 文件」→ 选中文件 → 弹窗右上角点「编码」按钮 → 明确选
UTF-8（不是「自动检测」） - 编辑连接 →「高级」→「初始化命令」填入：
SET NAMES utf8mb4;（注意是utf8mb4，不是utf8） - 脚本第一行也建议加
SET NAMES utf8mb4;，避免依赖连接配置 - 禁用「SQL 预处理」（工具 → 选项 →「SQL 编辑器」→ 取消勾选「启用 SQL 预处理」），防止 Navicat 自作主张转义中文
导出的.sql文件在其他工具里打开又乱码
导出对话框里选了「UTF-8」只控制文件保存编码，不保证 SQL 内容本身用的是 utf8mb4。如果连接层还是 latin1，导出的建表语句里会写 DEFAULT CHARSET=utf8 甚至 latin1，还原时照样丢 emoji。
- 导出前先确认连接已生效：连上后执行
SHOW VARIABLES LIKE 'character_set_client';，返回值必须是utf8mb4 - 编辑连接 →「高级」→ 勾选「使用自定义字符集」→ 手动输入
utf8mb4（别信下拉菜单，旧版常不显示） - 导出向导最后一步 → 勾选「导出为 UTF-8 编码」，且不要勾选「包含 CREATE DATABASE 语句」，除非你确认语句里写了
CHARACTER SET = utf8mb4 - 导出后用
file -i filename.sql（macOS/Linux）或记事本另存为验证实际编码，别只看 Navicat 对话框选项
Mac/Linux 上 Navicat 查询结果仍显示方块
字符集全对了，但字体不支持 CJK 字形，渲染层直接 fallback 到缺失字形，显示为空格或方块。这不是编码问题，是字体链断了。
- macOS：偏好设置 →「字体」→ 改为
Noto Sans CJK SC或Apple Color Emoji（别用Helvetica） - Linux：确保系统已安装
fonts-noto-cjk或fonts-wqy-microhei，然后 Navicat 字体设为Noto Sans CJK SC - 改完字体必须完全退出 Navicat（不只是关窗口），再重开才生效
- Linux 用户额外检查：
locale | grep -E "LANG|LC_CTYPE"，输出应含zh_CN.UTF-8或en_US.UTF-8，否则界面控件本身就会乱码
文件编码、连接声明编码、服务端存储编码这三者得同时对齐，少一个环节，中文就卡在某个中间态变成问号——而最常被跳过的，是确认 SHOW VARIABLES LIKE 'character_set_client' 真的返回 utf8mb4，不是靠“测试连接成功”就以为万事大吉。
