楼主: jeffli73

[精华] Oracle数据库字符集问题解析

[复制链接]
论坛徽章:
62
马上加薪
日期:2014-02-19 11:55:142012新春纪念徽章
日期:2012-01-04 11:49:54ITPUB十周年纪念徽章
日期:2011-11-01 16:20:28现任管理团队成员
日期:2011-05-07 01:45:082011新春纪念徽章
日期:2011-02-18 11:42:472011新春纪念徽章
日期:2011-01-25 15:42:562011新春纪念徽章
日期:2011-01-25 15:42:332011新春纪念徽章
日期:2011-01-25 15:42:152011新春纪念徽章
日期:2011-01-25 15:41:502011新春纪念徽章
日期:2011-01-25 15:41:01
发表于 2005-6-2 12:50 | 显示全部楼层
经典之作!顶!

使用道具 举报

回复
论坛徽章:
28
ITPUB元老
日期:2005-06-17 10:37:44操作系统板块每日发贴之星
日期:2005-07-02 01:01:58数据库板块每日发贴之星
日期:2005-07-18 01:01:26管理团队2006纪念徽章
日期:2006-04-16 22:44:45会员2006贡献徽章
日期:2006-04-17 13:46:34
发表于 2005-6-3 00:56 | 显示全部楼层
好文章,不过,最后的几个问题还没有回答,希望搂主解决以下。

使用道具 举报

回复
论坛徽章:
0
发表于 2005-6-3 09:51 | 显示全部楼层

关于字符集问题,救助各位大侠!

这段时间我也为中文乱码显示苦恼啊!
情况是这样:
1、源数据库PRD(在UNIX 环境下,SAP系统的数据库),而目标数据库DWEIS(是在Windows 2000 server环境下的,新装测试用的

)。
2、目标数据库与源数据库字符集是一样的,ORACLE 也都是同一版本9.2
3、结果是目标数据库中SQL*PLUS显示中文为乱码,通过远程数据连接插入的表中数据中文部份同样显示为乱码。
prd(源数据库):
select * from V$NLS_PARAMETERS
NLS_LANGUAGE        SIMPLIFIED CHINESE
NLS_TERRITORY        CHINA
NLS_CURRENCY        RMB
NLS_ISO_CURRENCY        CHINA
NLS_NUMERIC_CHARACTERS        .,
NLS_CALENDAR        GREGORIAN
NLS_DATE_FORMAT        MM/DD/YYYY HH24:MI:SS
NLS_DATE_LANGUAGE        SIMPLIFIED CHINESE
NLS_CHARACTERSET        WE8DEC
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 TZH:TZM
NLS_TIMESTAMP_TZ_FORMAT        DD-MON-RR HH.MI.SSXFF AM TZH:TZM
NLS_DUAL_CURRENCY        RMB
NLS_NCHAR_CHARACTERSET        UTF8
NLS_COMP        BINARY
NLS_LENGTH_SEMANTICS        BYTE
NLS_NCHAR_CONV_EXCP        FALSE

dweis(目标数据库):我在安装时,字符集已设置为一样。
select * from V$NLS_PARAMETERS
NLS_LANGUAGE        SIMPLIFIED CHINESE
NLS_TERRITORY        CHINA
NLS_CURRENCY        RMB
NLS_ISO_CURRENCY        CHINA
NLS_NUMERIC_CHARACTERS        .,
NLS_CALENDAR        GREGORIAN
NLS_DATE_FORMAT        MM/DD/YYYY HH24:MI:SS
NLS_DATE_LANGUAGE        SIMPLIFIED CHINESE
NLS_CHARACTERSET        WE8DEC
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        UTF8
NLS_COMP        BINARY
NLS_LENGTH_SEMANTICS        BYTE
NLS_NCHAR_CONV_EXCP        FALSE

select name,value$ from sys.props$
NAME        VALUE$
DICT.BASE        2
DEFAULT_TEMP_TABLESPACE        TEMP
DBTIMEZONE        -07:00
NLS_LANGUAGE        AMERICAN
NLS_TERRITORY        AMERICA
NLS_CURRENCY        $
NLS_ISO_CURRENCY        AMERICA
NLS_NUMERIC_CHARACTERS        .,
NLS_CHARACTERSET        WE8DEC
NLS_CALENDAR        GREGORIAN
NLS_DATE_FORMAT        DD-MON-RR
NLS_DATE_LANGUAGE        AMERICAN
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        $
NLS_COMP        BINARY
NLS_LENGTH_SEMANTICS        BYTE
NLS_NCHAR_CONV_EXCP        FALSE
NLS_NCHAR_CHARACTERSET        UTF8
NLS_RDBMS_VERSION        9.2.0.1.0
GLOBAL_DB_NAME        DWEIS.US.ORACLE.COM
EXPORT_VIEWS_VERSION        8
(注:在源数据库中NLS也一样的
NLS_LANGUAGE        AMERICAN
NLS_TERRITORY        AMERICA
NLS_CHARACTERSET        WE8DEC)
目标数据库DWEIS远程连接如下:
create public database link sap_prd connect to zcam identified by zcam using 'prd';
CREATE TABLE zmat_temp AS
select * from sapprd.zmat_input@sap_prd where mandt='900' and rownum<11;

select matnr,maktx,substr(maktx,1,8),CONVERT(maktx,'ZHS16GBK','WE8DEC') from zmat_temp;
000000000009500019        D2822£¤5??£???2a?°        D2822£¤5        D2822?ê?è5?£??ê£?£??2a£???
000000000009700043        ET62429£¤DIP8£?3é2a?°        ET62429£        ET62429?ê?èDIP8?ê£?3¤?2a£???
000000000009700027        ETK4800£¤SOP16£?3é2a?°        ETK4800£        ETK4800?ê?èSOP16?ê£?3¤?2a£???
000000000009700034        D2314(SOP28)3é2a?°        D2314(SO        D2314(SOP28)3¤?2a£???
000000000009700035        D2313£¤SOP28£?3é2a?°        D2313£¤S        D2313?ê?èSOP28?ê£?3¤?2a£???
000000000009700028        ET16312(QFP44)3é2a?°        ET16312(        ET16312(QFP44)3¤?2a£???
000000000009700026        ET8211S£¤SOP8£?3é2a?°        ET8211S£        ET8211S?ê?èSOP8?ê£?3¤?2a£???
000000000009700026        ET8211S£¤SOP8£?3é2a?°        ET8211S£        ET8211S?ê?èSOP8?ê£?3¤?2a£???
000000000009700028        ET16312(QFP44)3é2a?°        ET16312(        ET16312(QFP44)3¤?2a£???
000000000009102191        sca115(±?á?£?Ver1PT?°        sca115(±        sca115(?à?¤¢£??ê£?Ver1PT£???

本人在ORACLE数据库之间字符集处理方面是新手,希望能得到各位热心人的指点。谢谢了!

使用道具 举报

回复
论坛徽章:
18
操作系统板块每日发贴之星
日期:2005-07-28 01:01:51沸羊羊
日期:2015-03-04 14:43:43马上有车
日期:2014-02-18 16:41:112014年新春福章
日期:2014-02-18 16:41:11ITPUB 11周年纪念徽章
日期:2012-10-09 18:05:072011新春纪念徽章
日期:2011-02-18 11:43:32ITPUB9周年纪念徽章
日期:2010-10-08 09:32:272009新春纪念徽章
日期:2009-01-04 14:52:282008新春纪念徽章
日期:2008-02-13 12:43:03ITPUB新首页上线纪念徽章
日期:2007-10-20 08:38:44
发表于 2005-6-5 06:41 | 显示全部楼层
你的数据库都选择了LS_CHARACTERSET  WE8DEC。
WE8DEC是西欧语系的字符集,而且每个字符都使用8Bit来进行编码。按照道理,本来不应该支持中文。

使用道具 举报

回复
论坛徽章:
0
发表于 2005-6-15 11:45 | 显示全部楼层
cxc9532
我也遇到过类似问题
我的情况是:Sever为Win2k,装Oracle 8.16,字符集为WEI8什么的。 当用另一Win2k作Client时就出现你说的情况(在Client上用SQL PLUS插入汉字,SQL插入语句显示正常,但查询为乱码,在Server端也一样查询为乱码)。真是不可理解
  而我用原来的一端Win98机子作client一切正常。

使用道具 举报

回复
论坛徽章:
9
授权会员
日期:2005-10-30 17:05:33生肖徽章2007版:猴
日期:2009-03-10 21:16:262010广州亚运会纪念徽章:马术
日期:2010-11-12 17:41:272010广州亚运会纪念徽章:高尔夫球
日期:2010-12-30 18:46:462011新春纪念徽章
日期:2011-02-18 11:42:50ITPUB十周年纪念徽章
日期:2011-11-01 16:19:41ITPUB 11周年纪念徽章
日期:2012-10-09 18:03:322014年新春福章
日期:2014-02-18 16:41:11马上有车
日期:2014-02-18 16:41:11
发表于 2005-6-29 11:59 | 显示全部楼层
非常好的帖子。。

使用道具 举报

回复
论坛徽章:
0
发表于 2005-6-30 20:50 | 显示全部楼层
分析的确非常透彻,用力顶!!!

使用道具 举报

回复
论坛徽章:
2
参与2007年甲骨文全球大会(中国上海)纪念
日期:2007-08-06 15:19:01
发表于 2005-7-24 08:31 | 显示全部楼层

好帖

非常有用

使用道具 举报

回复
论坛徽章:
0
发表于 2005-7-27 11:08 | 显示全部楼层
终于看完了,基本明白了,thx

使用道具 举报

回复
论坛徽章:
1
授权会员
日期:2005-10-30 17:05:33
发表于 2005-8-7 23:26 | 显示全部楼层

数据库字符集转换的新问题(ZHS16GBK->UTF8)??

最初由 jeffli73 发布
[B]看了wyq21973朋友的帖子,当时就有些疑问,因为上面我也提到从理论上讲汉字由ZHS16GBK到UTF8的转换是可能的,是不是因为wyq21973朋友用的Oracle8.1.7,还没提供这种转换呢,但由于当时也没条件试,就放了下来,最近看到论坛里关于字符集的问题又不少,于是决定做一下进一步的实验;
我的PC上本来已经装了一个数据库test1,字符集为ZHS16GBK,今天利用DBCA又建了一个test2,字符集选用UTF8。
实验所用的数据库版本为:Oracle9i Enterprise Edition Release 9.2.0.1.0
''''''''''''''''''''''''''''''
7.小结
[B]在Oracle 9.2环境下,汉字可以由ZHS16GBK转换为UTF8;
数据库服务器选用的字符集虽然可以各不相同,但只要各种相关设置正确,Oracle总是尽可能地将正确的转换结果呈现给客户端的用户。[/B] [/B]



我觉得上述结论可能也不能那么绝对!! "Oracle 9.2环境下,汉字可以由ZHS16GBK转换为UTF8"

这两天我也碰到一个数据库字符集转换的问题. 我需要将一个使用ZHS16GBK的数据库的数据imp到一个UTF8的数据库中, exp倒出文件的字符集也是ZHS16GBK. 我的操作系统是HP11I 英文的,ORACLE9.2设置NLS_LANG为"simple chinese_china.ZHS16GBK"后再imp到UTF8的数据库中时发现exp中报了很多ORA-1401 "inserted value too large for column"的错误,虽然最后也是报"imp succesful with warnning"; 我不太明白UTF8应该是ZHS16GBK的超集怎么会转换不成功呢??  于是我想将数据库字符集更改为ZHS16GBK,开始使用alter database character set ZHS16GBK 不成功因为ZHS16GBK不是UTF8的超集,因为没看eygle的那篇文章, 于是我直接了props$表, 结果我的数据库起不了,alert日志报好象是12701的 错误"CREATE DATABASE character set is not known"
,http://www.eygle.com/index-special.htm

后来我仔细查1401的错误,又在网上查了些文章,包括jeffli73网友的文章,觉得可能是ORACLE在转化ZHS16GBK到UTF8时候,数据长度变长了,如将一个2字节的字符转化成了UTF8定义的3字节(个人理解,不知是否正确),所以导致字符长度超出了表的列定义的长度因而导致imp报1401的错误,.
可是这有没有比较好的办法解决呢? 因为涉及到的表比较多,一个个去更改表列定义太多了..

另我的数据库更改props$后不能启动,能mount, 是否跟操作系统环境有关?? 因为我好象在哪看到资料说 "create database character set"是跟创建v$nls_parameters动态性能有关, 我觉得可能是操作系统不支持我更改的字符集所以ORACLE 在启动时候报12701 这个错.
我回头再在系统上安装中文语言试试看看..

请各位高手指点迷津!!!

使用道具 举报

回复

您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

TOP技术积分榜 社区积分榜 徽章 团队 统计 知识索引树 积分竞拍 文本模式 帮助
  ITPUB首页 | ITPUB论坛 | 数据库技术 | 企业信息化 | 开发技术 | 微软技术 | 软件工程与项目管理 | IBM技术园地 | 行业纵向讨论 | IT招聘 | IT文档
  ChinaUnix | ChinaUnix博客 | ChinaUnix论坛
CopyRight 1999-2011 itpub.net All Right Reserved. 北京盛拓优讯信息技术有限公司版权所有 联系我们 
京ICP备09055130号-4  北京市公安局海淀分局网监中心备案编号:11010802021510 广播电视节目制作经营许可证:编号(京)字第1149号
  
快速回复 返回顶部 返回列表