字符集问题的初步探讨

Oracle全球支持(即Globalization Support)允许我们使用本地语言和格式来存储和检索数据。通过全球支持，Oracle可以支持多种语言及字符集，得以展示数据库的强大魅力。 
由于不同语言及字符集的共同存储存在设置上具有一定的复杂性，字符集一度成为普遍困扰大家的一个主要问题。
本文试图就一些常见问题进行探讨，希望可以把一些实际经验共享给大家！
1． 字符集的基本知识
如果从头说起，字符集最早的编码方案来自于与ASCII.
这也是我们最常见的编码方式。该方案起源于1960年代初期，最初是美国国会图书馆制定用来作为美国图书馆界书目交换的共同标准，最后完善成为美国的国家标准ASCII（American Standard Codefor Information Interchange），之后进一步演变成世界性的计算机字符编码标准ISO646（其全名为7-bit coded character set for information interchange）。成为计算机编码方案的基础。 
Oracle数据库最早支持的编码方案也就是US7ASCII.
但是我们知道，英文字符一般是以一个字节来存储的，7位的编码方案最多只能代表128个字符；经过扩展的8位的编码方案也只能代表256个字符，这远远不能满足计算机发展的需要，对于亚洲国家复杂的字符存储需要更多的码位，于是各种编码方案随之而生。
为了容纳全世界各种语言的所有字符和符号，解决不同编码之间的兼容和转换问题，1991年元月，10多家公司共同出资，组建Unicode协会,随后Unicode编码产生了。
Unicode协会的口号是: 给每个字符提供了一个唯一的数字，不论是什么平台，不论是什么程序，不论什么语言。
最初Unicode编码使用2-Byte(16bit)来进行编码，但是最多只能容纳65536个字符，仍然不够使用，后来进行了扩充，也就是Unicode3.1标准，增加了额外的补充字符定义，现在Unicode4.0标准已经发布，具体可以参考Unicode官方站点:
www.unicode.org

Unicode编码方案主要有三个实施标准:
UTF-8
USC-2
UTF-16
Oracle从7.2开始支持UTF-8编码，提供Unicode编码支持。
按照各种标准的含义，Oracle推荐，如果你的数据库需要存放不同语言的不同符号和字符，建议使用Unicode编码方案。诚然，Unicode方案可以表示更多的字符，但是由于多位的存储，需要额外的存储空间和网络传输，所以选择最适合的数据库字符集仍然需要慎重考虑。 　

2． 数据库的字符集 
字符集在创建数据库时指定，在创建后通常不能更改，所以在创建数据库时能否选择一个正确的字符集就显得尤为重要。 
在创建数据库时，我们可以指定字符集(CHARACTER SET)和国家字符集(NATIONAL CHARACTER SET)。
字符集用来存储:
     CHAR, VARCHAR2, CLOB, LONG等类型数据
     用来标示诸如表名、列名以及PL/SQL变量等
     SQL和PL/SQL程序单元等
国家字符集用以存储:
     NCHAR, NVARCHAR2, NCLOB等类型数据
这些设置在数据库创建时指定，我们可以看一下数据库的创建脚本:

connect SYS/change_on_install as SYSDBA
set echo on
spool E:/oracle/ora92/assistants/dbca/logs/CreateDB.log
startup nomount pfile="E:/oracle/admin/eygle/scripts/init.ora";
CREATE DATABASE eygle
MAXINSTANCES 1
MAXLOGHISTORY 1
MAXLOGFILES 5
MAXLOGMEMBERS 3
MAXDATAFILES 100
DATAFILE ’E:/oracle/oradata/eygle/system01.dbf’ SIZE 250M REUSE AUTOEXTEND ON NEXT 10240K MAXSIZE UNLIMITED
EXTENT MANAGEMENT LOCAL
DEFAULT TEMPORARY TABLESPACE TEMP TEMPFILE ’E:/oracle/oradata/eygle/temp01.dbf’ SIZE 40M REUSE AUTOEXTEND 
ON NEXT 640K MAXSIZE UNLIMITED
UNDO TABLESPACE "UNDOTBS1" DATAFILE ’E:/oracle/oradata/eygle/undotbs01.dbf’ SIZE 50M REUSE AUTOEXTEND 
ON NEXT 5120K MAXSIZE UNLIMITED
CHARACTER SET ZHS16GBK
NATIONAL CHARACTER SET AL16UTF16
LOGFILE GROUP 1 (’E:/oracle/oradata/eygle/redo01.log’) SIZE 10M,
GROUP 2 (’E:/oracle/oradata/eygle/redo02.log’) SIZE 10M,
GROUP 3 (’E:/oracle/oradata/eygle/redo03.log’) SIZE 10M;
spool off
exit;

以上用粗体显示的就是对我们至关重要的字符集设置。
在创建数据库的过程中，在以下界面选择你的字符集，对于简体中文平台，缺省的字符集是:ZHS16GBK

一旦你的字符集选定了，数据库中能够存储的字符就受到了限制，所以你选择的字符集的应该可以容纳所有你将用到字符。

常见的中文字符集有:

ZHS16CGB231280  CGB2312-80  16-bit Simplified Chinese MB,

ASCIIZHS16GBK      GBK   16-bit Simplified Chinese MB, 

ASCII, 

UDC 
                
其中GB2312码是中华人民共和国国家汉字信息交换用编码，全称《信息交换用汉字编码字符集--基本集》，由国家标准总局发布，
1981年5月1日实施，通行于大陆。新加坡等地也使用此编码。 
GBK编码是1995年12月颁布的指导性规范。
GBK与国家标准 GB 2312-80 信息处理交换码所对应的、事实上的内码标准兼容；同时，在字汇一级支持 ISO/IEC 10646-1 和
GB 13000-1 的全部中日韩 (CJK) 汉字(20902字)。包含了更多的编码。
但是我们说，ZHS16GBK 并非是ZHS16CGB231280的严格超集（虽然后者的汉字在前者中都存在，但是同样的编码在不同两个
字符集中可能表达不同的汉字），所以在做数据库字符转换时仍然需要特别注意。

Oracle的字符集命名遵循以下命名规则:


      即:  <语言>    <比特位数><编码>比如: ZHS    · 16     ·GBK 
                
需要说明的是，有些字符集命名违背了这个规范，Oracle8/Oralce8i中的UTF-8是第一个打破这个命名规范的字符集。
我们可以看到一类字符集以 AL开头，如:
     AL16UTF16
其中 AL代表 ALL,指适用于所有语言(All Languages)，按照这个标准当年UTF-8本应被命名为AL24UTF8。