NLS_LANG必须与数据库字符集严格匹配，否则中文显示为?或方块；需通过SELECT * FROM NLS_DATABASE_PARAMETERS查NLS_CHARACTERSET等参数，Windows下应设系统级环境变量如SIMPLIFIED CHINESE_CHINA.ZHS16GBK并重启PL/SQL Developer确认生效。
NLS_LANG 必须与数据库字符集严格匹配，否则中文必然显示为 ? 或方块
查清数据库实际字符集用 SELECT * FROM NLS_DATABASE_PARAMETERS
别信“系统默认是 UTF8”这种说法。执行这条 SQL，重点看三行：
-
NLS_CHARACTERSET：决定数据库存储用什么编码（如ZHS16GBK、AL32UTF8） -
NLS_LANGUAGE和NLS_TERRITORY：合起来构成 NLS_LANG 的前两段（如SIMPLIFIED CHINESE_CHINA）
常见错误是把 SELECT USERENV('LANGUAGE') FROM DUAL 的结果直接当全部——它只返回语言+地域，缺字符集，拼出来必错。
Windows 下设 NLS_LANG 环境变量比改注册表更可靠
注册表路径（如 HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_OraClient19c_home1）容易因客户端版本、位数（32/64）、安装方式（绿色版/完整版）而失效。环境变量则无此问题：
- 变量名：
NLS_LANG - 变量值：按“语言_地域.字符集”拼，例如
SIMPLIFIED CHINESE_CHINA.ZHS16GBK（注意中间是下划线和点，不能有空格） - 设在“系统变量”里，不是用户变量——PL/SQL Developer 启动时读的是系统级环境
- 设完必须彻底关闭并重启 PL/SQL Developer，仅刷新窗口无效
确认 NLS_LANG 是否生效，看 PL/SQL Developer 的“关于”对话框
启动后点 帮助 → 关于，弹窗底部会显示当前加载的 NLS_LANG 值。如果还是空白、AMERICAN_AMERICA.US7ASCII 或其他不匹配值，说明：
- 环境变量没生效（检查是否设在系统变量、是否重启工具）
- 机器上装了多个 Oracle 客户端，PATH 优先加载了旧版本的
oraociei19.dll，导致实际加载的是另一套配置 - PL/SQL Developer 自身设置了“首选项 → 连接 → Oracle Home”，手动指定了错误的客户端路径
遇到 US7ASCII 数据库时，NLS_LANG 设置无效是正常现象
US7ASCII 是单字节字符集，根本不支持中文。此时无论你把 NLS_LANG 设成什么，Oracle Net 在传输层都会强制截断或替换非 ASCII 字节。表现就是查询出的中文全变成 ???，且无法通过客户端配置修复。
唯一可行路径是应用层绕过：用 UTL_RAW.CAST_TO_VARCHAR2 + CONVERT 手动转码，或改用支持原始字节透传的驱动（如某些 JDBC 的 useUnicode=false&connectionTimeZone=GMT 组合）。但这是数据读取逻辑的改造，不是配置能解决的。
