Navicat中文乱码根源在于连接层、编辑器层与表结构的字符集配置不一致，而非快捷键操作；必须同步设置连接属性（启用UTF8MB4）、查询窗口字符集（设为UTF8）及表/列CHARACTER SET（确认为utf8mb4）。
Navicat 编辑器中文乱码的根源不是快捷键
乱码根本不是靠按某个快捷键就能“触发解决”的——ctrl+s、f5 或 ctrl+r 都不会自动修正编码问题。真正起作用的是连接层和编辑器层的字符集配置，快捷键只是操作载体，不是修复开关。
常见错误现象：SELECT 查询结果里中文显示为问号（???）或方块；在编辑器里直接输入中文，保存后变乱码；从 Excel 粘贴中文进 Navicat 表格，再查出来就错。
- 本质是客户端（Navicat）、服务端（MySQL/MariaDB）、表/列的
CHARACTER SET和COLLATION不一致 - Navicat 默认用系统 locale 初始化连接，Windows 中文版通常走
gbk，但 MySQL 8.0+ 默认是utf8mb4，一来一回就丢字节 - 快捷键如
Ctrl+Enter（执行当前 SQL）或F6（切换查询窗口）本身不改变编码，但误以为“多按几次就能好”是典型误区
必须改的三个地方：连接属性、查询窗口编码、表结构
这三个位置漏掉任意一个，光调快捷键毫无意义。
- 新建连接时，在「连接属性 → 高级」里勾选
Use UTF8 for connection（MySQL）；如果是 PostgreSQL，要确认client_encoding设为utf8 - 已存在的连接：右键连接 →「编辑连接」→「高级」→ 强制指定
charset=utf8mb4（MySQL）或填入options=-c client_encoding=utf8（PostgreSQL） - 打开查询窗口后，不要直接写 SQL —— 先点顶部菜单「查询 → 字符集 → UTF8」，否则粘贴/输入的中文会按当前窗口默认编码（可能是
GBK）发送，服务端收不到正确字节 - 检查目标表：运行
SHOW CREATE TABLE `your_table`;，确认CHARACTER SET是utf8mb4，不是latin1或空着（空着会继承库级设置）
哪些快捷键真有用？别乱按，记这 3 个
不是所有快捷键都跟编码有关，只记真正影响文本流转的几个：
-
Ctrl+Shift+U：在查询编辑器中把选中文本转成 Unicode 十六进制（比如把“测试”变成\u6D4B\u8BD5），适合调试是否真的传了 UTF-8 字节 —— 但这是诊断手段，不是修复动作 -
Ctrl+K：打开「格式化 SQL」面板，其中「字符集」下拉必须选UTF-8（不是System或GBK），否则格式化过程可能二次损坏中文 -
F9：执行当前语句前，Navicat 会校验连接编码是否匹配；如果弹出警告「Character set mismatch」，说明连接属性没设对，这时候按F9不会执行，而是卡住 —— 这是唯一一个能“暴露问题”的快捷键
Windows 下特别容易踩的坑：系统区域设置 + Navicat 版本混用
Navicat 15 及更早版本在 Windows 上默认读取系统「区域设置 → 管理 → 更改系统区域设置」里的选项。如果你开了「Beta 版：使用 Unicode UTF-8 提供全球语言支持」，反而会让老版本 Navicat 解析失败，出现中文全乱。
- 验证方法：打开命令行，执行
chcp，若返回Active code page: 65001（即 UTF-8），而 Navicat 是 12.x 或更旧版本，大概率出问题 - 临时绕过：右键 Navicat 快捷方式 →「属性 → 兼容性 → 更改高 DPI 设置 → 勾选“替代高 DPI 缩放行为”并选“系统(增强)”」，有时能缓解
- 终极解法：升级到 Navicat 16+（明确支持 UTF-8 系统代码页），或关掉系统级 UTF-8 Beta 选项（需重启）
乱码问题从来不是按错键，而是配置断层。连上就乱，说明连接属性没锁死；输进去就坏，说明查询窗口字符集没切；查出来是问号，八成是表本身存的就是 latin1。键盘敲得再快，也补不上这三处空档。
