Navicat连Oracle中文乱码主因是NLS_LANG与数据库字符集不匹配；需先查数据库字符集（SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'），再严格按LANGUAGE_TERRITORY.CHARACTERSET格式设置系统级NLS_LANG环境变量，OCI驱动位数与Navicat必须一致，连接属性中的字符集选项仅影响SQL编辑器编码，不参与通信解码。
navicat 连 oracle 出现中文乱码，90% 以上的情况不是 navicat 本身的问题，而是 nls_lang 环境变量没设对，或者跟数据库字符集不匹配。改连接属性里的「字符集」下拉框基本没用，别在这儿反复试。
怎么查清 Oracle 数据库实际用的字符集
连上数据库后，直接执行这条 SQL：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';
返回值常见有：AL32UTF8（UTF-8）、ZHS16GBK（GBK）、WE8ISO8859P1（Latin-1）等。注意：这不是你本地系统区域设置，也不是 Navicat 里选的那个下拉项，是数据库服务端真实存储和传输的编码。
补充查法（兼容性更强）：
SELECT userenv('language') FROM DUAL;
它返回类似 AMERICAN_AMERICA.AL32UTF8 的完整字符串，其中最后部分就是你要对齐的字符集名。
Windows 下必须设系统级 NLS_LANG 环境变量
Navicat 启动时读取的是操作系统环境变量，不是快捷方式里的“起始位置”或“运行参数”。只在 Navicat 快捷方式里加 set NLS_LANG=... 是无效的。
- 右键“此电脑”→属性→高级系统设置→环境变量
- 在“系统变量”或“用户变量”里新建变量：
变量名：NLS_LANG
变量值：AMERICAN_AMERICA.（例如：AMERICAN_AMERICA.AL32UTF8或SIMPLIFIED CHINESE_CHINA.ZHS16GBK） - 重启 Navicat（不是重连，是彻底关闭再打开）
关键点：NLS_LANG 格式必须是 语言_地区.字符集，中间用点分隔；字符集名必须跟 NLS_DATABASE_PARAMETERS 查出来的完全一致（大小写敏感）；不能只写 ZHS16GBK，必须带前面的语言和地区前缀。
OCI 驱动版本和位数必须严格匹配
乱码还常伴随连接失败或静默无响应，大概率是 OCI 层出了问题。
- 64 位 Navicat 必须配 64 位
oci.dll；32 位 Navicat 必须配 32 位oci.dll——混用直接报ORA-12154或根本连不上 - 旧版 Instant Client（如 11g/12c）对
AL32UTF8支持不完整，遇到四字节字符（比如 emoji、某些生僻汉字）会截断或变问号 - Navicat → 工具 → 选项 → 其他 → OCI：路径必须指向
oci.dll所在目录（通常是解压后的根目录，不是bin/子目录）
推荐用 Oracle 官方最新版 Instant Client（21c 或 19c），下载地址：https://www.oracle.com/database/technologies/tech/oci/instant-client/downloads/
Navicat 连接属性里的「字符集」选项到底管什么
这个下拉框只影响两件事：
- SQL 编辑器打开本地
.sql文件时，默认用哪种编码去读——比如你保存的是 UTF-8 无 BOM 文件，但这里选了GBK，打开就全是问号 - 你在编辑器里手写的中文注释、字符串字面量（如
SELECT '测试' FROM DUAL）能否正确显示
它**完全不影响**查询结果中字段值的解码。也就是说：编辑器里中文看着正常，但执行后返回的中文列仍是乱码？说明问题出在 NLS_LANG 或 OCI 层，跟这个下拉框无关。别花时间反复切换它。
真正容易被忽略的是：NLS_LANG 设置后必须重启 Navicat 才生效；OCI 路径指向错误时不会报错提示，只会静默降级或失败；数据库字符集是 AL32UTF8 却设成 ZHS16GBK，OCI 内部转换会直接丢数据，不是乱码，而是空值或问号——这种问题查日志都难定位。
