Oracle817 版本 不同字符集之间的数据库导入 由于业务原因，需要将一英文字符集（American_America.WE8ISO8859P1）的数据库DMP文件导入到一中文字符集（SIMPLIFIED CHINESE_CHINA.ZHS16GBK）的数据库中。由于字符集的不同，需要将中文字符集的数据库环境改变成英文字符集。遇到很多的麻烦，通过在网上查找资料，终于解决了问题。在这个过程中，发现网友们也有同样的问题，为了，让大家在以后能够顺利的完成此类工作，现将把我导入成功的过程写出来，与大家共享。 一、系统环境： 导出环境： 主机：Compaq 小型机 操作系统：Unix 数据库：oracle8.1.7{英文字符集（American_America.WE8ISO8859P1）} 导入环境： 主机：普通Pc 机 主频：PIII750 内存：192M 操作系统：Windows 2000 server 数据库：Oracle8.1.7中文字符集（SIMPLIFIED CHINESE_CHINA.ZHS16GBK） 注：导出过程省略 二、导入过程 1、 将win2000系统中的oracle注册表 [HKEY_LOCAL_MACHINESOFTWAREORACLE]中的[NLS_LANG]键值“SIMPLIFIED CHINESE_CHINA.ZHS16GBK”改成“American_America.WE8ISO8859P1” 2、 用system用户的身份，在Sql-plus 下执行以下语句： update sys.props$ set value$='WE8ISO8859P1' where name='NLS_CHARACTERSET'； update sys.props$ set value$='WE8ISO8859P1' where name='NLS_NCHAR_CHARACTERSET'； commit; 3、 重新启动oracle 4、 开始导入数据库 userid = 用户名/密码@连结串buffer = 60000log = c:dmp.logfile = c:导入数据文件名称.dmpfromuser = 用户名touser = 用户名 这里要注意，要确保导入的表空间和用户已经建立并与导出文件一至，还要确认用户是否拥有dba的权限，否则有可能会影响导入数据的完整。 5、 检查导入效果，在目前环境下，测试数据是否正确，是否有乱码，是否有未成功导入的表和其他触发器、过程和函数等信息。确认导入没有问题后，进入到下一步。6、 将win2000下oracle字符集环境恢复成中文字符集。[HKEY_LOCAL_MACHINESOFTWAREORACLE]中的[NLS_LANG]键值“American_America.WE8ISO8859P1” 改回“SIMPLIFIED CHINESE_CHINA.ZHS16GBK” 7、 用system用户的身份，在Sql-plus 下执行以下语句： update sys.props$ set value$=' ZHS16GBK ' where name='NLS_CHARACTERSET'； update sys.props$ set value$=' ZHS16GBK ' where name='NLS_NCHAR_CHARACTERSET'； commit; 8、 重新启动数据库。 检查你的数据库中的数据，如果没有乱码，而且你的程序能够在这个环境下正常运行，那么恭喜你，你也成功了！！
用编辑方式打开导出的dmp文件，获取2、3字节的内容，如00 01，
先把它转换为10进制数，为1，使用函数NLS_CHARSET_NAME即可获得该字符集：
SQL> select nls_charset_name(1) from dual;
NLS_CHARSET_NAME(1)
-------------------
US7ASCII
可以知道该dmp文件的字符集为US7ASCII，
如果需要把该dmp文件的字符集换成ZHS16GBK，
则需要用NLS_CHARSET_ID获取该字符集的编号：
SQL> select nls_charset_id('zhs16gbk') from dual;
NLS_CHARSET_ID('ZHS16GBK')
--------------------------
852
把852换成16进制数，为354，把2、3字节的00 01换成03 54，
即完成了把该dmp文件字符集从us7ascii到zhs16gbk的转化，
这样，再把该dmp文件导入到zhs16gbk字符集的数据库就可以了。
使用一点点技巧，就可以使导出/导入在不同的字符集的数据库上转换数据。这里需要一个2进制文件编辑工具即可，如uedit32。用编辑方式打开导出的dmp文件，获取2、3字节的内容，如00 01，先把它转换为10进制数，为1，使用函数NLS_CHARSET_NAME即可获得该字符集：(ultraedit 打开几百M到上G的文件很慢，我试了winHex,哪个速度啊，闪电！)
SQL> select nls_charset_name(1) from dual;
NLS_CHARSET_NAME(1)
-------------------
US7ASCII
可以知道该dmp文件的字符集为US7ASCII，如果需要把该dmp文件的字符集换成ZHS16GBK，则需要用NLS_CHARSET_ID获取该字符集的编号：
SQL> select nls_charset_id('zhs16gbk') from dual;
NLS_CHARSET_ID('ZHS16GBK')
--------------------------
852
把852换成16进制数，为354，把2、3字节的00 01换成03 54，即完成了把该dmp文件字符集从us7ascii到zhs16gbk的转化，这样，再把该dmp文件导入到zhs16gbk字符集的数据库就可以了。（注意，十进制数与十六进制之间的转换，想明白其中的道理）SQL> select nls_charset_id('zhs16cgb231280') from dual;NLS_CHARSET_ID('ZHS16CGB231280')
--------------------------------
850字符集 代码（十进制） 对应的dmp文件（2、3字节/二进制）
ZHS16CGB231280 850 03 52
ZHS16GBK 852 03 54
以前一直用oracle8.0.5 ， 安装好 oracle8.1.6 后发现SQL*Plus可以用，SQL*WorkSheet 总出现乱码，改了字符集也不对
---------------------------------------------------------------
解决办法：
在$ORACLE_HOME\sysman\config目录下有一个配置文件名为dbappscfg.properties，找到这样一项，#SQLPLUS_NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
去掉注释符#，同时将其修改为SQLPLUS_NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
对于Windows操作系统，还需要修改一项，在文件中找到# SQLPLUS_SYSTEMROOT=c:\\WINNT40，去掉注释符，将其修改为你所在机器的操作系统主目录。如操作系统的主目录在D盘的Winnt下，则将其修改为 SQLPLUS_SYSTEMROOT=d:\\WINNT。
修改完成后，保存文件，退出编辑。重新连接SQL PLUS Worksheet，OK！
---------------------------------------------------------------
对于Oracle Enterprise Manager中的所有工具，有一个配置文件名为dbappscfg.properties，修改该文件即可解决上述问题。这个文件的位置在$ORACLE_HOME\sysman\config目录下，用任何的文本编辑器打开该文件，在这个文件里面，找到这样一项，
# SQLPLUS_NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1
去掉注释符#，同时将其修改为SQLPLUS_NLS_LANG=AMERICAN_AMERICA.ZHS16GBK。
对于Windows操作系统，还需要修改一项，在文件中找到# SQLPLUS_SYSTEMROOT=c:\\WINNT40，去掉注释符，将其修改为你所在机器的操作系统主目录。如操作系统的主目录在D盘的Winnt下，则将其修改为 SQLPLUS_SYSTEMROOT=d:\\WINNT。
对于后面一项的修改只对Windows操作系统进行，对UNIX操作系统则不需要。如果在Windows操作系统中不修改该项，在Oracle Enterprise Manager中，连接系统时，会提示如下的错误：
ORA-12560 TNS:protocol adapter error
或者
ORA-12545 Connect failed because target host or object does not exist
修改完成后，保存文件，退出编辑。重新连接SQL PLUS Worksheet，字符集乱码问题得到解决,显示正确的简体中文字符集。
==============================UTF8 characters occupy up to 3 bytes. AL32UTF8 (Oracle9i only) characters occupy up to 4 bytes. 4 bytes are only for characters allocated in Unicode 3.1, not yet supported by Oracle, and user-defined characters from Private Use area above U+0000FFFF. Four bytes they are not yet practically used. Chinese and Japanese characters occupy 3 bytes in UTF8. Due to Han unification in Unicode there is no distinction between Chinese and Japanese ideographs, if they are the same character (like the Chinese character for "center", appearing in the word "China", and used in Japanese as well). You have to distinguish between languages on the application level (e.g. extra column).