oracle中文乱码主因是nls_lang配置错误，需严格匹配数据库字符集（al32utf8或zhs16gbk）；sql*plus等oci工具只读环境变量，pl/sql developer须在界面手动配置三段式值，jdbc必须在连接url中指定characterencoding参数。
直接改配置文件解决 Oracle 客户端中文乱码，只对部分工具有效——SQL*Plus 和 OCI 类命令行工具不认配置文件，只读 NLS_LANG 环境变量；而 PL/SQL Developer、Toad、某些 JDBC 封装层才真正从配置文件读取字符集设置。盲目改错地方，等于白忙。
PL/SQL Developer 必须在 Tools → Preferences → Oracle → Connection 里填 NLS_LANG
它完全忽略系统环境变量和注册表里的 NLS_LANG，只认自己界面里手动输入的值。常见翻车点：
- 值必须是三段式完整格式，例如
SIMPLIFIEDCHINESE_CHINA.ZHS16GBK（注意中间无空格，SIMPLIFIED CHINESE带空格会失效） - 填完必须点 OK 并重启 PL/SQL Developer，热加载不生效
- 如果连的是远程库，还要确认该客户端机器上已安装对应字符集的 Oracle Instant Client（比如 ZHS16GBK 需要含该字符集支持的 client 版本）
tnsnames.ora 本身不控制字符集，但影响 NLS_LANG 协商结果
tnsnames.ora 文件不存字符集配置，但它定义的连接别名可能触发不同监听器行为，间接导致 NLS_LANG 协商失败。关键点：
- 确保
TNS_ADMIN环境变量指向含正确tnsnames.ora的目录，否则客户端可能 fallback 到默认监听地址，绕过你设的NLS_LANG - 若使用 EZCONNECT 格式（如
sqlplus user/pass@host:1521/orcl），tnsnames.ora不参与，此时NLS_LANG是否生效全看环境变量是否被读到 - 检查监听器日志（
$ORACLE_HOME/network/log/listener.log）是否有TNS-12537或字符集协商警告，那是底层 OCI 层已拒绝按你声明的字符集通信
JDBC 连接串里加 characterEncoding 才算真正“改配置文件”
JDBC 驱动压根不看 NLS_LANG，必须在连接 URL 中显式指定编码参数：
- 数据库是
AL32UTF8：URL 加?useUnicode=true&characterEncoding=UTF-8 - 数据库是
ZHS16GBK：URL 加?useUnicode=true&characterEncoding=GBK（不是 GB2312，Oracle 对 GBK 支持更稳） - Spring Boot 中写在
application.yml里时，要双写反斜杠：url: jdbc:oracle:thin:@//host:1521/pdb?useUnicode=true\&characterEncoding=UTF-8 - Tomcat 的
context.xml里配数据源时，&要写成&，否则 XML 解析失败
最容易被忽略的是：很多团队把 NLS_LANG 设在 shell 配置文件里，却用 IDE（如 IntelliJ）直接运行 Java 程序——IDE 启动的 JVM 不继承终端环境变量，NLS_LANG 对它完全无效，必须靠 JDBC URL 控制。这点不验证，改十遍配置都没用。
