navicat中文乱码根源在于文件编码与加载编码不一致，需用vs code确认真实编码后“重新以编码打开”，再“另存为utf-8 with bom”；oracle依赖系统级nls_lang环境变量，mysql需在连接高级设置中填入“set names utf8mb4”。
navicat sql编辑器里输入中文变问号或方块
根本不是字体或系统语言问题，而是 navicat 加载文件时用的编码 ≠ 你保存文件时用的编码。新建查询窗口打中文正常，但打开 .sql 文件后乱码——说明编辑器本身能渲染中文，只是“读错了字节”。
右键“重新以编码打开…”选错就全毁
Windows 中文版下，Navicat 默认用 GBK 猜 UTF-8 无 BOM 文件，一打开就是 ??。这不是 bug，是它没看到 BOM 就不敢信你是 UTF-8。
- 先用 VS Code 或 Notepad++ 查真实编码（看右下角状态栏），别凭感觉选
- 右键已打开的 SQL 标签 → “重新以编码打开…” → 选对应编码（如
GBK或UTF-8） - 确认显示正常后，立刻点右下角编码 → “另存为编码” → 存成
UTF-8 with BOM（Windows 下最稳） - 永久设置：菜单栏「工具」→「选项」→「常规」→「默认编码」设为
UTF-8，并勾选「新建查询时使用默认编码」
连接属性里的“字符集”下拉框对 Oracle 是摆设
这个选项只影响 SQL 编辑器文本渲染，和 Oracle 客户端通信完全无关。你在这儿选 UTF-8，但系统没设 NLS_LANG，执行 SELECT '测试' FROM DUAL 返回的仍是 ??。
- Oracle 必须靠系统环境变量
NLS_LANG驱动，格式如AMERICAN_AMERICA.AL32UTF8 - Windows 下必须设系统级环境变量（不是仅 Navicat 快捷方式里设），重启 Navicat 生效
- 查库实际字符集：
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';，NLS_LANG值要跟它严格匹配
MySQL 连接“初始化命令”不填就等于没设字符集
即使编辑器里中文显示正常，执行 INSERT 含中文的语句仍报 Incorrect string value，大概率是连接建立后没发 SET NAMES utf8mb4，服务端还在用 latin1 解析字节流。
- 编辑连接 →「高级」→「初始化命令」栏填：
SET NAMES utf8mb4; - 别写
SET NAMES utf8：MySQL 的utf8是utf8mb3，不支持 emoji 和部分汉字 - 验证是否生效：连接后立即执行
SELECT @@character_set_client, @@collation_connection;，两个值都应含utf8mb4 - 如果脚本里已有
SET NAMES latin1这类语句，删掉——它会覆盖初始化命令
真正卡住人的从来不是某一个设置，而是文件编码、连接声明、服务端存储这三层里有一层没对齐。尤其容易忽略的是：Oracle 的 NLS_LANG 是系统级的，MySQL 的 SET NAMES 必须显式写进初始化命令，而 Navicat 的“自动检测编码”在 Windows 下基本不可信。
