oracle的asciistr函数惹祸了（在9i和10g上运行输出结果不一致）

最新推荐文章于 2025-05-26 18:07:08 发布

luocm

最新推荐文章于 2025-05-26 18:07:08 发布

阅读量2.6k

点赞数

CC 4.0 BY-SA版权

分类专栏：数据库文章标签： oracle sun calendar aix solaris date

本文链接：https://blog.youkuaiyun.com/luocm/article/details/2638155

数据库专栏收录该内容

34 篇文章

订阅专栏

从Oracle9i升级到10g后，发现ASCII函数在不同版本间存在输出结果不一致的问题，尽管两个数据库的字符集设置相同。本文记录了这一现象，并探讨了可能的原因。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

从oracle9i升级到10g之后，意外地发现ascii函数在9i和10g上输出结果不一致，两个库的字符集设置完全相同，难道跟操作系统平台（9i：9.2.0.7.0安装在solaris操作系统上，10g：10.2.0.3.0安装在AIX操作系统上）有关？是否跟底层的C语言类库有关系？

到metalink、google上搜了一圈没有找到解决方案，在itpub的“oracle高级管理”论坛里发了个贴，没人理，真得是黔驴技穷了。去找Oracle技术人员？

附录A：两个库字符集设置完全相同
字符集配置相同（NLS_CHARACTERSET = ZHS16GBK，NLS_NCHAR_CHARACTERSET = AL16UTF16）

PARAMETER VALUE
NLS_LANGUAGE SIMPLIFIED CHINESE
NLS_TERRITORY CHINA
NLS_CURRENCY RMB
NLS_ISO_CURRENCY CHINA
NLS_NUMERIC_CHARACTERS .,
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT YYYY-MM-DD
NLS_DATE_LANGUAGE SIMPLIFIED CHINESE
NLS_CHARACTERSET ZHS16GBK
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY RMB
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE

附录B：两个库上执行，1-255之间的ASCII码表（92和128不相同）
SELECT chr(ROWNUM), asciistr(chr(ROWNUM))
FROM all_tab_cols
WHERE 1 = 1
AND ROWNUM <= 256; 
SELECT ascii(/'€/'), asciistr(/'€/'), ascii(/'//'), asciistr(/'//') FROM dual;
输出结果：
128 /FFFD 92 / --9i输出结果
128 /20AC 92 /005C --10g输出结果
 
附录C：系统环境
9i系统配置：
主机配置 Sun Microsystems  sun4u Sun Fire V890，4 cpu*1500MHZ，16G内存，EMC共享存储（Raid10）。
操作系统 SunOS jsdbcenter01 5.10 Generic_118822-11 sun4u sparc SUNW,Sun-Fire-V890
数据库系统 Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production，JSDC
10g系统配置：
AIX操作系统，其它不详