编辑手记：很多人在进行数据库导入导出操作的时候会遇到字符集的问题，今日拣选了 《循序渐进Oracle》一书中的相关章节，希望对初学Oracle的朋友有所帮助。
在传统的EXP导出文件中，记录着导出使用的字符集id，通过查看导出文件头的第2、3个字节，我们可以找到十六进制表示的字符集ID，在Windows上，可以使用UltraEdit等工具打开dmp文件，查看其导出字符集，如图所示：
在UNIX环境上，可以通过以下命令来查看（以下范例来自Solaris平台）：
cat expdat.dmp | od -x | head
需要注意的是，在不同平台，以上命令的输出可能有所不同，比如在Linux平台：
[oracle@jumper oracle]$ cat a.dmp |od -x |head -2 0000000 0303 4554 5058524f3a54 3156 2e30 3230 0000020 302e0a31 4544 4759454c520a41544c42
这是由于Solaris和Linux的字节序是不同的，Solaris是Big-Endians，Linux是Little-Endians，所以Linux上的输出通过交换可以得到：
0303 5445 58504f52 ….
字符集和Solaris上是一致的，所以也可以通过od的参数设置显示格式：
[oracle@jumper oracle]$ cat a.dmp|od -t x1|head -2 0000000 03 03 54 45 58 504f52 543a56 31 30 2e 30 32 0000020 2e 30 310a44 45 59 474c450a52 54 41 424c
Oracle提供标准函数，对字符集名称及ID进行转换：
SQL> selectnls_charset_id('ZHS16GBK') from dual; NLS_CHARSET_ID('ZHS16GBK') -------- 852 SQL> select nls_charset_name(852) from dual; NLS_CHAR -------- ZHS16GBK
十进制转换十六进制，即可获得字符集的编码:
SQL> select to_char('852','xxxx') from dual; TO_CH ----- 354
对应前两张图 第2、3字节，就知道该导出文件字符集为ZHS16GBk。查询数据库中有效的字符集可以使用以下脚本：
col nls_charset_id for 9999 col nls_charset_name for a30 col hex_id for a20 select nls_charset_id(value) nls_charset_id, value nls_charset_name,to_char(nls_charset_id(value), 'xxxx') hex_id from v$nls_valid_values where parameter = 'CHARACTERSET' order by nls_charset_id(value)；
输出样例如下：
而对于Oracle 10g的expdp导出文件，一切则要简单得多，在expdp的导出文件开始部分，Oracle以XML格式记录了数据的字符集信息，以下是一个单表导出文件的头信息。
在文件开始部分就记录了数据库的字符集、国家字符集及时区等信息，在表字段的属性部分也记录了字符集ID：
对于传统的DMP导出文件，在很多时候，当进行导入操作时，已经离开了源数据库，这时如果目标数据库的字符集和导出文件不一致，多半就需要进行特殊处理进行转换。最常见的转换发生在从US7ASCII到ZHS16GBK之间。
由于很多数据库最初以US7ASCII字符集存储中文，单纯通过导出导入是无法完成字符集转换的。对于这种情况，可以通过设置导出字符集为US7ASCII，原样导出数据；导出后修改导出文件的第二、三字符，修改0001为0354，这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中。
如图所示是一个测试例子，我们可以通过UltraEdit等工具的二进制编辑模式修改导出文件：
修改完成之后，可以导入修改后的DMP文件：
E:\nls2>set NLS_LANG=AMERICAN_AMERICA.ZHS16GBK E:\nls2>imp eygle/eygle file=Sus7ascii-Cus7ascii-exp817.dmp fromuser=eygle touser=eygle tables=test Export file created by EXPORT:V08.01.07via conventional path import done in ZHS16GBK character set and AL16UTF16 NCHAR character set export server uses UTF8 NCHAR character set (possible ncharset conversion) . . importing table "TEST" 2 rows imported Import terminated successfully without warnings.
通过这种方式，最终中文可以被正常导入ZSH16GBK的数据库：
另外一种可以尝试的方法是使用create database命令。如果导出文件使用的字符集是US7ASCII，目标数据库的字符集是ZHS16GBK，就可以使用create database的方法来修改，具体操作如下：
然后可以导入数据：
E:\nls2>set nls_lang=AMERICAN_AMERICA.US7ASCII E:\nls2>imp eygle/eygle file=Sus7ascii-Cus7ascii.dmp fromuser=eygle touser=eygle Export file created by EXPORT:V09.02.00via conventional path import done in US7ASCII character set and AL16UTF16 NCHAR character set import server uses ZHS16GBK character set (possible charset conversion) . . importing table "TEST" 2 rows imported Import terminated successfully without warnings.
查询导入数据：
E:\nls2>sqlplus eygle/eygle SQL> select * from test; NAME ---------- 测试 test
当发出“create database character set us7ascii；”命令时，数据库v$nls_parameters中的字符集设置随之更改，该参数影响导入进程，更改后可以正确导入数据，重起数据库后，该设置恢复。
提示：v$nls_paraemters来源于x$nls_parameters，该动态性能视图影响导入操作；而nls_database_parameters来源于props$数据表，影响数据存储。以上的方法只应该在不得已的情况下使用，其本质是欺骗数据库，强制导入数据，但是可能会损失元数据。