NLS_LANG设错是Oracle中文乱码主因，需根据数据库字符集（AL32UTF8/ZHS16GBK）严格匹配客户端第三段值，且不同工具生效方式各异：SQL*Plus读系统变量，PL/SQL Developer需界面配置，JDBC须URL参数，cx_Oracle新版优先自动协商。
NLS_LANG 设错是绝大多数 Oracle 中文乱码的直接原因，不是数据库坏了，也不是程序写错了——只是客户端没告诉服务端“我用什么编码收发数据”。
查清数据库真实字符集，别猜
所有配置都得基于这个值来对齐，不能凭印象或工具默认值。
- 执行
SELECT * FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';，看返回值是AL32UTF8、ZHS16GBK还是US7ASCII -
US7ASCII是硬伤：它根本不存中文，后续所有“修复”都是掩耳盗铃，必须重建库或导出重导 - 如果返回
AL32UTF8，客户端NLS_LANG的第三段必须是AL32UTF8；如果是ZHS16GBK，第三段就得是ZHS16GBK，混用必乱码
不同客户端，NLS_LANG 生效方式完全不同
同一个环境变量，在 SQL*Plus、PL/SQL Developer、Java JDBC 里地位天差地别。
-
SQL*Plus和 OCI 类工具（如exp/imp）严格读系统NLS_LANG环境变量：Windows 在系统属性里设，Linux/macOS 在~/.bashrc或/etc/profile里export NLS_LANG=AMERICAN_AMERICA.AL32UTF8，改完要新开终端 -
PL/SQL Developer不认系统变量，得进Tools → Preferences → Oracle → Connection里手动填完整值，比如SIMPLIFIEDCHINESE_CHINA.AL32UTF8（注意中间无空格） -
JDBC根本不看NLS_LANG，必须在连接 URL 里加参数：jdbc:oracle:thin:@//host:1521/pdb?useUnicode=true&characterEncoding=UTF-8—— 如果库是ZHS16GBK，这里就得写characterEncoding=GBK
Python cx_Oracle 别乱设 NLS_LANG
新版（v8+）默认走 Unicode 协商，硬设反而容易翻车。
- 优先不设
NLS_LANG环境变量，让cx_Oracle自动匹配：它会结合 Python 源文件编码（# -*- coding: utf-8 -*-）和数据库字符集协商 - 如果非得控制，用
cx_Oracle.init_oracle_client(config_dir=...)指定tnsnames.ora路径，比依赖环境变量更稳 - 连接建立后立刻检查
conn.encoding和conn.nencoding，这两个值必须和数据库NLS_CHARACTERSET一致，否则说明协商失败，问题出在监听器或tnsnames.ora配置上 - 绝对不要在插入前做
str.encode('gbk').decode('utf-8')这类手动转码，cx_Oracle会按协商结果自动处理，手动干预等于叠 buff 式乱码
导出 SQL 文件后打开是乱码，不是数据库问题
这是 PL/SQL Developer 或 Toad 这类工具导出时用的编码和你编辑器猜的编码不一致，跟数据库字符集无关。
- 导出时务必勾选
UTF-8 with BOM（不是“UTF-8”），VS Code、Notepad++ 才能准确识别 - 导出后用命令行验证：
file -i xxx.sql（Linux/macOS）或Get-Content xxx.sql -Encoding UTF8（PowerShell）看实际编码 - 别信编辑器右下角显示的“UTF-8”，很多编辑器看到没 BOM 就默认当 ANSI（即 GBK）处理，一打开就变形
真正容易被忽略的是：NLS_LANG 的三段式格式（LANGUAGE_TERRITORY.CHARACTERSET）缺一不可，中间必须是下划线，不能有空格；而工具是否读这个变量，完全取决于它的启动方式和底层驱动类型——图形界面工具几乎都不继承 shell 环境变量，靠设系统变量根本无效。
