查数据库字符集应使用select userenv('language') from dual，其返回值language_territory.characterset（如american_america.zhs16gbk）是nls_lang的直接来源，必须严格一致，空格、大小写和标点均敏感；windows需新建系统变量nls_lang并重启pl/sql developer，linux需在shell配置文件中正确export；新版pl/sql developer需关闭tools→preferences→environment→encoding中的“use system encoding”选项，否则会绕过nls_lang导致乱码。
查数据库字符集用 userenv('language')，别只看 V$NLS_PARAMETERS
很多人执行 select * from V$NLS_PARAMETERS 后盯着第一行 NLS_LANGUAGE 和第九行 NLS_CHARACTERSET 对比，但这是错的。真正决定客户端行为的是数据库会话级语言环境，必须用 select userenv('language') from dual。这个结果格式是 LANGUAGE_TERRITORY.CHARACTERSET（比如 AMERICAN_AMERICA.ZHS16GBK），它才是 NLS_LANG 的直接来源。忽略这点，光按操作系统区域设置硬填 ZHS16GBK，遇到 UTF-8 数据库就会出问题。
NLS_LANG 必须和 userenv('language') 完全一致，空格和大小写都敏感
Windows 下新建系统环境变量时，值必须严格匹配查询结果，包括中间的点号、下划线和大小写。常见错误有：
• 写成 SIMPLIFIED CHINESE_CHINA.ZHS16GBK（空格不能出现在语言名里）
• 写成 american_america.zhs16gbk（Oracle 不认小写）
• 多加一个空格变成 AMERICAN_AMERICA. ZHS16GBK（点后不能有空格）
改完必须重启 PL/SQL Developer 或命令行终端，否则变量不生效。Linux/macOS 还要确认 shell 配置文件（如 ~/.bashrc）里用了 export NLS_LANG=...，不是只写 NLS_LANG=...。
字符串截断本质是字符长度计算错，ZHS16GBK 下中文占 2 字节，AL32UTF8 下可能占 3 字节
当表字段定义为 VARCHAR2(10)，在 ZHS16GBK 字符集下最多存 10 个中文；但在 AL32UTF8 下，10 字节只能存 3 个中文（每个占 3 字节），第 4 个字就截断了。这种“截断”不是报错，而是静默丢弃——你看到的可能是前几个字加一堆问号或方框。验证方法：插入 '测试数据abc'，再查 dump(列名) 看实际字节流，对比字段定义长度和 dump 输出的 Len 值。
PL/SQL Developer 自身编码设置会覆盖 NLS_LANG，优先关掉
新版 PL/SQL Developer（v14+）在 Tools → Preferences → Environment → Encoding 里默认勾选了 “Use system encoding”。这个选项一旦启用，会强制用 Windows 系统 ANSI 编码（通常是 GBK）去解码网络流，完全绕过 NLS_LANG 设置。结果就是：即使 NLS_LANG 设对了，显示仍是乱码。解决方法：取消勾选该选项，让 PL/SQL Developer 完全依赖 NLS_LANG 做字符转换。如果仍异常，再检查是否启用了 “Auto detect encoding”，也一并关闭。
字符集配置不是一次设完就高枕无忧的事——数据库升级、迁移、跨平台连接都会让 NLS_LANG 失效。最稳妥的做法是每次换环境都重新跑一遍 userenv('language')，而不是复用旧配置。
