Oracle字符集基本知识以及正确设置

Oracle 字符集基本知识以及正确设置，ORACLE的字符集名字一般由以下部分组成：语言或区域、表示一个字符的比特位数、标准字符集名

1、字符集的一些基本知识
字符集有很多种，最初的字符集是ASCII，由于ASCII支持的字符很有限，因此随后又出现了很多的编码方案，这些编码方案大部分都是包括了ASCII的。EBCDIC编码是另一个比较基本的编码，它的部分字符采用了和ASCII不同的编码值，因此两者是不兼容的基本编码方案。采用EBCDIC编码的比较少，目前主要是IBM 的系统采用，如AS400及S390系统，大部分的系统都是基于ASCII编码的。
由于亚洲国家的字符集相对复杂一些，因此一般都使用了两个及以上的字节进行编码的方案。对于简体中文，GB2312码是国家1981年实施的编码标准，通行于大陆。新加坡等地也使用此编码。GBK编码是GB2312码的扩展，是1995年发布的指导性规范，它在字汇一级支持 ISO/IEC 10646-1 和GB 13000-1 的全部中日韩 (CJK) 汉字(20902字)。目前最新的汉字字符集是2000年的GB18030，它是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。目前简体WINDOWS的缺省内码还是GBK。
由于编码方案太多且彼此之间不兼容，存在互相之间存在冲突的情况，即对于同一个编码数值，在两种不同的编码方案中代表的是两个不同的字符。这样对于一些WEB应用来说，由于多种语言文字的同时使用及存储，需要采用一种统一的字符集。为此，国际标准化组织(ISO)制定了ISO 10646码表，而Unicode协会制定了Unicode规范，这两个体系刚开始时是独立建立的，在1991年，双方都认识到世界不需要两个不兼容的字符集。于是它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采用了与ISO 10646-1相同的字库和字码。目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2006年的Unicode 5.0。

2、Oracle数据库的字符集
ORACLE的字符集名字一般由以下部分组成：语言或区域、表示一个字符的比特位数、标准字符集名称（可选项，S或C，表示服务器或客户端）。ORACLE字符集UTF8与UTFE不符合此规定，其它基本都是这种格式。

set nls_lang=AMERICAN_AMERICA.UTF8

set nls_lang=SIMPLIFIED CHINESE_AMERICA.UTF8

对于US7ASCII，表示区域是US，用7个比特位表示一个字符，标准的字符集名称为ASCII。
对于中文字符集ZHS16GBK，表示简体中文（ZHT为繁体中文），一个字符需要16位比特，标准的字符集名称为GBK。而ZHS16CGB231280表示简体中文，一个字符需要16位比特，标准的字符集名称为GB231280，属于我们前面提过的1981年发布的GB2312－80标准。虽然我们说，GBK编码标准是GB2312编码标准的扩展，但是数据库字符集ZHS16GBK与ZHS16CGB231280之间却不是严格的超集与子集的关系，主要是有些汉字的编码在两个字符集中的数值是不同的，因此它们进行字符集转换时会出现问题。
在本文中，有时候使用的是标准字符集名称，有时候又需要使用ORACLE字符集的名称，因此希望大家明白两者之间的对应关系。
ORACLE数据库有国家字符集（national character set）与数据库字符集(database character set)之分。两者都是在创建数据库时需要设置的。国家字符集主要是用于NCHAR、NVARCHAR、NCLOB类型的字段数据，而数据库字符集使用很广泛，它用于：CHAR、VARCHAR、CLOB、LONG类型的字段数据；表名、列名、PL/SQL中的变量名；输入及保存在数据库的SQL和PL/SQL的源码。
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作为子集的编码方案。

3、如何选择合适的数据库字符集
3.1、数据库需要存储的数据类型是字符集选择的首要考虑目标。
对于只存储英文信息的数据库等来说，一般采用US7ASCII或WE8ISO8859P1等单字节的字符集就比较合适，在性能和空间上也是最优，

同样，存储了中文信息的数据库，如果采用单字节的字符集，也是不合适的。在这种情况下，数据库的字符集虽然是US7ASCII或WE8ISO8859P1编码，但里面存储的数据编码实际上却是另外的编码格式，这种不一致的情况很容易引起问题，建议不要这样使用。ORACLE提供了很多种类的字符集供客户选择，就是要满足各种文字不同的编码需要。

3.2、字符集的选择需要优先考虑应用程序的需要。
目前出于国际化的需要，软件需要可以对不同的语言文字进行处理，，尤其一个系统中需要容纳多种语言文字的时候，一般都会采用Unicode这样的通用解决方案，即使会有一些空间和运行效率的损失也是值得的。此时数据库字符集建议可以采用AL32UTF8或UTF8编码，一种比较理想的模式就是由程序负责编码格式的转换，而数据库只提供一个透明的数据存储，
客户在应用程序中输入数据，此时数据的编码格式是由客户操作系统的区域及语言设置决定的，如在简体中文XP的环境下，输入的中文编码属于GBK编码。在客户输入结束后，程序首先判断客户的本地环境，并把编码转换成UNICODE，并通过NET传送到服务器端。由于客户端与服务器数据库的字符集均为UTF8格式，ORACLE在传送过程中不会进行字符转换，直接把数据按UTF8格式存储到数据库中。查询时是一个反向的过程，应用程序从数据库中取出UTF8编码的数据，再由应用程序根据客户的本地环境，把UTF8编码的数据转换成客户本地的编码格式，最后把结果数据显示给客户。此方案的关键在于应用程序要能很好的支持UNICODE编码，编码的转换由应用程序来负责，数据库只是提供了一个数据存储功能。
对于部分程序来说，由于对UNICODE支持不够，没有提供编码的转换功能，则可以使用ORACLE提供的字符集转换功能来实现同样的目的。客户在应用程序中输入数据，此时数据的编码格式是由客户操作系统的区域及语言设置决定的，如在简体中文XP的环境下，输入的中文编码属于GBK编码。在客户输入结束后，程序直接把数据并通过NET传送到服务器端。由于客户端与服务器数据库的字符集不一致，因此ORACLE会把客户端的编码转换成UTF8格式，再把数据按UTF8格式存储到数据库中。这种方案的优点就是程序可以不用支持UNICODE，由ORACLE数据库自动进行转换。由于数据库的字符集为UTF8，是其它字符集的超集，因此在转换过程中不会发生数据丢失的情况。对于英文的字符符号，在UTF8中使用单字节存储，转换的工作量很小，可以忽略，而对于一些亚洲字符集，在UTF8中一般需要两到三个字节存储，需要的数据库空间增加，而且转换的工作量也相对大一些，性能会有一些损失。