Navicat连Oracle中文乱码根本原因是NLS_LANG与数据库字符集不匹配；需查数据库字符集、正确设置系统级NLS_LANG环境变量，Navicat连接属性中的字符集选项仅影响SQL编辑器，与通信层无关。
Navicat 连 Oracle 时中文显示为问号或方块
根本原因是客户端字符集（nls_lang）与数据库实际字符集不匹配，navicat 自身不主动读取或设置 nls_lang，全靠系统环境变量或连接配置兜底。oracle 服务端字符集（如 al32utf8 或 zhs16gbk）和客户端理解方式对不上，就直接丢弃或替换成 。
- 先查清数据库实际字符集：
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'; - Windows 下必须设置系统级环境变量
NLS_LANG，格式为AMERICAN_AMERICA.<code>字符集名（如AMERICAN_AMERICA.AL32UTF8），不能只设在 Navicat 启动快捷方式里 - 若数据库是
ZHS16GBK，但 Windows 系统区域设为「中文（简体，中国）」且未改环境变量，Navicat 默认用系统 ANSI 代码页（通常是 GBK）去解码 UTF8 数据，必然乱码
Navicat 连接属性里「字符集」选项到底起不起作用
这个下拉框只影响 Navicat 内部 SQL 编辑器的文本编码识别，和 Oracle 客户端通信层完全无关。它既不设置 NLS_LANG，也不修改 OCI 连接参数，选错顶多导致你写的 SQL 里中文注释显示异常，不影响查询结果中的中文字段值。
- 编辑器里写
SELECT '测试' FROM DUAL;显示乱码？检查该连接的「字符集」是否和你保存 SQL 文件的实际编码一致（推荐统一用 UTF-8） - 执行后返回的字段值仍是乱码？说明问题出在 NLS 层，跟这个下拉框无关
- 该选项对 Oracle 连接属于「装饰性配置」，调不通乱码时别在这儿浪费时间
OCI 驱动版本与字符集兼容性问题
旧版 Oracle Instant Client（如 11g/12c 的 32 位客户端）在 Windows 上对 UTF-8 支持不完整，尤其遇到四字节 emoji 或某些生僻汉字时会截断或报错，表现就是部分中文能显示、部分变空或问号。
- 优先使用 Oracle 官方最新版 Instant Client（21c 或 19c），并确保 Navicat 配置中指向的是
oci.dll所在目录（不是bin子目录） - 如果必须用老客户端，且数据库字符集是
AL32UTF8，则NLS_LANG必须设为AMERICAN_AMERICA.AL32UTF8；设成ZHS16GBK会导致 OCI 内部转换失败 - 64 位 Navicat 必须配 64 位
oci.dll，混用会导致连接直接失败，错误信息可能是ORA-12154: TNS:could not resolve the connect identifier specified或静默无响应
Linux/macOS 下 Navicat for Mac 的字符集陷阱
macOS 终端默认 UTF-8，但 Navicat for Mac 的 OCI 加载逻辑会绕过 shell 环境变量，只认启动时继承的 NLS_LANG。如果你从 Dock 启动，它根本看不到你在终端 export 的变量。
- 必须用命令行启动：先
export NLS_LANG=AMERICAN_AMERICA.AL32UTF8，再运行open -a "Navicat Premium" - Linux 用户要注意 glibc 版本 —— 较老的 CentOS 7 默认 glibc 不完全支持 Unicode 标准区段，即使
NLS_LANG正确，某些扩展汉字仍会显示为 □ - 不要试图用
iconv转换 Navicat 安装包或配置文件，OCI 层的字符处理发生在二进制驱动内部，外部转码无效
最常被忽略的一点：改完 NLS_LANG 或客户端后，必须彻底退出 Navicat（包括后台进程），再重新打开连接 —— 它不会热加载环境变量，也不会重读 OCI 配置。
