注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

太极虫的博客

好好学习,天天向上

 
 
 

日志

 
 

飞刀,又见飞刀  

2008-04-11 10:36:35|  分类: ORACLE技术 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

呵呵,这个题目有点吓人的,借用了古龙的小说名字,

之所以想到这么个题目实在是需要探讨的是一个非常古老且常见且平凡发生且不易解决且令人难以解决的问题,说了这么多废话,很多人可能已经猜到了我想说什么了,对的,那就是从诞生计算机技术就诞生的字符集问题。

好了,再说废话要被人揍了,切入正题吧(注:PW同志曾经在一个两个小时的讲座里,在第一个小时零十分钟的时候说:下面我们切入正题

 

提到ORACLE的字符集的转换,很多人立刻会想到服务器端字符集和客户端字符集的转换,这点很多人都清楚,就不多说了,我今天主要想介绍一下OS字符集以及OS字符集在字符集转换中起的作用。

下面看一个DEMO:

环境:
OS:WINXP SP2
中文版
ORACLE 10.2.0.1
服务器和客户端在一台机器上
服务器字符集:AL32UTF8 国家字符集 AL16UTF16
客户端字符集: AL32UTF8

以下是在SQLPLUS里面的操作:

SQL> create table test (a varchar2(10));
琛ㄥ凡鍒涘缓銆?
SQL> insert into test values ('
');
宸插垱寤?1 琛屻??
SQL> commit;
鎻愪氦瀹屾垚銆?
SQL> select a,dump(a)  from test;
A                                                                              
----------                                                                     
DUMP(A)                                                                        
--------------------------------------------------------------------------------

                                                                              
Typ=96 Len=2: 206,210               
                  

                                                                                
可以看到,服务器端和客户端都是UTF8但是显示出来的提示全部是乱码,

在看一下汉字""字的编码,我查了一下编码表,ZHS16GBK里面是 206 98   ,UTF8里面是230 136 145,UTF16里面应该是98 17

但是实际的值是什么呢?实际的编码值是206 210,既不是GBK,也不是UTF8UTF16的编码,我查了一下其它的编码表,最终发现

206 210GB2312“我”字的编码

 

接着我把数据库客户端编码切换成ZHS16GBK,看看会发生什么

SQL> insert into test values('');

已创建 1 行。

SQL> commit;

提交完成。

SQL> select a,dump(a)  from test;

A                                                                              
--------------------                                                            
DUMP(A)                                                                        
--------------------------------------------------------------------------------

                                                                              
Typ=96 Len=3: 230,136,145

可以发现,数据库在插入时,准确的把""字转换成UTF8的编码,而在显示的时候又转换成了准确的汉字"",

怎么解释上面这个现象呢

 

事实上,通过试验我们可以发现OS的字符集实际是GB2312的,但是由于客户端字符集和服务器端字符集一致,所以在上传数据的时候,认为不存在字符集转换,所以就直接把OS的汉字编码上传上去了,这也是我们看到的库中实际存放的是GB2312“我”字编码 206 210的原因,显示的时候同样的方式,认为数据库服务器与客户端字符集编码一致,不存在字符集转换,于是把206 210发到客户端,到了客户端,就正好原封不动的把206 210显示成为了汉字“我”。这也是造成提示乱码的原因,让GBK的窗口去解析UTF8的编码,从而产生乱码。

 

当客户端字符集是GBK的时候,执行INSERT的时候,ORACLE意识到服务器与客户端字符集不一致,产生一次字符集转换,把“我”字转换成UTF8编码230,136,145存入数据库中,select的时候做反操作,将UTF8转换成GBK编码显示出来。

 

 

下面顺带介绍一下一个经典的乱码问题,“靠”问题,

可能有人见过,就是在一个中文系统中所有的汉字全部显示为“靠”

下面介绍这种问题产生的原因:

服务器端:ZHS16GBK

客户端:WE8ISO8859P1

OS:GBK

假设库里存在汉字“我是从辉”,客户端做了一个select,ORACLE判断服务器客户端字符集不一致,于是做字符集转换,但是西欧字符集里面是没有汉字的,于是他会转换成特殊编码,一个倒问号,编码为”BF”,这样客户端得到的值就是“BF BF BF BF,OSGBK的,它会认为这是两个汉字,“BFBF,”BFBF”,恰巧是汉字“靠”的编码,于是你就会看到最终显示结果“靠靠”!

 

 

  评论这张
 
阅读(55)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017