Navicat中文显示异常分三类：字体不支持、文件编码误判、系统locale缺失；需分别配置等宽中文字体、手动指定UTF-8编码打开文件、启用zh_CN.UTF-8 locale。
SQL编辑器里中文显示为方块或空格
这不是编码问题，是字体不支持中文字形。navicat 默认字体（如 consolas、courier new）在 windows 上对中文 fallback 失败，直接渲染为空白或方块。
- Windows：进入「工具」→「选项」→「编辑器」→「编辑器字体」，选
Noto Sans CJK SC Regular或Microsoft YaHei（避免用 SimSun，它在等宽场景下易断行错位） - macOS：推荐
Monaco+ 启用“使用系统字体渲染”，或手动指定STHeiti - Linux：必须安装
fonts-noto-cjk包，然后在选项里设为Noto Sans Mono CJK SC - 改完必须完全退出 Navicat（不只是关窗口），否则新字体不加载
新建查询窗口字体正常，但打开本地 .sql 文件就乱码
这是文件编码被误判导致的视觉异常，不是字体本身问题。编辑器试图用错误编码解析字节流，结果把 UTF-8 字节当 GBK 解，显示成一堆方块——此时换字体没用，得先纠正编码识别。
- 右键已打开的 SQL 标签页 →「重新以编码打开…」→ 试
UTF-8和GBK，哪个能正常显示中文就选哪个 - 确认后，右下角编码标识旁点「Save with Encoding」→ 保存为
UTF-8（无 BOM） - 永久预防：「工具」→「选项」→「常规」→「默认编码」设为
UTF-8，并勾选「新建查询时使用默认编码」 - 别依赖「自动检测」：Navicat 对 UTF-8 无 BOM 文件的识别准确率低于 60%，尤其在 Windows 中文环境下
Oracle 连接下编辑器中文注释乱码，但查询结果正常
Oracle 场景下，字符集 下拉框只影响 SQL 编辑器文本渲染，和数据库通信无关。它不控制 NLS_LANG，也不修改 OCI 参数，纯属前端显示层配置。
- 若写
-- 插入用户数据显示为方块，说明当前连接的「字符集」设置与你保存该 SQL 文件的实际编码不一致 - 统一用
UTF-8：编辑器字体设为支持中文的等宽字体，文件保存为 UTF-8，连接属性里「字符集」也选UTF-8 - 注意：这个选项对 Oracle 查询结果、INSERT/SELECT 中文字段值完全无影响，乱码只出现在你写的 SQL 文本里
- 如果连
SELECT '测试' FROM DUAL都显示乱码，优先检查文件编码，而非怀疑 Oracle 服务端
Linux 下启动即全界面方块，连菜单都不可读
根本不是 Navicat 本身的问题，是系统 locale 缺失或未生效。Navicat Linux 版依赖系统级 locale 渲染 UI 和编辑器，zh_CN.UTF-8 没启用时，所有中文控件都会崩。
- 终端执行
locale -a | grep zh_CN.utf8，若无输出，需生成 locale：sudo locale-gen zh_CN.UTF-8 - 编辑
/etc/default/locale，确保含LANG="zh_CN.UTF-8" - 重启桌面环境（或直接
export LANG=zh_CN.UTF-8后再启动 Navicat 测试） - 别改
start_navicat脚本里的export LANG=—— 它只影响启动进程，不传递给 Qt GUI 子线程，无效
字体设置只是表象，真正卡住的往往是系统 locale、文件编码识别逻辑、以及 Oracle 场景下对「字符集」选项作用范围的误判。改字体前，先确认你面对的是渲染问题，还是编码错位问题。
