Navicat中文显示问号或方块的根本原因是客户端编码识别错误，需将默认字符集设为UTF-8并重启；连接级设UTF-8、执行SET NAMES utf8mb4；导入SQL文件时手动选UTF-8编码；关闭SQL预处理功能。

Navicat编辑器显示中文是问号或方块？先查客户端编码设置

根本原因不是数据库出问题，而是navicat把sql文件或查询结果当成iso-8859-1或gbk读取，而实际存的是utf-8。重点不是改数据库，是让navicat“认对字”。

实操建议：

• 菜单栏 → 工具 → 选项 → 左侧选常规 → 右侧找到默认字符集，改成UTF-8
• 如果用的是旧版Navicat（如12或更早），该选项可能叫默认编码，同样选UTF-8
• 改完必须重启Navicat，否则不生效
• 若只对某个连接生效，右键连接 → 编辑连接 → 高级页签 → 勾选使用自定义字符集 → 设为UTF-8

执行SQL时插入中文变乱码？检查连接层的character_set_client

即使Navicat设对了，发出去的SQL仍可能被MySQL服务端用错编码解析。典型现象：建表语句里写COMMENT '用户昵称'，执行后变成COMMENT 'Óû§Ãû³Æ'。

实操建议：

• 连接成功后，立即执行：

  SET NAMES utf8mb4;

  （不是utf8，注意mb4）
• 更稳妥的做法：在连接的高级设置里，勾选初始化命令，填入SET NAMES utf8mb4;
• 验证是否生效：执行SHOW VARIABLES LIKE 'character\_set%';，确认character_set_client、character_set_connection、character_set_results三项都是utf8mb4

从文件导入SQL脚本出现中文乱码？别直接拖进查询窗口

直接把.sql文件拖进Navicat编辑器，它会按当前默认编码打开——哪怕文件本身是UTF-8无BOM，也常被误判。结果就是注释和字符串全乱。

实操建议：

• 右键连接 → 运行SQL文件 → 选择文件 → 弹窗中务必手动选UTF-8（不是“自动检测”）
• 如果文件是Windows记事本保存的，很可能带BOM，此时选UTF-8 with BOM；VS Code等编辑器默认保存为无BOM UTF-8，就选UTF-8
• 避免用“打开文件”方式加载SQL脚本，那个路径走的是编辑器编码逻辑，和执行逻辑分离

Navicat 16+ 新增的SQL预处理功能导致中文被转义？关掉它

新版Navicat默认开启SQL预处理（在工具 → 选项 → SQL编辑器里），它会对字符串做自动转义，比如把'张三'悄悄变成'\u5f20\u4e09'，再发给服务端——MySQL不认识这种写法，直接报错或存空。

实操建议：

• 进入工具 → 选项 → SQL编辑器 → 找到启用SQL预处理 → 取消勾选
• 这个选项对中文字段名、表名、注释、INSERT值都会生效，且错误不报在界面上，只在执行结果里体现为NULL或截断
• 除非你明确需要Unicode转义（比如写跨平台兼容脚本），否则建议始终关闭

真正卡住人的，往往不是数据库配置，而是Navicat自己在中间多做了几步“好意”的转换——尤其是SQL预处理和自动检测编码这两个开关，关掉比调通更容易见效。