oracle客户端乱码本质是nls_lang字符集与终端实际编码不匹配，其格式为language_territory.characterset，须三段齐全且顺序固定；设置后需在sql*plus中查询nls_session_parameters验证生效情况。
oracle客户端乱码本质是字符集不匹配
oracle客户端显示乱码，90%以上不是数据库本身问题，而是客户端环境没告诉oracle“我用什么字符集解码”。nls_lang就是干这个的——它不改变数据存储，只控制客户端如何解释从服务端传来的字节流。设错就等于让客户端用gbk去解utf-8编码的字节，结果必然是方块、问号或乱码字符。
设置NLS_LANG必须三段式且顺序固定
NLS_LANG格式是 LANGUAGE_TERRITORY.CHARACTERSET，缺一不可，顺序不能颠倒。常见错误是只写ZHS16GBK或AMERICAN_AMERICA.AL32UTF8，漏掉中间的TERRITORY部分，Oracle会直接忽略该变量。
-
LANGUAGE：决定提示信息语言（如AMERICAN、CHINESE），不影响数据编码 -
TERRITORY：决定日期/数字格式（如AMERICA、CHINA），必须与LANGUAGE逻辑匹配 -
CHARACTERSET：最关键！必须和客户端实际使用的字符集一致（如Windows命令行默认GBK，就配ZHS16GBK；Linux终端用UTF-8，就配AL32UTF8）
不同场景下NLS_LANG设置方式差异大
同一台机器上，SQL*Plus、PL/SQL Developer、Java应用、Python cx_Oracle各自读取NLS_LANG的优先级和位置不同，不能只设系统环境变量就以为万事大吉。
- Windows命令行：在启动SQL*Plus前用
set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK，临时生效；永久设需改系统环境变量，但要注意重启CMD才生效 - Linux终端：在
~/.bashrc里加export NLS_LANG=AMERICAN_AMERICA.AL32UTF8，然后source ~/.bashrc - PL/SQL Developer：工具→首选项→Oracle→连接→语言，这里填的值会覆盖系统环境变量
- Java应用：不能依赖
NLS_LANG，必须在JDBC URL里显式指定字符集，例如?useUnicode=true&characterEncoding=UTF-8
验证是否生效比设置更重要
设完NLS_LANG不验证，等于没设。最简单方法是在SQL*Plus里执行：SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER = 'NLS_LANGUAGE' OR PARAMETER = 'NLS_TERRITORY' OR PARAMETER = 'NLS_CHARACTERSET';。注意看返回的NLS_CHARACTERSET值——它反映的是当前session实际生效的字符集，不是数据库的DBA_DATABASES.NLS_CHARACTERSET。
- 如果查出来是
AL32UTF8但你终端是GBK，依然会乱码 - 如果查出来是
ZHS16GBK但数据库存的是UTF-8编码的中文，插入时可能报ORA-12899（值太大） - Windows下用
chcp命令确认当前CMD代码页，chcp 936对应GBK，chcp 65001对应UTF-8，必须和NLS_LANG的第三段一致
真正麻烦的不是怎么设，而是同一个Oracle客户端要连多个字符集不同的库，或者开发环境和生产环境终端默认编码不一致。这时候硬靠NLS_LANG容易顾此失彼，得靠应用层做转码或统一终端环境。
