我们知道在导出文件中，记录着导出使用的字符集id,通过查看导出文件头的第2、3个字节，我们可以找到16进制表示的字符集ID,在Windows上，
我们可以使用UltraEdit等工具打开dmp文件，查看其导出字符集::
在Unix上我们可以通过以下命令来查看:
Oracle提供标准函数，对字符集名称及ID进行转换:
对应上面的图中第2、3字节，我们知道该导出文件字符集为ZHS16GBk.
查询数据库中有效的字符集可以使用以下脚本:
输出样例如下:
在很多时候，当我们进行导入操作的时候，已经离开了源数据库，这时如果目标数据库的字符集和导出文件不一致，很多时候就需要进行特殊处理，
以下介绍几种方法，主要以US7ASCII和ZHS16GBK为例
1． 源数据库字符集为US7ASCII，导出文件字符集为US7ASCII或ZHS16GBK，目标数据库字符集为ZHS16GBK
在Oracle92中，我们发现对于这种情况，不论怎样处理，这个导出文件都无法正确导入到Oracle9i数据库中，这可能是因为Oracle9i的编码方案发生了较大改变。
以下是我们所做的简单测试，其中导出文件命名规则为:
S-Server ，后跟Server字符集
C-client , 后跟导出操作时客户端字符集
导入时客户端字符集设置在命令行完成，限于篇幅，我们省略了部分测试过程。
对于Oracle9iR2,我们的测试结果是US7ASCII字符集，不管怎样转换，都无法正确导入ZHS16GBK字符集的数据库中。
在进行导入操作时，如果字符不能正常转换，Oracle数据库会自动用一个”?”代替，也就是编码63。
对于这种情况，我们可以通过使用Oracle8i的导出工具，设置导出字符集为US7ASCII，导出后修改第二、三字符，修改 0001 为
0354,这样就可以将US7ASCII字符集的数据正确导入到ZHS16GBK的数据库中。
修改导出文件:
导入修改后的导出文件:
2． 使用create database的方法
如果导出文件使用的字符集是US7ASCII，目标数据库的字符集是ZHS16GBK,我们可以使用create database的方法来修改，具体如下:
我们看到，当发出create database character set us7ascii；命令时，数据库v$nls_parameters中的字符集设置随之更改，该参数影响导入进程，
更改后可以正确导入数据，重起数据库后，该设置恢复。
提示:v$nls_paraemters来源于x$nls_parameters,该动态性能视图影响导入操作；而nls_database_parameters来源于props$数据表，影响数据存储。
3． Oracle提供的字符扫描工具csscan
我们说以上的方法只是应该在不得已的情况下使用，其本质是欺骗数据库，强制导入数据，可能损失元数据。
如果要确保数据的完整性，应该使用csscan扫描数据库，找出所有不兼容的字符，然后通过编写相应的脚本及代码，在转换之后进行更新，确保数据的正确性。
我们简单看一下csscan的使用。
要使用csscan之前，需要以sys用户身份创建相应数据字典对象:
这个脚本创建相应用户(csmig)及数据字典对象，扫描信息会记录在相应的数据字典表里。
我们可以在命令行调用这个工具对数据库进行扫描:
然后我们可以检查输出的日志来查看数据库扫描情况:
不能转换的数据将会被记录下来，我们可以根据这些信息在转换之后，对数据进行相应的更新，确保转换无误。
