Navicat编辑器中文乱码突然出现，主因是编辑器缓存/渲染异常而非连接编码配置错误；应优先尝试Ctrl+R重载视图、关闭硬件加速、调回Windows缩放至100%、清理%AppData%\PremiumSoft\Navicat\Cache和FontCache文件夹，并确保连接层与编辑器层字符集一致。
Navicat 编辑器中文乱码突然出现，不是编码设置问题
乱码“突然”发生，大概率不是 字符集 或 连接编码 配置错了——那些通常一连就错，不会用着用着才崩。真正常见原因是 navicat 自身编辑器缓存/渲染层状态错乱，尤其是 windows 下启用了硬件加速或高 dpi 缩放时，字体回退逻辑容易卡住。
实操建议：
- 先试快捷键
Ctrl + R强制重载当前编辑器视图（不重启软件），多数临时渲染异常能当场恢复 - 关闭硬件加速：菜单栏
工具 → 选项 → 界面 → 使用硬件加速→ 取消勾选 → 重启 Navicat - 检查 Windows 显示缩放是否为非 100%（如 125%、150%）：右键桌面 →
显示设置 → 缩放与布局，临时调回 100% 测试是否恢复
重置 Navicat 编辑器字体和编码缓存
Navicat 不会把编辑器字体/编码偏好实时写入配置文件，而是缓存在内存+本地临时目录里。一旦缓存损坏（比如异常退出、杀进程），下次启动可能沿用错误的字体映射表，导致中文显示成方块或问号。
实操建议：
- 关闭所有 Navicat 实例，包括系统托盘残留进程（任务管理器里确认
navicat.exe已退出） - 删除以下路径中的缓存文件夹（Windows）：
%AppData%\PremiumSoft\Navicat\下的Cache和FontCache文件夹 - 重新启动 Navicat，首次打开编辑器时它会重建字体缓存；此时若仍乱码，再进
工具 → 选项 → 编辑器 → 字体，手动指定支持中文的字体（如Consolas、Microsoft YaHei、NSimSun）
连接层 vs 编辑器层：两个地方的字符集必须匹配
很多人只改了数据库连接的 字符集（如 utf8mb4），却忘了编辑器本身也有独立的 编码格式 设置。这两者不一致时，即使数据存得对，编辑器读出来也会解码错位。
实操建议：
- 连接属性中确认
字符集是utf8mb4（MySQL）或UTF-8（PostgreSQL），且勾选了使用 MySQL 字符集类似选项 - 编辑器右下角状态栏点击当前编码（如
UTF-8、GBK），强制设为和连接层一致的值；如果点不开，说明编辑器已卡死，需按上一节清缓存 - 特别注意：某些旧版 Navicat（v15 以前）在 SSH 隧道连接时，会忽略连接层字符集，强行走本地终端编码，此时必须在
连接 → SSH → 终端类型中设为xterm-256color并勾选启用终端
为什么清理缓存后还是乱码？检查这三个隐藏点
缓存清了、字体设了、编码也对了，还乱码？问题往往藏在更底层：系统级字体缺失、SQL 模式干扰、或 Navicat 插件冲突。
实操建议：
- 确认 Windows 是否缺少等宽中文字体：打开
C:\Windows\Fonts，搜索simhei.ttf、msyh.ttc、consola.ttf，缺任一都可能导致编辑器 fallback 到不支持中文的字体 - 执行
SELECT @@sql_mode;，如果返回包含NO_BACKSLASH_ESCAPES或STRICT_TRANS_TABLES，某些含反斜杠的中文字符串会被截断或转义，看起来像乱码 - 禁用所有第三方插件（尤其主题类、代码高亮类）：菜单栏
工具 → 插件 → 管理插件，全部停用后重启测试
最麻烦的情况是：乱码只出现在某张表的某个字段，其他都正常。这时候别折腾 Navicat，先查 SHOW CREATE TABLE `xxx`; 和 SHOW FULL COLUMNS FROM `xxx`;，确认该字段的 COLLATION 是 utf8mb4_unicode_ci 而不是 latin1_swedish_ci —— 这种局部不一致，Navicat 编辑器根本救不了。
