影响Oracle数据库字符集最重要的参数是NLS_LANG参数。
它的格式如下: NLS_LANG = language_territory.charset
它有三个组成部分(语言、地域和字符集)，每个成分控制了NLS子集的特性。
其中:
Language： 指定服务器消息的语言， 影响提示信息是中文还是英文
Territory： 指定服务器的日期和数字格式，
Charset： 指定字符集。
如:AMERICAN _ AMERICA. ZHS16GBK
从NLS_LANG的组成我们可以看出，真正影响数据库字符集的其实是第三部分。
所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据，前面影响的只是提示信息是中文还是英文。
查看数据库字符集
数据库服务器字符集select * from nls_database_parameters，其来源于props$，是表示数据库的字符集。
客户端字符集环境select * from nls_instance_parameters,其来源于v$parameter，
表示客户端的字符集的设置，可能是参数文件，环境变量或者是注册表
会话字符集环境 select * from
nls_session_parameters，其来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是alter
session完成，如果会话没有特殊的设置，将与nls_instance_parameters一致。
客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，alter session>环境变量>注册表>参数文件
字符集要求一致，但是语言设置却可以不同，语言设置建议用英文。如字符集是zhs16gbk，则nls_lang可以是American_America.zhs16gbk。
涉及三方面的字符集，
1. oracel server端的字符集;
2. oracle client端的字符集;
3. dmp文件的字符集。
在做数据导入的时候，需要这三个字符集都一致才能正确导入。
基本概念
字符集（Character set）：是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。常见的字符集有ASCII，ZHS16GB231280，ZHS16GBK等。
字符编码（Character Encoding）：是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其它的一个集合（如电脑编码）进行配对。即在符号集合与数字系统之间建立对应关系。与字符集相对应，常见的字符编码有：ASCii，ZHS16GBK，ZHT16BIG5，ZHS32GB18030等。
字符集的定义其实就是字符的集合，而字符编码则是指怎么将这些字符变成字节用于保存、读取和传输。
万国码（Unicode）：包含了几乎人类所有可用的字符，每年还在不断的增加，可以看作是一种通用的字符集。它将全世界所有的字符统一化，统一编码，不会再出现字符不兼容和字符转换的问题。
它有以下三种编码方式：
1.UTF-32编码：固定使用4个字节来表示一个字符，存在空间利用效率的问题。
2.UTF-16编码：对相对常用的60000余个字符使用两个字节进行编码，其余的使用4字节。
3.UTF- 8编码：兼容ASCII编码；拉丁文、希腊文等使用两个字节；包括汉字在内的其它常用字符使用三个字节；剩下的极少使用的字符使用四个字节。
Oracle字符集基本原理
在搞懂Oracle字符集基本原理之前，一定要先分清以下三个概念：
1. Oracle数据库服务器字符集：即Oracle以哪种字符编码存储字符，可以通过以下语句查出数据库字符集的设置。
SQL> select * from v$nls_parameters where parameter='NLS_CHARACTERSET';
PARAMETER VALUE
------------------------------ -----------------
NLS_CHARACTERSET AL32UTF8
2. 客户端操作系统字符集：即客户端操作系统以哪种字符编码存储字符。
如果是Windows，可以使用chcp命令获得代码页（code page）：
C:Usersxianzhu>chcp
Active code page: 936
根据该代码页，到微软的官方文档《National Language Support (NLS) API Reference》找到其对应的字符集。
如果是Linux，字符集在/etc/sysconfig/i18n设置：
LANG="zh_CN.GB2312" (指定当前操作系统的字符集)
SUPPORTED="zh_CN.GB2312"(指定当前操作系统支持的字符集)
SYSFONT="lat0-sun16"(指定当前操作系统的字体)
3. 客户端NLS_LANG参数：该参数用于向Oracle指示客户端操作系统的字符集。
有了以上3个基本概念之后，我来阐述一下Oracle字符集转换的基本原则：
1.设置客户端的NLS_LANG为客户端操作系统的字符集
2.如果数据库字符集等于NLS_LANG，数据库和客户端传输字符时不作任何转换
3.如果它们俩不等，则需要在不同字符集间转换，只有客户端操作系统字符集是数据库字符集子集的基础上才能正确转换，否则会出现乱码。
几种常见情况分析
下面先看一个例子，再透过现象看本质，我们会针对这个例子进行分析。
该例子如下：
1. 数据库字符集为Unicode（UTF-8编码）
我们的数据库版本是10.2.0.4.0，数据库字符集是：
SQL> select * from v$nls_parameters where parameter='NLS_CHARACTERSET';
PARAMETER VALUE
---------------------------------------- ------------------------------
NLS_CHARACTERSET AL32UTF8
2. 客户端操作系统字符集为代码页936（字符集为ZHS16GBK）
可以使用chcp获得windows的代码页(code page)
C:Documents and Settingsa105024Desktop>chcp
Active code page: 936
3. 创建测试表
SQL> create table test(id number,var varchar2(30));
Table created.
4. 插入数据
这里在同一个操作系统启动两个session，session1的NLS_LANG设为和数据库字符集一样（即AL32UTF8）：
C:Documents and Settingsa105024Desktop>set nls_lang=Simplified Chinese_China.AL32UTF8
连接数据库并插入一条数据：
Session_1>insert into test values(1,'中国');
1 row created.
Session_1>commit;
Commit complete.
session2的NLS_LANG设为和客户端操作系统一样（即ZHS16GBK）：
C:Documents and Settingsa105024Desktop>set nls_lang=Simplified Chinese_China.ZHS16GBK
连接数据库并插入一条数据：
Session_2>insert into test values(2,'中国');
1 row created.
Session_2>commit;
Commit complete.
5. 执行查询
在session 1上执行查询：
Session_1>select * from test;
ID VAR
---------- ---------------------
1 中国
2 涓 浗
在session 2上执行查询：
Session_2>select * from test;
ID VAR
---------- --------------------
1 ？??
2 中国
上面例子看起来很诡异，session1和2都能正常显示自己插入的字符串，又都不能正常显示对方插入的字符串。为了弄清楚，我们首先得知道数据库里对这两个字符串是怎么存储的。我们可以使用dump函数获得字符在数据库的编码:
SQL> select id,dump(var,1016) from test;
ID DUMP(VAR,1016)
-- ------------------------------------------------------------
1 Typ=1 Len=4 CharacterSet=AL32UTF8: d6,d0,b9,fa
2 Typ=1 Len=6 CharacterSet=AL32UTF8: e4,b8,ad,e5,9b,bd
根据AL32UTF8的编码，“中国”两字的正确编码为（都为3个字节）：
中--e4,b8,ad
国--e5,9b,bd
因此session 1插入的字符串在数据库中的编码是错误的，session 2正确。这也是为什么一定要设置NLS_LANG为客户端操作系统的字符集。
但是根据上面实验我们可以知道，数据库中存储正确，并不代表客户端能正常显示；同样地，即时数据库没有正确存储，有时候客户端也能够正常显示，这又是为什么呢？别急，请听我慢慢道来：
场景1：session 1插入，session 1查询，在数据库中存储错误，但显示正确。
插入过程：
”中国“两字在客户端操作系统字符集ZHS16GBK中的编码是”d6,d0,b9,fa"，由于NLS_LANG和数据库字符集相同，数据库端对客户端传过来的字符编码不进行任何转换直接存入数据库，因此数据库中存储的编码也是“d6,d0,b9,fa”，
读取过程：
数据库端读取的编码是“d6,d0,b9,fa”，由于NLS_LANG和数据库字符集相同，客户端对数据库端传过来的字符编码不进行任何转换直接显示，编码”d6,d0,b9,fa“在客户端操作系统字符集ZHS16GBK对应的汉字为“中国”。
从以上分析可知，虽然读取时正确的，但那是因为负负得正，实际上数据库中存储是错误的，因此要特别小心这种情况，在生成库中要避免。其实只要对它进行length操作就能轻易揭开它的假面具：
Session_1>select length(var) from test where id=1;
LENGTH(VAR)
-----------
3
得出的长度居然为3！实际的长度只是2，这会带来很多麻烦。
场景2：session 1插入，session 2查询，在数据库中存储错误，显示也错误。
插入过程和场景1一样，这里就不再累述。
读取过程：
数
据库端读取的编码是“d6,d0,b9,fa”，由于NLS_LANG和数据库字符集不同，客户端对数据库端传过来的字符编码进行转换，数据库端字符集
AL32UTF8里编为“d6,d0,b9,fa”无法在客户端操作系统字符集ZHS16GBK里找到对应的编码，所以只好用?代替。
场景3：session 2插入，session 1查询，在数据库中存储正确，但显示错误。
插入过程：
”
中国“两字在客户端操作系统字符集ZHS16GBK中的编码是”d6,d0,b9,fa"，由于NLS_LANG和数据库字符集不同，Oracle会进行
字符编码转换，也就是将字符集ZHS16GBK里“中国”的编码“d6,d0,b9,fa"转换为字符集"AL32UTF8"里”中国“的编
码”e4,b8,ad,e5,9b,bd“。
读取过程：
数据库端读取的编码
是”e4,b8,ad,e5,9b,bd“，由于NLS_LANG和数据库字符集相同，客户端对数据库端传过来的字符编码不进行任何转换直接显示，编
码”e4,b8,ad,e5,9b,bd“在客户端操作系统字符集ZHS16GBK对应的汉字为“涓
浗”（原本2个字符，现在变成了3个字符，因为ZHS16GBK的汉字以2个字节编码）。
场景4：session 2插入，session 2查询，在数据库中存储正确，显示也正确。
插入过程和场景3类似。
读取过程：
数
据库端读取的编码是”e4,b8,ad,e5,9b,bd“，由于NLS_LANG和数据库字符集不同，客户端对数据库端传过来的字符编码进行转换，数据
库端字符集AL32UTF8里”中国“两字的编码”e4,b8,ad,e5,9b,bd“转换成客户端操作系统字符集ZHS16GBK里“中国”两字的编
码“d6,d0,b9,fa"，并正常显示。
这种情况虽然经过了两次转换，都确实最正确、最推荐的方式。
附录：Oracle 字符集超集和子集的对应关系可查看：http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/applocaledata.htm#sthref1988
结论：NLS_LANG只和客户端操作系统的字符集相关，如果客户端操作系统的字符集和数据库字符集间无法正确转换，则应该首先改变客户端终端的字符集，而不是简单地把NLS_LANG设为和数据库字符集一样。
概念描叙
ORACLE 数据库有国家字符集（national character set）与数据库字符集(database character set)之分。两者都是在创建数据库时需要设置的。国家字符集主要是用于NCHAR、NVARCHAR、NCLOB类型的字段数据，而数据库字符集使用很 广泛，它用于：CHAR、VARCHAR、CLOB、LONG类型的字段数据；
ORACLE的字符集名字一般由以下部分组成：语言或区域、表示一个字符的比特位数、标准字符集名称（可选项，S或C，表示服务器或客户端）。 ORACLE字符集UTF8与UTFE不符合此规定，其它基本都是这种格式。NLS_LANG=<Language>_< Territory>.<Clients Characterset>
set nls_lang=AMERICAN_AMERICA.UTF8
set nls_lang=SIMPLIFIED CHINESE_AMERICA.UTF8
NLS( National Language Support)国家语言支持。NLS是数据库的一个非常强大的特性，它控制着数据的许多方面：比如数据如何存储，一般来说它控制着以下两个方面：
文本数据持久存储在磁盘上时如何编码
透明的将数据从一个字符集转换到另外一个字符集。
假 设你在数据库中用WE8ISO8859P1 字符集存储8 位的数据，但是你的某些客户使用的是一种7 位字符集，如US7ASCII字符集转换过程通常会修改数据，而你往往会把一个较大的字符集（在此例中就是8 位字符集）映射到一个较小的字符集（此例中的7 位字符集）。这是一种有损转换（lossy conversion），字符就会被修改，这只是因为：较小的字符集不可能表示较大字符集中的每一个字符。但是这种转换必须发生。这也是乱码产生的原因。 如果数据库以一种单字节字符集存储数据，但是客户（如一个Java 应用，因为Java 语言使用Unicode）希望数据采用多字节表示，就必须执行转换，只有这样客户应用才能使用这些数据。
ORACLE支持的Unicode字符集有以下几种，下面的列表给出了字符集的名称、对应的数据库版本范围、采用的Unicode的版本。
AL24UTFFSS：是ORACLE第一种支持Unicode的字符集，从7.2版本开始使用，但是它支持的Unicode版本为1.1，因此从9i开始就不支持此字符集了。
UTF8 : 是ORACLE从ORACLE8开始使用的属于UTF-8编码的字符集，从ORACLE8.0到ORACLE8.16，Unicode版本为2.1，而ORACLE817到10g，采用的Unicode标 准为3.0
UTFE ：用于EBCDIC码平台上的数据库Unicode字符集。因此它属于专用系统使用的字符集，其它属性与UTF8基本相同。
AL32UTF8 ：是从ORACLE9开始使用的属于UTF-8编码的字符集，与UTF8相比，它采用的Unicode版本更新，在10g版本中使用的是Unicode 4.01标准，而UTF8因 为兼容性的考虑，在10g版本中用的是Unicode 3.0标准。
AL16UTF16： 是ORACLE第一种采用UTF-16编码方式的字符集，从ORACLE9开始使用，是作为缺省的国家字符集使用，它不能被用作数据库的字符集。这是因为 数 据库的字符集决定了SQL与PL/SQL源码的编码方式，对于UTF－16这种使用固定的两个字节来表示英文字母的编码方案来说，确实不适于用作数据库 的字符集，ORACLE目前采用的数据库字符集都是基于ASCII或EBCDID作为子集的编码方案。
对于US7ASCII，表示区域是US，用7个比特位表示一个字符，标准的字符集名称为ASCII。
对 于中文字符集ZHS16GBK，表示简体中文（ZHT为繁体中文），一个字符需要16位比特，标准的字符集名称为GBK。而ZHS16CGB231280 表示简体中文，一个字符需要16位比特，标准的字符集名称为GB231280，属于我们前面提过的1981年发布的GB2312－80标准。虽然我们 说，GBK编码标准是GB2312编码标准的扩展，但是数据库字符集ZHS16GBK与ZHS16CGB231280之间却不是严格的超集与子集的关系， 主要是有些汉字的编码在两个字符集中的数值是不同的，因此它们进行字符集转换时会出现问题。
查看字符集参数
1：查看NLS_CHARACTERSET：字符集，NLS_NCHAR_CHARACTERSET：国家字符集
实例字符集环境
SELECT * FROM NLS_INSTANCE_PARAMETERS
主 要涉及NLS_LANGUAGE、NLS_TERRITORY的值. NLS_INSTANCE_PARAMETERS其来源于v$parameter，注意：网上很多资料都 说"NLS_INSTANCE_PARAMETERS 表示客户端的字符集的设置，可以是参数文件，环境变量或者是注册表",而且网上都人人亦云。记住它是表示实例的字符集环境。
数据库可用字符集参数设置
SELECT * FROM V$NLS_VALID_VALUES
数据库服务器字符集
SELECT * FROM NLS_DATABASE_PARAMETERS
NLS_DATABASE_PARAMETERS其来源于props$，是表示数据库的字符集。
客户端字符集环境
SELECT * FROM V$NLS_PARAMETERS;
SELECT USERENV('language') FROM DUAL;
USERENV、 V$NLS_PARAMETERS表示当前字符集环境。如果你在客户端执行，则表示客户端字符集环境。
会话字符集环境
SELECT * FROM NLS_SESSION_PARAMETERS;
它来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是ALTER SESSION完成，如果会话没有特殊的设置，将与 V$NLS_PARAMETERS一致。
2： 查看客户端字符集(NLS_LANG) 的方法
如果系统是LINUX或UNIX平台，则也可以通过下面命令查看(前提是必须设置了NLS_LANG，否则查出来的是空值)
[etl@m1 ~]$env | grep NLS_LANG
NLS_LANG=AMERICAN_AMERICA.ZHS16GBK
[etl@m1 ~]$echo $NLS_LANG
AMERICAN_AMERICA.ZHS16GBK
如果系统是WINDOWS平台，则可以通过下面命令查看：
1：在运行里面，输入regedit进入注册表，HKEY_LOCAL_MACHINESOFTWAREORACLEKEY_OraDb11g_home1里面(最后一项与实例名、数据库版本有关系)，找到NLS_LANG选项，双击它，你就可以看到相应的值。
2：echo %NLS_LANG% 。如果没有设置NLS_LANG，用这个命令看不到相关信息。
3： 设置NLS_LANG的方法
Windows平台：
3.1
set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
set NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBK
3.2 可以通过修改注册表键值永久设置
HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE/KEY_XXXX_home1/NLS_LANG
UNIX & LINUX
3.3
export NLS_LANG=AMERICAN_AMERICA.UTF8
3.4可以编辑 bash_profile 文件进行永久设置
vi .bash_profile
export NLS_LANG="SIMPLIFIED CHINESE_CHINA.ZHS16GBK"
客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，优先级关系为：SQL Function >Alter session>环境变量>注册表>参数文件字符集要求一致，但是语言设置却可以不同，语言设置建议用英文。如字符集是zhs16gbk，则nls_lang可以是American_America.zhs16gbk。
修改数据库字符集
数 据库字符集在创建后原则上不能更改。因此，在前期规划和安装之初考虑使用哪一种字符集十分重要。对数据库服务器而言，错误的修改字符集将会导致很多不可测 的后果，可能会严重影响数据库的正常运行，所以在修改之前一定要确认两种字符集是否存在子集和超集的关系。一般来说，除非万不得已，我们不建议修改 ORACLE数据库SERVER端的字符集。
有两种方法修改数据库字符集设置
1. 通常需要导出数据库数据，重建数据库，然后再导入数据库数据的方式来转换。
2. 通过ALTER DATABASE CHARACTER SET语句修改字符集，但创建数据库后可以修改的字符集是有限制的，只有新的字符集是当前字符集的超集时才能修改数据库字符集，例如UTF8是 US7ASCII的超集，修改数据库字符集可使用ALTER DATABASE CHARACTER SET UTF8。
特别说明，我们最常用的两种字符集ZHS16GBK和ZHS16CGB231280之间不存在子集和超集关系，因此理论上讲这两种字符集之间的相互转换不受支持修改
关于数据库子集-超级对照表（subset-superset pairs），可以参考官方文档，例如ORACLE 10g的http://docs.oracle.com/cd/B19306_01/server.102/b14225/applocaledata.htm
Table A-11 Subset-Superset Pairs
|
Subset |
Superset |
|
AR8ADOS710 |
AR8ADOS710T |
|
AR8ADOS720 |
AR8ADOS720T |
|
AR8ADOS720T |
AR8ADOS720 |
|
AR8APTEC715 |
AR8APTEC715T |
|
AR8ARABICMACT |
AR8ARABICMAC |
|
AR8ISO8859P6 |
AR8ASMO708PLUS |
|
AR8ISO8859P6 |
AR8ASMO8X |
|
AR8MUSSAD768 |
AR8MUSSAD768T |
|
AR8MUSSAD768T |
AR8MUSSAD768 |
|
AR8NAFITHA711 |
AR8NAFITHA711T |
|
AR8NAFITHA721 |
AR8NAFITHA721T |
|
AR8SAKHR707 |
AR8SAKHR707T |
|
AR8SAKHR707T |
AR8SAKHR707 |
|
BLT8CP921 |
BLT8ISO8859P13 |
|
BLT8CP921 |
LT8MSWIN921 |
|
D7DEC |
D7SIEMENS9780X |
|
D7SIEMENS9780X |
D7DEC |
|
DK7SIEMENS9780X |
N7SIEMENS9780X |
|
I7DEC |
I7SIEMENS9780X |
|
I7SIEMENS9780X |
IW8EBCDIC424 |
|
IW8EBCDIC424 |
IW8EBCDIC1086 |
|
KO16KSC5601 |
KO16MSWIN949 |
|
LT8MSWIN921 |
BLT8ISO8859P13 |
|
LT8MSWIN921 |
BLT8CP921 |
|
N7SIEMENS9780X |
DK7SIEMENS9780X |
|
US7ASCII |
See Table A-12, "US7ASCII Supersets". |
|
UTF8 |
AL32UTF8 |
|
WE8DEC |
TR8DEC |
|
WE8DEC |
WE8NCR4970 |
|
WE8ISO8859P1 |
WE8MSWIN1252 |
|
WE8ISO8859P9 |
TR8MSWIN1254 |
|
WE8NCR4970 |
TR8DEC |
|
WE8NCR4970 |
WE8DEC |
|
WE8PC850 |
WE8PC858 |
AS SYSDBA;
3: SQL>SHUTDOWN IMMEDIATE;
5: SQL>STARTUP MOUNT;
7: SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION;
9: SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
11: SQL>ALTER SYSTEM SET AQ_TM_PROCESSES=0;
13: SQL>ALTER DATABASE OPEN;
--可以从子集到父集
ALTER DATABASE CHARACTER SET ZHS16GBK;
3: --如果是从父集到子集，需要使用INTERNAL_USE参数，跳过超子集检测
5: SQL>ALTER DATABASE NATIONAL CHARACTER SET UTF8;
7: --SQL>ALTER DATABASE NATIONAL CHARACTER SET INTERNAL_USE UTF8;
9: SQL>SHUTDOWN IMMEDIATE;
11: SQL>STARTUP;
ALTER DATABASE NATIONAL CHARACTER SET UTF8;
有可能会出现ORA-12717: Cannot ALTER DATABASE NATIONAL CHARACTER SET when NCLOB data exists 这样的提示信息.这时你用ALTER DATABASE NATIONAL CHARACTER SET INTERNAL_USE UTF8;就可解决上述问题。