Oracle 11g Linux中文乱码设置NLS_LANG环境变量解决

说到底，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，而不是靠肉眼判断“好像不乱”。