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工具來檢查兩個字符集之間是否可以轉換。