探索Oracle之 EXP/IMP过程中的字符集问题

1. 问题描述：

       数据库之间的数据迁移是一个很常见的作业，EXP/IMP工具是一个常用的数据迁移及转化工具，因其导出文件具有平台无关性，所以在跨平台迁移中，最为常用。但在实际操作过程中，涉及到源数据库，客户端，目标数据库三方面的字符集问题。操作人员对三者之间的字符集转换过程不了解，而冒然使用EXP/IMP命令，往往在迁移过程中报错终止，或是在没有报错的情况下成功导入，但其背后却存在隐患，在查询时经常显示乱码。

2.解决方法

       2.1 源端数据库（1）→EXP客户端（2）→IMP客户端（3）→目标数据库（4），数据在迁移过程中要经历如上的4个点，数据在流动过程中（如上的3个箭头）需要依次比较箭头两端的字符集，如果相同则不转换，如果不同则进行转换。如果相邻的两个点之间设置的字符集均不相同，则需要转换3次。

       根据上述理论分析，最好的设置方式是，因为（1）（4）数据库的字符集是固定的，则设置客户端的字符集（2）（3）均与（1）相同，这样最多只在(3)→（4）的过程中发生一次字符集的转换。但是前提是（4）的字符集必须是（1）的的字符集的超集。客户端字符集是通过环境变量NLS_LANG来设置。

Linux: export NLS_LANG=SIMPLIFIEDCHINESE_CHINA.ZHS16GBK
Windows: set NLS_LANG=SIMPLIFIEDCHINESE_CHINA.ZHS16GBK

03 03 54 45 58 50 4F 52 54 3A

其中，03 54是16进制的数字，代表了一种字符集。将其转换为10进制为：

SQL> select to_number('0354','xxxx') from dual;
TO_NUMBER('0354','XXXX')
------------------------
                     852
查询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

       2.2 ORACLE在10g以后的版本中提供了新的迁移工具EXPDP/IMPDP，此工具无需设置客户端字符集，而是由ORACLE自动去识别并完全字符集的转换。这是因为EXPDP/IMPDP并不是完整意义上的客户端，它和EXP/IMP/sqlplus并不完全一样。它只是向oracle传输了一个命令，oracle在内部生成一个任务，文件只能导出在服务器上，而不能像exp/imp一样将文件导出到远程端。但前提依然是，目标数据库的字符集应是源数据库字符集的超集。

      其实，在使用exp/imp,expdp/impdp时，并不一定要严格要求目的数据库是源数据库的超集。问题的关键之处在于源端的字符能在目的端找到对应的字符。在不同字符集的数据库传输之前，我们最好通过oracle提供的csscan工具来检查两个字符集之间是否可以转换。