说到底，Oracle 11g 在 Linux 上中文乱码，90% 是因为
NLS_LANG没设对，或者设了但没生效——不是数据库字符集错了，也不是终端本身不支持中文。
怎么查清数据库实际字符集
别猜，直接问数据库：
SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET';
返回值常见两种：ZHS16GBK（GBK 编码）或 AL32UTF8（Oracle 的 UTF-8 实现）。注意：UTF8 ≠ AL32UTF8，后者才支持 4 字节 Unicode（如 emoji、生僻汉字），前者是 Oracle 旧版简化编码，现在基本弃用。
- 如果返回
ZHS16GBK，客户端NLS_LANG第三段必须是ZHS16GBK，不能填AL32UTF8 - 如果返回
AL32UTF8，第三段必须是AL32UTF8，填UTF8会报ORA-12705 - 别抄
NLS_DATABASE_PARAMETERS的值直接当客户端用——它只说明服务端存什么，不代表你终端能正确渲染什么
Linux 下怎么正确设置 NLS_LANG 环境变量
关键不是“设了”，而是“被进程读到”。SQL*Plus 启动时只读启动它的 shell 的当前环境变量，不继承父进程之外的配置。
- 在
~/.bash_profile或~/.bashrc里加一行：export NLS_LANG=AMERICAN_AMERICA.AL32UTF8（按实际字符集替换第三段） - 改完必须执行
source ~/.bash_profile（或source ~/.bashrc），否则新终端也看不到 - 别写成
NLS_LANG='AMERICAN_AMERICA . AL32UTF8'——中间空格、引号多余、大小写混用都会让 Oracle 忽略该变量 - 检查是否生效：
echo $NLS_LANG，输出必须是完整三段式，如AMERICAN_AMERICA.ZHS16GBK
为什么设置了还是乱码：工具不读环境变量
很多图形化或封装过的工具压根不继承 shell 的 NLS_LANG，尤其 PL/SQL Developer、Toad、甚至某些 Ja va 启动脚本。
- SQL*Plus：老老实实读 shell 环境变量，设对就生效
- PL/SQL Developer：进
Tools → Preferences → Oracle → Connection，手动填NLS_LANG值，这里优先级高于系统变量 - Toad：连接配置页底部有
NLS Settings区域，必须单独填 - Ja va 应用（JDBC）：
NLS_LANG完全无效，得在连接 URL 加参数，例如?useUnicode=true&characterEncoding=UTF-8
验证是否真生效，而不是“看起来不乱”
在 SQL*Plus 连上后，执行：
SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER IN ('NLS_LANGUAGE', 'NLS_TERRITORY', 'NLS_CHARACTERSET');
重点看 NLS_CHARACTERSET 这一行的 VALUE —— 它才是当前 session 实际使用的客户端字符集。如果它和你数据库的 NLS_CHARACTERSET 不一致，说明协商失败，数据可能已“看错”或“输错”。
- 插入前可用
SELECT DUMP('测试', 1016) FROM DUAL;查十六进制值，比对是否符合预期编码 - 导出
.dmp文件时，NLS_LANG决定文件编码，设错会导致文件本身乱码，后续无法恢复 - Windows 客户端设
ZHS16GBK连AL32UTF8库，看似能显示，但插入含 emoji 的字符串会截断或报错
最常被忽略的是：不同工具加载 NLS_LANG 的时机和位置完全不同，不能设一次就以为全局解决；验证必须落到 NLS_SESSION_PARAMETERS，而不是靠肉眼判断“好像不乱”。
