<p>Oracle 11g Linux中文乱码主因是NLS_LANG未正确设置或未生效,需先查数据库字符集(SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER = 'NLS_CHARACTERSET'),再按返回值(ZHS16GBK或AL32UTF8)严格配置三段式NLS_LANG,最后通过SELECT * FROM NLS_SESSION_PARAMETERS验证session实际字符集是否匹配。</p>
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 的值直接当客户端用——它只说明服务端存什么,不代表你终端能正确渲染什么关键不是“设了”,而是“被进程读到”。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、甚至某些 Java 启动脚本。
Tools → Preferences → Oracle → Connection,手动填 NLS_LANG 值,这里优先级高于系统变量NLS Settings 区域,必须单独填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 决定文件编码,设错会导致文件本身乱码,后续无法恢复ZHS16GBK 连 AL32UTF8 库,看似能显示,但插入含 emoji 的字符串会截断或报错最常被忽略的是:不同工具加载 NLS_LANG 的时机和位置完全不同,不能设一次就以为全局解决;验证必须落到 NLS_SESSION_PARAMETERS,而不是靠肉眼判断“好像不乱”。