Oracle字符集研究幻灯片.pptVIP

字符集转换 如果源字符集和目标字符集一致，则保证全部客户端一致。 如果源和目标不一致，则保证导入和导出客户端一致，且与源或者目标保持一致。 字符集转换 为了避免在数据库迁移过程中由于字符集不同导致的数据损失，oracle提供了字符集扫描工具（character set scanner），通过这个工具我们可以测试在数据迁移过程中由于字符集转换可能带来的问题，然后根据测试结果，确定数据迁移过程中最佳字符集解决方案。 字符集转换 用sysdba用户登陆 执行$ORACLE_HOME\rdbms\admin\csminst.sql 然后退回到命令提示符 执行 csscan FULL=Y FROMCHAR=WE8ISO8859P1 TOCHAR=UTF8 log=check.log capture=y array=1000000 process=2 执行完毕以后查看log文件，可以知道那些转换会失败 字符集转换 字符集转换 字符集转换 OS字符集 OS字符集以及OS字符集在字符集转换中起的作用。 OS字符集 查看OS字符集 OS字符集 DEMO: 环境:OS:WINXP SP2 中文版ORACLE 服务器和客户端在一台机器上服务器字符集:AL32UTF8 国家字符集 AL16UTF16客户端字符集: AL32UTF8 以下是在SQLPLUS里面的操作： OS字符集 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? ?? ?? OS字符集 可以看到,服务器端和客户端都是UTF8但是显示出来的提示全部是乱码, 在看一下汉字我字的编码, 查了一下编码表,在ZHS16GBK里面是 206 98? ?,在UTF8里面是230 136 145,在UTF16里面应该是98 17 但是实际的值是什么呢？实际的编码值是206 210,既不是GBK,也不是UTF8和UTF16的编码，查了一下其它的编码表，最终发现 206 210是GB2312“我”字的编码 OS字符集 接着把数据库客户端编码切换成ZHS16GBK，看看会发生什么 SQL insert into test values(‘我’);已创建 1 行。SQL select a,dump(a) ?from test;A? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?DUMP(A)? 我? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ?Typ=96 Len=3: 230,136,145 OS字符集 可以发现,数据库在插入时,准确的把我字转换成UTF8的编码,而在显示的时候又转换成了准确的汉字我, 怎么解释上面这个现象呢？? OS字符集 通过试验我们可以发现OS的字符集实际是GB2312的，但是由于客户端字符集和服务器端字符集一致，所以在上传数据的时候，认为不存在字符集转换，所以就直接把OS的汉字编码上传上去了，这也是我们看到的库中实际存放的是GB2312“我”字编码 206 210的原因，显示的时候同样的方式，认为数据库服务器与客户端字符集编码一致，不存在字符集转换，于是把206 210发到客户端，到了客户端，就正好原封不动的把206 210显示成为了汉字“我”。这也是造成提示乱码的原因，让GBK的窗口去解析UTF8的编码，从而产生乱码