根本原因是客户端NLS_LANG未正确设置，导致字符集协商失败；应先查数据库字符集，再按客户端类型配置NLS_LANG或连接参数，确保与数据库字符集一致。
Oracle客户端连接后中文显示为问号或方块
根本原因是客户端 nls_lang 环境变量未正确设置，导致 oracle 客户端无法告诉服务端“我用的是什么字符集”。服务端按默认（比如 al32utf8）发数据，客户端却用 zhs16gbk 解，或者反过来，必然乱码。
实操建议：
- 先查清数据库实际字符集：
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';—— 常见值是AL32UTF8或ZHS16GBK - 再确认你用的客户端环境（SQL*Plus / PL/SQL Developer / Python cx_Oracle / JDBC）是否受
NLS_LANG控制：命令行工具和 OCI 驱动都认这个变量；JDBC 通过连接串参数控制，不看它 -
NLS_LANG格式必须是LANGUAGE_TERRITORY.CHARACTERSET，比如中文 Windows + UTF8 数据库应设为AMERICAN_AMERICA.AL32UTF8；若数据库是ZHS16GBK，客户端也得配成AMERICAN_AMERICA.ZHS16GBK，不能混用 - Windows 下在系统环境变量里设
NLS_LANG，Linux/macOS 在 shell 启动文件中export NLS_LANG=...，设完重启终端或客户端进程才生效
Python cx_Oracle 连接 Oracle 中文乱码
cx_Oracle（v8+）默认使用 Unicode，但底层仍依赖 OCI，NLS_LANG 设错时会触发隐式字符转换，插入/查询中文出错——尤其在字段为 VARCHAR2 且数据库字符集非 UTF8 时。
实操建议：
- 优先不设
NLS_LANG，让 cx_Oracle 自动协商：它会读取 Python 源文件编码（# -*- coding: utf-8 -*-）并匹配数据库字符集，成功率更高 - 如果必须显式指定，用
cx_Oracle.init_oracle_client()的config_dir或lib_dir参数配合tnsnames.ora，比靠环境变量更可控 - 插入前检查
connection.encoding和connection.nencoding值，它们反映实际协商结果；若与数据库字符集不一致，说明协商失败，需排查tnsnames.ora或监听器配置 - 避免用
str.encode('gbk').decode('utf-8')这类手动转码——cx_Oracle 不吃这套，反而引入二次乱码
PL/SQL Developer 中文显示正常但导出 SQL 文件后乱码
这是工具级字符集切换问题：PL/SQL Developer 显示时用了正确的 NLS_LANG，但“导出到文件”功能默认用系统 ANSI 代码页（Windows 上常为 GBK），而文件本身没带 BOM 或编码声明，编辑器打开时猜错编码。
实操建议：
- 导出时勾选
UTF-8 with BOM（不是纯 UTF-8），VS Code、Notepad++ 都能正识别 - 不要依赖工具自动保存编码，导出后用
file -i xxx.sql（Linux/macOS）或 PowerShell 的Get-Content -Encoding UTF8验证实际编码 - 如果导出内容含
NLS_LANGUAGE相关 DDL（如ALTER SESSION SET NLS_DATE_FORMAT），注意这些语句本身不含字符集信息，乱码只影响可读性，不影响执行
Java JDBC 连接 Oracle 中文乱码（非 Spring Boot 场景）
JDBC 驱动（ojdbc8.jar）完全忽略 NLS_LANG，所有字符集行为由连接串参数和 JVM 启动参数共同决定。常见错误是只改了 -Dfile.encoding=UTF-8 却漏掉 JDBC 参数。
实操建议：
- 连接 URL 必须显式加参数：
?useUnicode=true&characterEncoding=UTF-8（MySQL 风格写法对 Oracle 无效）→ 正确写法是：?oracle.jdbc.defaultNChar=true（启用 Unicode 绑定）+&oracle.jdbc.convertNcharLiterals=true（确保 N'xxx' 字面量正确） - JVM 启动参数加
-Doracle.jdbc.defaultNChar=true，否则即使连接串写了，某些版本驱动仍走默认字节路径 - 数据库字符集为
ZHS16GBK时，不要强行用 UTF-8 连接：JDBC 会尝试转码，但ZHS16GBK不是AL32UTF8的子集，部分生僻汉字会变成? - 验证方式：执行
SELECT DUMP('测试', 1016) FROM DUAL，看返回值是否与 Java 端"测试".getBytes(StandardCharsets.UTF_8)的十六进制一致
最麻烦的其实是混合环境：开发机 Win10（GBK）、测试库 Linux（AL32UTF8）、中间件容器（locale=C）。这时候光调一个 NLS_LANG 没用，得逐层确认每个环节的编码协商是否真正达成一致——尤其是那些不声不响就做隐式转换的地方。
