Navicat 15 连接 MySQL/MariaDB 必须在「高级」页「MySQL 字符集」下拉框中严格选择 utf8mb4（非 utf8、非 UTF-8），并勾选「使用初始化命令」填入 SET NAMES utf8mb4;，且重新连接生效；否则 emoji 和四字节汉字会报错或显示乱码。
Navicat 15 连接设置里该填 utf8mb4，不是 UTF-8 或 utf8
MySQL/MariaDB 的字符集下拉框里选 utf8mb4 是硬性要求，不是风格偏好。Navicat 15 的「高级」页中「MySQL 字符集」选项若选 utf8（即 MySQL 的旧版 utf8mb3），插入 emoji 或「?」「?」这类四字节汉字会直接报 Incorrect string value；若选 UTF-8（首字母大写、带连字符等变体），Navicat 可能无法识别，fallback 到 latin1，导致表名、字段注释显示为 æ 这类乱码。必须手动点开下拉框，严格选择 utf8mb4 —— 注意拼写、大小写、无空格、无连字符。
导出/导入向导中「编码」选项不能依赖 Auto，必须显式选 UTF-8 或 GBK
Navicat 15 的 CSV/SQL/JSON 导入导出向导最后一步都有「编码」下拉框，Auto 模式在中文 Windows 下大概率误判 UTF-8 无 BOM 文件为 GBK，一导入就劈字段或变问号。实际操作要按文件真实编码选：
- 用
file -i your_file.csv（Linux/macOS）或xxd your_file.csv | head -1看开头三字节：是ef bb bf→ 选UTF-8 with BOM；否则 → 先试UTF-8，乱码再试GBK（Windows 记事本右下角标“ANSI”≈GBK） - 导出 SQL 文件给他人执行时，统一选
UTF-8（无 BOM），避免 Excel 自动加解码干扰；但若对方明确要用 Excel 双击打开，才选UTF-8 with BOM - 导入 JSON 时，即使文件是 GBK 编码，也不要指望 Navicat 自动转码 —— 先用 Notepad++ 转存为 UTF-8，再导入
连接初始化命令必须填 SET NAMES utf8mb4;，且重新连接才生效
只改字符集下拉框不生效是 Navicat 15 最常见的假成功场景。MySQL 协议建立连接后默认发的是 SET NAMES latin1，覆盖你界面上的设置。必须勾选「使用初始化命令」，并填入：
SET NAMES utf8mb4;
这条命令同步设置 character_set_client、character_set_connection、character_set_results 三个变量。填完务必右键连接 →「断开连接」→「连接」，否则 SHOW VARIABLES LIKE 'character_set_client'; 仍返回 latin1。PostgreSQL 用户则需在连接字符串末尾加 options=-c%20client_encoding%3DUTF8（URL 编码不能错）。
编辑器打开本地 .sql 文件乱码，是因为没指定真实文件编码
新建查询窗口打中文正常，但打开本地 xxx.sql 后全是方块，说明 Navicat 默认用系统 locale（Windows 中文版 ≈ GBK）去读一个实际是 UTF-8 编码的文件。解决方法分两步：
- 临时修复：右键已打开的 SQL 标签 →「重新以编码打开…」→ 选
UTF-8或GBK（取决于文件真实编码） - 永久生效：菜单栏「工具」→「选项」→「常规」→「默认编码」设为
UTF-8，并勾选「新建查询时使用默认编码」 - 关键提醒：这个设置只影响「新建」和「重新打开」，不影响已打开的标签页；若别人发来的文件，先用 VS Code 确认真实编码，别凭感觉选
真正容易被忽略的点是：Navicat 15 不会自动对齐「文件编码」「连接声明编码」「服务端存储编码」这三者。哪怕你把所有界面都设成 UTF-8，只要建表语句里漏了 DEFAULT CHARSET=utf8mb4，或者数据库本身是 latin1，后续插入中文照样崩。得一层层查实，不能只调客户端。
