oracle错误消息字符串和表里字符串字段(分别)乱码的原因(NLS)


设计客户端nls_lang这个变量的作用是讲oracle服务端发来的所有字符串(包括错误消息字符串和表里字符串字段)的以服务端数据库字符集

编码的编码值转码为客户端字符集(狭义,即操作系统字符集)的编码值
故客户端nls_lang要和客户端字符集一致才好,否则就可能会乱码。客户端nls_lang要和客户端字符集间不转码,
即设置为客户端字符集的客户端输出函数不转码

地显示以客户端nls_lang编码的
字符串为参数的值(从如下例子可知的:客户端nls_lang为ZHS16GBK,客户端字符集cmd 为代码页437时 如 表里的中文数据为乱码,而非?

字符,即可知道这里未发生转码)。


例如,输出函数如printf都是将要输出的字符串的编码值按照操作系统语言设置里(非Unicode)的字符集来解释显示 。该字符集设置改变,则原输出正常显示的字符串将变为乱码。

输出函数wprintf固定将要输出的字符串的编码值按照Unicode字符集来解释显示,与 操作系统语言设置里(非Unicode)的字符集设置无关


表里char数据类型的字符串字段 在 服务端数据库里以database级别的nls_charset字符集编码的
表里nchar数据类型的字符串字段 在 服务端数据库里以database级别的nls_ncharset字符集编码的

错误消息字符串等由session级别的nls_language决定,而nls_language值对应用的字符集由oracle服务端软件决定


oracle服务端发来的错误消息字符串  根据客户端nls_lang 转码。证明如下:
其他条件不变,即 服务端数据库字符集为ZHS16GBK 客户端字符集cmd GBK,
客户端nls_lang 分别为
KOREAN_CHINA.KO16KSC5601
KOREAN_CHINA.AL32UTF8
时显示的乱码字符不一样,说明有转码。

再如,
其他不变 服务端数据库字符集为ZHS16GBK 客户端字符集cmd GBK(即ZHS16GBK)
客户端nls_lang
SIMPLIFIED CHINESE_CHINA.US7ASCII
显示??字符,说明有转码(源字符集的字符不存在目标字符集里时,一般转码为?字符)

oracle服务端发来的错误消息字符串是否按
服务端数据库字符集编码的?
服务端数据库字符集为ZHS16GBK还是AL32UTF8
客户端nls_lang为ZHS16GBK时不乱码;
客户端nls_lang为AL32UTF8时乱码;
客户端字符集cmd一直是 GBK
这个例子还不能证明上述结论,因为
(客户端nls_lang为)ZHS16GBK 和(服务端数据库字符集为)AL32UTF8间(共有的字符)是可正确转码的,
而客户端nls_lang为AL32UTF8时客户端cmd的字符集为 GBK,故最后显示为乱码。

服务端数据库字符集为ZHS16GBK 客户端字符集cmd 韩文
客户端nls_lang
KOREAN_CHINA.KO16KSC5601
不乱码 说明oracle服务端发来的错误消息字符串不按
服务端数据库字符集编码的,而是

错误消息字符串等由session级别的nls_language决定,而nls_language值对应用的字符集由oracle服务端软件决定。



参考:

Oracle中NLS_LANG的默认值

【不错】浅析Oracle三层全球化支持(NLS)

nls_lang Korea 百度

【不错 转自mos中文文章】Microsoft Windows 环境中NLS_LANG的正确设置


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值