client exp导出时的nls_lang值如下:
NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
--====================================
C:>exp test/test file=c:tempa.dmp tables=t
Export: Release 10.2.0.1.0 - Production on 星期四 3月 10 09:46:20 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集
即将导出指定的表通过常规路径...
. . 正在导出表 T导出了 0 行
成功终止导出, 没有出现警告。
C:>exp test/test file=c:tempa.dmp tables=t
Export: Release 10.2.0.1.0 - Production on 星期四 3月 10 09:47:06 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
连接到: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集
即将导出指定的表通过常规路径...
. . 正在导出表 T导出了 2 行
成功终止导出, 没有出现警告。
C:>
--======================================
--通过ultraedit打开a.dmp文件:
发现第2个和第3个字节是:03 54
按照网上流传的一个说法(之所以这么说,因为自己么有在doc中看到过,汗)这2个字节代表就是exp时client端nls_lang中的client字符集
--==========================
SQL> select to_number('0354','xxxx') from dual;
TO_NUMBER('0354','XXXX')
------------------------
852
SQL> select nls_charset_name(852) from dual;
NLS_CHAR
--------
ZHS16GBK
SQL> select nls_charset_id('ZHS16GBK') from dual;
NLS_CHARSET_ID('ZHS16GBK')
--------------------------
852
SQL>
SQL> select nls_charset_name(936) from dual;
N
-
SQL>
--这里有个小小的疑问,windows下我们看到的代码936对应的是简体中文 GBK,貌似和
oracle中的852不一致,肯定指的都是简体中文,莫非2个地方的id不同?另外貌似没有oracle视图记录charset name和id的对应关系...?
--=======================
知道了exp导出时client端的字符集,那么我们在导入时也设置成这样的字符集(当然最终
都得和db server的字符集保持一致),导入之后才有可能不至于产生乱码。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/19602/viewspace-1047080/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/19602/viewspace-1047080/