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

从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操作系统,其它不详
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值