oracle character set2
实验结果分析三
当客户端字符集设置为ZHS16GBK后向数据库插入“东北”,Oracle检查发现数据库设置的字符集为US7ASCII与客户端不一致,需要进行转换,但字符集ZHS16GBK中的“东北”两字在US7ASCII中没有对应的字符,所以Oracle用统一的“替换字符”插入数据库,在这里为“?”,编码为63(00111111),这时,输入的信息实际上已经丢失,不管字符集设置如何改变(如下面引用的实验结果),第二行SELECT出来的结果也都是两个“?”号(注意是2个,而不是4个)。
需要指出的是,通过“update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';”来修改数据库字符集是非常规作法,很可能引起问题,在这里只是原文引用网友的实验结果。
由于此时数据库与客户端的字符集设置均为ZHS16GBK,所以不会发生字符集的转换,第一行与第三行数据显示正确,而第二行由于存储的数据就是63(00111111),所以显示的是“?”号。
将客户端字符集设置改为US7ASCII后进行SELECT,Oracle检查发现数据库设置的字符集为ZHS16GBK,数据需要进行字符集转换,而第一行与第三行的汉字“东”与“北”在客户端字符集US7ASCII中没有对应字符,所以转换为“替换字符”(“?”),而第二行数据在数据库中存的本来就是两个“?”号,所以虽然在客户端显示的三行都是两个“?”号,但在数据库中存储的内容却是不同的。
实验结果分析五
在客户端字符集设置为US7ASCII时,向字符集为ZHS16GBK的数据库中插入“东北”,需要进行字符转换,“东北”的ZHS16GBK编码为182(10110110)、171(10101011)与177(10110001)、177(10110001),由于US7ASCII为7bit编码,Oracle将这两个汉字当作四个字符,并忽略各字节的最高位,从而存入数据库的编码就变成了54(00110110)、43(00101011)与49(00110001)、49(00110001),也就是“6+11”,原始信息被改变了。这时,将客户端字符集设置为ZHS16GBK再进行SELECT,数据库中的信息不需要改变传到客户端,第一、三行由于存入的信息没有改变能显示“东北”,而第二、四行由于插入数据时信息改变,所以不能显示原有信息了。
quote:
最初由 tellin 发布
用ZHS16GBK插入数据
SQL> INSERT INTO TEST VALUES('东北');
1 row created.
SQL> SELECT * FROM TEST;
R1
--------------------
6+11
??
SQL> EXIT
当客户端字符集设置为ZHS16GBK后向数据库插入“东北”,Oracle检查发现数据库设置的字符集为US7ASCII与客户端不一致,需要进行转换,但字符集ZHS16GBK中的“东北”两字在US7ASCII中没有对应的字符,所以Oracle用统一的“替换字符”插入数据库,在这里为“?”,编码为63(00111111),这时,输入的信息实际上已经丢失,不管字符集设置如何改变(如下面引用的实验结果),第二行SELECT出来的结果也都是两个“?”号(注意是2个,而不是4个)。
quote:
更改客户端字符集为US7ASCII
D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
D:\>SQLPLUS "/ AS SYSDBA"
无法显示用ZHS16GBK插入的字符集,但可以显示用US7ASCII插入的字符集
SQL> SELECT * FROM TEST;
R1
----------
东北
??
更改服务器字符集为ZHS16GBK
SQL> update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';
1 row updated.
SQL> COMMIT;
更改客户端字符集为ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
D:\>SQLPLUS "/ AS SYSDBA"
可以显示以前US7ASCII的字符集,但无法显示用ZHS16GBK插入的数据,说明用ZHS16GBK插入的数据为乱码。
SQL> SELECT * FROM TEST;
R1
--------------------
东北
??
需要指出的是,通过“update props$ set value$='ZHS16GBK' WHERE NAME='NLS_CHARACTERSET';”来修改数据库字符集是非常规作法,很可能引起问题,在这里只是原文引用网友的实验结果。
实验结果分析四
quote:
SQL> INSERT INTO TEST VALUES('东北');
1 row created.
SQL> SELECT * FROM TEST;
R1
--------------------
东北
??
东北
SQL> EXIT
由于此时数据库与客户端的字符集设置均为ZHS16GBK,所以不会发生字符集的转换,第一行与第三行数据显示正确,而第二行由于存储的数据就是63(00111111),所以显示的是“?”号。
quote:
更改客户端字符集为US7ASCII
D:\>SET NLS_LANG=AMERICAN_AMERICA.US7ASCII
D:\>SQLPLUS "/ AS SYSDBA"
无法显示数据
SQL> SELECT * FROM TEST;
R1
----------
??
??
??
疑问2:第一行数据是用US7ASCII环境插入的,为何无法正常显示?
将客户端字符集设置改为US7ASCII后进行SELECT,Oracle检查发现数据库设置的字符集为ZHS16GBK,数据需要进行字符集转换,而第一行与第三行的汉字“东”与“北”在客户端字符集US7ASCII中没有对应字符,所以转换为“替换字符”(“?”),而第二行数据在数据库中存的本来就是两个“?”号,所以虽然在客户端显示的三行都是两个“?”号,但在数据库中存储的内容却是不同的。
实验结果分析五
quote:
SQL> INSERT INTO TEST VALUES('东北');
1 row created.
SQL> EXIT
更改客户端字符集为ZHS16GBK
D:\>SET NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
D:\>SQLPLUS "/ AS SYSDBA"
无法显示用US7ASCII插入的字符集,但可以显示用ZHS16GBK插入的字符集
SQL> SELECT * FROM TEST;
R1
--------------------
东北
??
东北
6+11
SQL>
疑问3:US7ASCII为ZHS16GBK的子集,为何在US7ASCII环境下插入的数据无法显示? [/B]
在客户端字符集设置为US7ASCII时,向字符集为ZHS16GBK的数据库中插入“东北”,需要进行字符转换,“东北”的ZHS16GBK编码为182(10110110)、171(10101011)与177(10110001)、177(10110001),由于US7ASCII为7bit编码,Oracle将这两个汉字当作四个字符,并忽略各字节的最高位,从而存入数据库的编码就变成了54(00110110)、43(00101011)与49(00110001)、49(00110001),也就是“6+11”,原始信息被改变了。这时,将客户端字符集设置为ZHS16GBK再进行SELECT,数据库中的信息不需要改变传到客户端,第一、三行由于存入的信息没有改变能显示“东北”,而第二、四行由于插入数据时信息改变,所以不能显示原有信息了。
0
收藏
推荐专栏更多
猜你喜欢
我的友情链接
oralce dump logfile
oracle表分区详解
Java集合框架List,Map,Set等全面介绍
Oracle用户、权限、角色管理
Oracle的AWR报告分析
ORACLE EXP/IMP的使用详解
rhel7.4安装oracle 11G 11.2.0.4.0 RAC
Java线程:线程的调度-休眠
我们不得不面对的中年职场危机
Oracle group by 用法实例详解
ORACLE11g系列教程之二:ORACLE11g 的安装
PostgreSQL的B-tree索引
PostgreSQL pg_rewind实例--could not find previous WA
redis geo 地理位置系应用战案例
PostgreSQL逻辑备份pg_dump使用及其原理解析
PostgreSQL如何删除不使用的xlog文件
PostgreSQL pg_ctl start超时分析
Greenplum -- segment 死机后恢复
postgresql 主备及切换-恢复方案
扫一扫,领取大礼包
转载于:https://blog.51cto.com/airlgc/29118
Ctrl+Enter 发布
发布
取消