一般来说，oracle数据导出spool方式，中文出现乱码，这情况是因为数据库服务器和客户端字符集不匹配，执行sqlplus的机器就是客户端，服务器和客户端也可能是一台机器，执行sqlplus之前要先设置客户端的字符集，在linux上：export NLS_LANG=.......
为永康等地区用户提供了全套网页设计制作服务，及永康网站建设行业解决方案。主营业务为网站设计制作、成都做网站、永康网站设计，以传统方式定制建设网站，并提供域名空间备案等一条龙服务，秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求，就会得到认可，从而选择与我们长期合作。这样，我们也可以走得更远！
在windows上set NLS_LANG查询数据库字符集：select property_value from database_properties where property_name like 'NLS_CHAR%';
1、比如查询结果是：ZHS16GBK
那你在sqlplus之前要设置：export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
然后再登录sqlplus用spool生成数据
检查下你导出时候的环境变量，导入时的环境变量
2、比如导出时NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
导入时NLS_LANG没有设置，或者设置为其他字符集，则导入的库内汉字就有可能变成乱码。
解决方法，连接数据库的时候设置正确字符集即可。
1. 服务器指定字符集与客户字符集不同，而与加载数据字符集一致。
解决方法：对于这种情况，只需要设置客户端字符集与服务器端字符集一致就可以了，具体操作如下：
* 查看当前字符集：
SQL select * from sys.props$
2 WHERE NAME=‘NLS_CHARACTERSET’;
NAME value$
NLS_CHARACTERSET ZHS16GBK
可以看出，现在服务器端Oracle数据库的字符集为‘ZHS16GBK’
* 根据服务器的字符集在客户端作相应的配置或者安装Oracle的客户端软件时指定：
如果还没安装客户端，那么在安装客户端时，指定与服务器相吻合的字符集即可；如果已经安装好了客户端，并且客户端为 sql*net 2.0 以下版本，进入Windows的系统目录，编辑oracle.ini文件，用US7ASCII替换原字符集，重新启动计算机，设置生效；否则，如果，客户端为 sql*net 2.0 以上版本，在Win98 下 运 行REGEDIT,第一步选HKEY_LOCAL_MACHINE,第二步选择SOFTWARE， 第三步选择 Oracle， 第四步选择 NLS_LANG， 键 入 与服 务 器 端 相 同 的 字 符 集
（本例为：HKEY_LOCAL_MACHINE/
SOFTWARE/ORACLE/NLS_LANG ：AMERICAN _ AMERICA. ZHS16GBK）。
如果是UNIX客户端，则：
SQL conn / as sysdba
Connected.
SQL SQL UPDATE sys.PROPS$ SET value$=‘SIMPLIFIED CHINESE’
2 WHERE NAME=‘NLS_LANGUAGE’;
2. 服务器指定字符集与客户字符集相同,与加载数据字符集不一致。
解决方法：强制加载数据字符集与服务器端字符集一致。要做到这一点，可以通过重新创建数据库，并选择与原卸出数据一致的字符集，然后IMP数据，这种情况仅仅适用于空库和具有同一种字符集的数据。
解决这类问题，也可以先将数据加载到具有相同字符集的服务器上，然后用转换工具卸出为foxbase 格式或access格式数据库，再用转换工具转入到不同字符集的Oracle数据库中，这样就避免了Oracle字符集的困扰。目前数据库格式转换的工具很多,像power builder5.0以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等。
3. 服务器指定字符集与客户字符集不同,与输入数据字符集不一致。
对于这种情况，目前为止都还没有太好的解决方法。
通过上面的了解，我们知道，导致在后期使用数据库时出现种种关于字符集的问题，多半是由于在数据库设计、安装之初没有很好地考虑到以后的需要，所以，我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦
怎样修改查看Oracle字符集
a.数据库服务器字符集select * from nls_database_parameters，其来源于props$，是表示数据库的字符集。
b.客户端字符集环境select * from nls_instance_parameters,其来源于v$parameter，
表示客户端的字符集的设置，可能是参数文件，环境变量或者是注册表
c.会话字符集环境 select * from nls_session_parameters，其来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是alter session完成，如果会话没有特殊的设置，将与nls_instance_parameters一致。
客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，alter session环境变量注册表参数文件
实际情况
我用select * from nls_database_parameters
PARAMETER VALUE
------------------------------ ------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET ZHS16GBK
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
PARAMETER VALUE
------------------------------ ------------------------------
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.2.0.1.0
说明我在创建数据库时指定的字符集是ZHS16GBK，我用
update sys.props$ set value$='AL32UTF8' where name='NLS_CHARACTERSET';
修改了字符集，但插入中文时仍然有问题，这或许就如上面资料所说的通过修改SYS.PROPS$来修改主要是对应客户端的显示，与存储无关，
所以仍旧是乱码。
然后我重新创建了个数据库，指定字符集为AL32UTF8，插入中文就没问题了。
可见我们如果要在数据库中显示中文，在创建数据库时一定哟指定好所用的字符集。
oracle表的partition名乱码查询：
1、查看服务器端编码
Select userenv('language') from dual;
我实际查到的结果为： AMERICAN_AMERICA.UTF8（每人查到的可能不一样）
2、执行语句 select * from V$NLS_PARAMETERS
查看第一行中PARAMETER项中为NLS_LANGUAGE对应的VALUE项中是否和第一步得到的值一样。
如果不是，需要设置环境变量。
3、设置环境变量
计算机--属性-- 高级系统设置-- 环境变量 --系统环境变量--新建
设置变量名：NLS_LANG
变量值：第1步查到的值，AMERICAN_AMERICA.UTF8(以你第一步查到的为准)
