oracle数据库字符集

时间:2021-02-21 06:38:04

我用的数据库是oracle11.2.0.4,数据库字符集是al32utf8。

客户端就是同一台机器的windows 7

用window7的客户端连接

查看windows客户端中文字符



虚拟机   192.168.10.5    数据库是test1    数据库字符集是al32utf8。


C:\Users\Administrator>echo %NLS_LANG%             -------查看客户端字符命令

SIMPLIFIED CHINESE_CHINA.AL32UTF8  


set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK       -----设置客户端字符命令



数据库是test1   ,数据库字符集是al32utf8。



--session 1 设置客户端字符集为 zhs16gbk(修改注册表nls_lang项的characterset 为zhs16gbk) 向表中插入两个中文字符。



C:\Users\Administrator>echo %NLS_LANG%

SIMPLIFIED CHINESE_CHINA.ZHS16GBK


C:\Users\Administrator>sqlplus sys/oracle@test1 as sysdba;      


SQL> create table test(col1 number(1),col2 varchar2(10));

   SQL> insert into test values(1,'中国'); --1为session 1的标记

        1 row created.

        SQL> commit;

        Commit complete.  

        

SQL> create table test(col1 number(1),col2 varchar2(10));


表已创建。


SQL>  insert into test values(1,'中国');


已创建 1 行。


SQL>        

        

     

     

        

-session 2 设置客户端字符集 al32utf8(修改注册表nls_lang项的characterset 为al32utf8),与数据库字符集相同。 向表中插入两个和session 1相同的中文字符。        

  

C:\Users\Administrator>echo %NLS_LANG%

SIMPLIFIED CHINESE_CHINA.AL32UTF8


C:\Users\Administrator>sqlplus sys/oracle@test1 as sysdba;


SQL*Plus: Release 11.2.0.1.0 Production on ����涓 11�?28 10:35:33 2016


Copyright (c) 1982, 2010, Oracle.  All rights reserved.



杩��ュ�?

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options


SQL>





  SQL> insert into test values(2,'中国'); --2为session 2的标记

        1 row created.

        SQL> commit;

        Commit complete.


--session 1


       SQL> select * from test;


      COL1 COL2

---------- --------------------

         1 中国

         2 ???    

                                                                  

--session 2

     SQL> select * from test;


      COL1 COL2

---------- ----------

         1 涓��

         2 中国


SQL>

                 

 

 

 从session 1和session 2的结果中可以看到,相同的字符(注意,我指的是我们看到的,显示为相同的字符 中国),在不同的字符集输入环境(客户端环境变量)下,显示成了乱码。    

   在zhs16gbk字符集的客户端,我们看到了utf8字符集客户端输入的相同的中文变成了乱码-->col1=2的col2字段

SQL> select * from test;


      COL1 COL2

---------- --------------------

         1 中国

         2 ???

   

   

   

  在utf8字符集客户端,我们看到zhs16gbk字符集的客户端输入的中文变成了另外的字符  -->col1=1的col2字段   

  

  SQL> select * from test;


      COL1 COL2

---------- ----------

         1 涓��      -----三个字符

         2 中国

         

         

 

 

SQL> select col1,dump(col2,1016) from test;


      COL1

----------

DUMP(COL2,1016)

-------------------------------------------------------------


         1

Typ=1 Len=6 CharacterSet=AL32UTF8: e4,b8,ad,e5,9b,bd


         2

Typ=1 Len=4 CharacterSet=AL32UTF8: d6,d0,b9,fa        



不同的客户端输入的中文字符,在数据库中存储的字符编码不一致。



session 1 输入的字符"中国" 在数据库中存储的字符编码为”e4,b8,ad,e5,9b,bd".

session 2 输入的字符"中国" 在数据库中存储的字符编码为”d6,d0,b9,fa".


会话一、

中国-------e4,b8,ad,e5,9b,bd     数据库发现客户端16gbk跟数据库端的utf8字符不一致    做了字符转换  首先将客户端 中国 16gbk的(双字节)编码转成utf8(三字节编码) 然后存储下来。 


会话二、

中国-------d6,d0,b9,fa           数据库发现客户端utf8跟数据库端的utf8字符一致      欺骗了数据库端,不做字符转换,直接以16gbk(双字节)的字符编码存储到数据库(utf8数据库编码为三字节)中。



              

session 1 输入的字符"中国" 在数据库中存储的字符编码为”e4,b8,ad,e5,9b,bd"

session 2 输入的字符"中国" 在数据库中存储的字符编码为”d6,d0,b9,fa"



数据库看到客户端的字符集和数据库的字符集一致,此时oracle将不会再对字符作转换,因为它认为两边的字符编码是一致的。而此时,

我们欺骗了数据库,尽管我们将客户端字符集设置为和数据库一致,但是其实我们使用的是zhs16gbk字符集编码(因为此时windows使用的就是这个字符编码),

对于字符"中国",zhs16gbk字符集里对应的编码为d6,d0,b9,fa。此时,oracle不加理会的直接将这个编码保存到了数据库中。




客户端的字符集的作用就是告知数据库端传输的字符编码,跟数据库端的字符集一致就直接存储,不一致就字符转换。




查询是存储的字符转换的逆过程。

session1查询

SQL> select * from test;


      COL1 COL2

---------- --------------------

         1 中国

         2 ???

         



当session 1开始查询时,oracle从表中取出这两个字符,并按照字符集al32utf8和字符集zhs16gbk的编码映射表,将它的转换成zhs16gbk字符编码,对于编码“e4,b8,ad,e5,9b,bd”,

它对应的zhs16gbk的字符编码为"d6,d0,b9,fa",这个编码对应的字符为”中国“,所以我们看到了这个字符正常显示出来了,

而对于字符集存储的al32utf8字符编码“d6,d0,b9,fa”,

由于我们用于显示字符的windows环境使用的是zhs16gbk字符集,而在zhs16gbk字符集里面并没有对应这个编码的字符或者属于无法显示的符号,utf8---16gbk 转换找不到

于是使用了"?"这样的字符来替换,这就是为什么我们看到session 2输入的字符变成了这样的乱码。






session2查询

SQL> select * from test;


      COL1 COL2

---------- ----------

         1 涓��

         2 中国

SQL>



当session 2开始查询时,oracle从表中取出这两个字符,由于客户端(nls_lang)和数据库的字符集设置一致,oracle将忽略字符的转换问题,

于是直接将数据库中存储的字符返回给客户端。对于编码为"d6,d0,b9,fa"的字符,返回给客户端,而客户端显示所用的字符集正好是zhs16gbk,在这个字符集里,########(虽然客户端变成ut8,但是转换回来还是以16gbk的,windows依然是16gbk。)

这个编码对应的是"中国"两个字符,所以就正常显示出来了。

对于字符编码“e4,b8,ad,e5,9b,bd”,返回到客户端後,因为在zhs16gbk里采用的是双字节存储字符方式,(虽然客户端变成utf8,但是转换回来还是以16gbk的,windows依然是16gbk。)

所以这6字节对应了zhs16gbk字符集的3个字符,也就是我们看到的"涓��"。






导入导出 exp   imp 客户端对字符的影响实验

 

 


创建两个库

test1 源数据库 字符集-----------   SIMPLIFIED CHINESE_CHINA.AL32UTF8     


test2 目标数据库 字符集-----------   SIMPLIFIED CHINESE_CHINA.16gbk


创建用户jiang/oracle  建立test表




oracle@linux5:/oracle>export NLS_LANG="SIMPLIFIED CHINESE_CHINA.ZHS16GBK" ###########环境变量


SQL>  select col1,dump(col2,1016) from test;


      COL1

----------

DUMP(COL2,1016)

--------------------------------------------------------------------------------

         2

Typ=1 Len=4 CharacterSet=AL32UTF8: d6,d0,b9,fa


         1

Typ=1 Len=6 CharacterSet=AL32UTF8: e4,b8,ad,e5,9b,bd




Export: Release 11.2.0.4.0 - Production on 星期一 11月 28 17:05:50 2016


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.



连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

服务器使用 AL32UTF8 字符集 (可能的字符集转换)

. 正在导出 pre-schema 过程对象和操作

. 正在导出用户 JIANG 的外部函数库名

. 导出 PUBLIC 类型同义词

. 正在导出专用类型同义词

. 正在导出用户 JIANG 的对象类型定义

即将导出 JIANG 的对象...

. 正在导出数据库链接

. 正在导出序号

. 正在导出簇定义

. 即将导出 JIANG 的表通过常规路径...

. . 正在导出表                            TEST导出了           2 行

. 正在导出同义词

. 正在导出视图

. 正在导出存储过程

. 正在导出运算符

. 正在导出引用完整性约束条件

. 正在导出触发器

. 正在导出索引类型

. 正在导出位图, 功能性索引和可扩展索引

. 正在导出后期表活动

. 正在导出实体化视图

. 正在导出快照日志

. 正在导出作业队列

. 正在导出刷新组和子组

. 正在导出维

. 正在导出 post-schema 过程对象和操作

. 正在导出统计信息

成功终止导出, 没有出现警告。







导入到test2 ,目标数据库字符集为16gbk


oracle@linux5:/oracle>imp jiang/oracle@test2 fromuser=jiang touser=jiang file=/backup/test1.dmp log=/backup/testimp.log


Import: Release 11.2.0.4.0 - Production on 星期一 11月 28 17:28:32 2016


Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.



连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options


经由常规路径由 EXPORT:V11.02.00 创建的导出文件

已经完成 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集中的导入

. . 正在导入表                          "TEST"导入了           2 行

成功终止导入, 没有出现警告。

oracle@linux5:/oracle>



SQL> select * from test;


      COL1 COL2

---------- ----------

         2 ???

         1 中国

         

 

 SQL>  select col1,dump(col2,1016) from test;


      COL1

----------

DUMP(COL2,1016)

--------------------------------------------------------------------------------

         2

Typ=1 Len=4 CharacterSet=ZHS16GBK: a3,bf,3f,3f        


         1

Typ=1 Len=4 CharacterSet=ZHS16GBK: d6,d0,b9,fa          ------------2个字节一个汉字, 16gbk编码存储 数据库做了数字编码转换工作。



SQL>         







参考   http://blog.csdn.net/wuweilong/article/details/39694531

源端数据库test1 (1)字符集为utf8 →EXP客户端(2)→IMP客户端(3)→目标数据库(4) test2字符集为16gbk,

数据在迁移过程中要经历如上的4个点,数据在流动过程中(如上的3个箭头)需要依次比较箭头两端的字符集,

如果相同则不转换,如果不同则进行转换。如果相邻的两个点之间设置的字符集均不相同,则需要转换3次。

最好的设置方式是,因为(1)(4)数据库的字符集是固定的,则设置客户端的字符集(2)(3)均与(1)相同,

这样最多只在(3)→(4)的过程中发生一次字符集的转换。但是前提是(4)的字符集必须是(1)的的字符集的超集。客户端字符集是通过环境变量NLS_LANG来设置。




写入数据----字符转换过程


数据库端通过简单的判断跟 客户端环境变量的字符集  是否一致进行字符转换   一致则不转换,直接存储到数据库中,不一致则字符转换。

客户端的字符集的作用就是告知数据库端传输的字符编码


数据库看到客户端的字符集和数据库的字符集一致,此时oracle将不会再对字符作转换,因为它认为两边的字符编码是一致的。而此时,

我们欺骗了数据库,尽管我们将客户端字符集设置为和数据库一致,但是其实我们使用的windows7是zhs16gbk字符集编码(因为此时windows使用的就是这个字符编码),

对于字符"中国",zhs16gbk字符集里对应的编码为d6,d0,b9,fa。此时,oracle不加理会的直接将这个编码保存到了数据库中。




查找数据----字符转换过程(win7  16gbk一定)


当session 1开始查询时,oracle从表中取出这两个字符,并按照字符集al32utf8和字符集zhs16gbk的编码映射表,将它的转换成zhs16gbk字符编码,对于编码“e4,b8,ad,e5,9b,bd”,

它对应的zhs16gbk的字符编码为"d6,d0,b9,fa",这个编码对应的字符为”中国“,所以我们看到了这个字符正常显示出来了,3---2


而对于字符集存储的al32utf8字符编码“d6,d0,b9,fa”,

由于我们用于显示字符的windows环境使用的是zhs16gbk字符集,而在zhs16gbk字符集里面并没有对应这个编码的字符或者属于无法显示的符号,utf8---16gbk 转换找不到

于是使用了"?"这样的字符来替换,这就是为什么我们看到session 2输入的字符变成了这样的乱码。