怎样选择数据库的字符集

1、选择ORACLE数据库字符集如何选择数据库的字符集是一个有争议的话题，字符集本身涉及的范围专门广，它与应用程序、客户的本地环境、操作系统、服务器等关系专门紧密，因此要做出合适的 选择，需要明白这些因素之间的关系。另外对字符集的差不多概念，ORACLE数据库字符集的一些知识也需要了解。 随着国内的软件产品逐步走向海外，关于多语言的支持差不多成为软件的一个差不多要求，采纳UNICODE标准也逐渐成为通用的设计方案，现在ORACLE数据 库的字符集应该如何选择？专门多人都有自己的见解，在网上也能够看到专门多关于字符集的文章。这些文章有专门多精华值得去学习，然而另一方面还存在一些错误，尤 其对UNIC

2、ODE，存在一些概念不清的地点。 数据库字符集的选择并不存在绝对意义上的正确或错误，每种字符集都有它适用的环境。关于我们来讲，了解得越多，越能关心自己做出适当地选择，而且能够采取 措施去主动防范或规避可能出现的问题。反之，假如数据库字符集选择不恰当，会给后面的工作带来专门多的苦恼，需要花费专门多时刻和精力去解决问题，有些问题甚 至会阻碍到客户的业务使用。本文希望能够给大伙儿提供一些相对全面的知识，方便大伙儿了解数据库字符集的相关概念，因此有些繁琐，请大伙儿见谅。另外由于个人的 局限，有何不妥之处还请大伙儿不吝指正。下面我们由浅入深，先由概念入手，再给出几种常用的字符集设置建议，对一些可能遇到的

3、问题做出分析，最后给出自己的建议。 1、字符集的一些差不多知识 讲到数据库的字符集设置，首先需要对字符集的知识有些了解。以下是字符集的差不多知识介绍：由于计算机只能存储使用二进制数据，因此关于一些字符或符号，需要对它们进行编码，用编码后的数值来表示这些字符。关于一组符号的编码集合确实是字符集。 字符集有专门多种，最初的字符集是ASCII，它用一个字节中的7位来表示128个字符，第8位没有使用。它包括大小写字母、数字0-9、标点符号、非打印 字符（换行符、制表符等4个）以及操纵字符（退格、响铃等）等。由于ASCII支持的字符专门有限，因此随后又出现了专门多的编码方案，这些编码方案大部分都 是包括

4、了ASCII的，它们只是做了扩展，这些扩展的内容一般各不相同，因此讲ASCII是一个比较差不多的编码，EBCDIC编码是另一个比较差不多的编 码，它的部分字符采纳了和ASCII不同的编码值，因此两者是不兼容的差不多编码方案。采纳EBCDIC编码的比较少，目前要紧是IBM 的系统采纳，如AS400及S390系统，大部分的系统差不多上基于ASCII编码的。 由于亚洲国家的字符集相对复杂一些，因此一般都使用了两个及以上的字节进行编码的方案。关于简体中文，GB2312码是国家1981年实施的编码标准，通 行于大陆。新加坡等地也使用此编码。GBK编码是GB2312码的扩展，是1995年公布的指导性规范，

5、它在字汇一级支持 ISO/IEC 10646-1 和GB 13000-1 的全部中日韩 (CJK) 汉字(20902字)。目前最新的汉字字符集是2000年的GB18030，它是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还 收录了藏文、蒙文、维吾尔文等要紧的少数民族文字。目前简体WINDOWS的缺省内码依旧GBK，能够通过GB18030升级包升级到GB18030。不 过GB18030相对GBK增加的字符，一般人是专门难用到的，因此GBK依旧我们目前最常用的简体中文字符集。 由于编码方案太多且彼此之间不兼容，存在互相之间存在冲突的情况，即关于同一个编码数值，在两种不同的编码

6、方案中代表的是两个不同的字符。如此关于一些 WEB应用来讲，由于多种语言文字的同时使用及存储，需要采纳一种统一的字符集。为此，国际标准化组织(ISO)制定了ISO 10646码表，而Unicode协会制定了Unicode规范，这两个体系刚开始时是独立建立的，在1991年，双方都认识到世界不需要两个不兼容的字 符集。因此它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode2.0开始，Unicode项目采纳了与ISO 10646-1相同的字库和字码。目前两个项目仍都存在，并独立地公布各自的标准。Unicode协会现在的最新版本是2006年的Unicode 5.0。ISO的

7、最新标准是10646-3:2003。下面简单介绍一下几种常见的编码方式： UCS(Universal Character Set)是按ISO-10646定义的字符集，有两种最常用编码方式： UCS-2和UCS-4。 UCS-2：使用0-65535之间的数表示一个unicode字符。UCS-2无法表示所有的unicode字符，只能表示其前65536个字符（称为 Basic Multilingual Plane，BMP）。我们一般经常使用的UNICODE码确实是指那个编码方案。 UCS-4:使用0-FFFFFFFF之间的数表示一个unicode字符，但为了和unicode体系兼容(unicode体

8、系是一个20bit系 统），ISO-10646表示所有定义的字符将不超过10FFFF。UCS-4能够表示所有的unicode字符。Unix 下使用 UCS-2/UCS-4会导致特不严峻的问题，因为有一些专门的字符, 比如 0 或 /, 它们在文件名和其他C的库函数参数里都有特不的含义，C语言使用0作为字符串结尾，而Unicode里恰恰有专门多字符都有一个字节为0，如此一 来，C语言的字符串函数将无法正常处理Unicode，除非把世界上所有用C写的程序以及他们所用的函数库全部换掉 。 为了解决那个问题，因此产生了将Unicode编码规则和计算机的实际编码对应起来的一个规则，UTF,英文为UCS

9、Transformation Format，即UCS转换格式，目前常用的有UTF-8、UTF-16、UTF-32三种。（还有UTF-7在此就不介绍了）。正如名字所示，它们分不 使用8位、16位、32位比特对UCS进行编码。 UTF-8：一种变长的Unicode编码方式，使用1到4个字节表示一个字符。这种方式的最大好处，是UTF8保留了ASCII字符的编码作为它的一 部分，因此在ASCII表示的128个字符在UTF-8的编码没有变化，它的兼容性比较好。UTF-8在目前WEB应用上使用专门广泛。 UTF-16:一种变长Unicode编码方式，使用两个或者四个字节表示一个字符。这种编码方式比较节约空

10、间，因为它把最常使用的字符都用两个字节来表示，而那些不常用的字节则用两个或四个字节来表示。但关于英文字符来讲，它要用两个字节来编码。 UTF-32:一种固定长度的Unicode编码方式，使用四个字节表示一个字符，它适用在内存专门充足，需要定长的编码场合。 2、ORACLE数据库的字符集 ORACLE的字符集名字一般由以下部分组成：语言或区域、表示一个字符的比特位数、标准字符集名称（可选项，S或C，表示服务器或客户端）。ORACLE字符集UTF8与UTFE不符合此规定，其它差不多差不多上这种格式。 关于US7ASCII，表示区域是US，用7个比特位表示一个字符，标准的字符集名称为ASCII。 关

11、于中文字符集ZHS16GBK，表示简体中文（ZHT为繁体中文），一个字符需要16位比特，标准的字符集名称为GBK。而 ZHS16CGB231280表示简体中文，一个字符需要16位比特，标准的字符集名称为GB231280，属于我们前面提过的1981年公布的 GB231280标准。尽管我们讲，GBK编码标准是GB2312编码标准的扩展，然而数据库字符集ZHS16GBK与ZHS16CGB231280之 间却不是严格的超集与子集的关系，要紧是有些汉字的编码在两个字符集中的数值是不同的，因此它们进行字符集转换时会出现问题。 在本文中，有时候使用的是标准字符集名称，有时候又需要使用ORACLE字符集的名称

12、，因此希望大伙儿明白两者之间的对应关系。 ORACLE数据库有国家字符集（national character set）与数据库字符集(database character set)之分。两者差不多上在创建数据库时需要设置的。国家字符集要紧是用于NCHAR、NVARCHAR、NCLOB类型的字段数据，而数据库字符集使用专门 广泛，它用于：CHAR、VARCHAR、CLOB、LONG类型的字段数据；表名、列名、PL/SQL中的变量名；输入及保存在数据库的SQL和PL /SQL的源码。 ORACLE支持的Unicode字符集有以下几种，下面的列表给出了字符集的名称、对应的数据库版本范围、采纳的Un

13、icode的版本。 字符集 对应的数据库版本范围 Unicode的版本 字符集 对应的数据库版本范围 Unicode的版本 AL24UTFFSS 7.2-8.1 1.1 UTF8 8.0-10g 2.1 (8.0-8.1.6) 3.0 (8.1.7-10g) UTFE 8.0-10g 2.1 (8.0-8.1.6) 3.0 (8.1.7-10g) AL32UTF8 9.0-10g 3.0 (9.0) 3.1 (9.2) 3.2 (10.1) 4.01(10.2) AL16UTF16 9.0-10g 3.0 (9.0) 3.1 (9.2) 3.2 (10.1) 4.01(10.2) AL24UT

14、FFSS：是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相比，它采纳的Un

15、icode版本更新，在10g版本中使用的是 Unicode 4.01标准，而UTF8因为兼容性的考虑，在10g版本中用的是Unicode 3.0标准。 AL16UTF16：是ORACLE第一种采纳UTF-16编码方式的字符集，从ORACLE9开始使用，是作为缺省的国家字符集使用，它不能被用作数据 库的字符集。这是因为数据库的字符集决定了SQL与PL/SQL源码的编码方式，关于UTF16这种使用固定的两个字节来表示英文字母的编码方案来讲， 确实不适于用作数据库的字符集，ORACLE目前采纳的数据库字符集差不多上基于ASCII或EBCDID作为子集的编码方案。 从以上几种字符集的介绍来看，Unic

16、ode字符集一般使用UTF8和AL32UTF8。假如数据库版本都在9i及其以上，不需要考虑ORACLE8的数 据库，建议使用AL32UTF8字符集，它采纳的Unicode标准要比UTF8采纳的Unicode标准更新，支持的字符也更多一些。假如要考虑 ORACLE8数据库，建议使用UTF8字符集，它的兼容性好，在ORACLE8及8I数据库上使用AL32UTF8字符集容易出现问题。 3、如何选择合适的数据库字符集 前面我们介绍了字符集的一些概念，并对ORACLE数据库的常用几个字符集有了一些了解，下面就具体对数据库字符集的选择阐述一些个人的观点： 3.1、数据库需要存储的数据类型是字符集选择的首要

17、考虑目标。 由于数据库的要紧功能在于存储数据，因此要保证数据的正确性。采纳何种数据库字符集需要看存储数据是何种类型的。关于只存储英文信息的数据库等来讲，一般 采纳US7ASCII或WE8ISO8859P1等单字节的字符集就比较合适，在性能和空间上也是最优，假如采纳ZHS16GBK编码，尽管能够使用，但 从数据库字符集本身的含义来讲，属于不恰当的选择。同样，存储了中文信息的数据库，假如采纳单字节的字符集，也是不合适的。在这种情况下，数据库的字符集 尽管是US7ASCII或WE8ISO8859P1编码，但里面存储的数据编码实际上却是另外的编码格式，这种不一致的情况专门容易引起问题，建议不要如此 使

18、用。ORACLE提供了专门多种类的字符集供客户选择，确实是要满足各种文字不同的编码需要。 3.2、字符集的选择需要优先考虑应用程序的需要。 目前出于国际化的需要，软件需要能够对不同的语言文字进行处理，尤其一个系统中需要容纳多种语言文字的时候，一般都会采纳Unicode如此的通用解决方 案，即使会有一些空间和运行效率的损失也是值得的。现在数据库字符集建议能够采纳AL32UTF8或UTF8编码，一种比较理想的模式确实是由程序负责编码 格式的转换，而数据库只提供一个透明的数据存储； 客户在应用程序中输入数据，现在数据的编码格式是由客户操作系统的区域及语言设置决定的，如在简体中文XP的环境下，输入的中

19、文编码属于GBK编码。在客 户输入结束后，程序首先推断客户的本地环境，并把编码转换成UNICODE，并通过NET传送到服务器端。由于客户端与服务器数据库的字符集均为UTF8 格式，ORACLE在传送过程中可不能进行字符转换，直接把数据按UTF8格式存储到数据库中。查询时是一个反向的过程，应用程序从数据库中取出UTF8编 码的数据，再由应用程序依照客户的本地环境，把UTF8编码的数据转换成客户本地的编码格式，最后把结果数据显示给客户。此方案的关键在于应用程序要能专门 好的支持UNICODE编码，编码的转换由应用程序来负责，数据库只是提供了一个数据存储功能。 关于部分程序来讲，由于对UNICODE

20、支持不够，没有提供编码的转换功能，则能够使用ORACLE提供的字符集转换功能来实现同样的目的。 客户在应用程序中输入数据，现在数据的编码格式是由客户操作系统的区域及语言设置决定的，如在简体中文XP的环境下，输入的中文编码属于GBK编码。在客 户输入结束后，程序直接把数据并通过NET传送到服务器端。由于客户端与服务器数据库的字符集不一致，因此ORACLE会把客户端的编码转换成UTF8格 式，再把数据按UTF8格式存储到数据库中。这种方案的优点确实是程序能够不用支持UNICODE，由ORACLE数据库自动进行转换。由于数据库的字符集 为UTF8，是其它字符集的超集，因此在转换过程中可不能发生数据丢

21、失的情况。关于英文的字符符号，在UTF8中使用单字节存储，转换的工作量专门小，能够忽 略，而关于一些亚洲字符集，在UTF8中一般需要两到三个字节存储，需要的数据库空间增加，而且转换的工作量也相对大一些，性能会有一些损失。 4、与字符集相关的问题分析 4.1、在UTF8环境下运行SQL语句报错的问题： 我们前面讲过，SQL*PLUS工具不提供编码自动转换的功能，当数据库字符集为UTF8，客户端的NLS_LANG假如也是UTF8，那么在 SQL*PLUS中运行SQL语句时，语句全是英文，可不能出现问题，假如语句包含了中文或其它一些专门字符，SQL语句运行时就会报错。关于返回的含中文 的结果，SQL

22、*PLUS也会显示乱码。造成此错误的缘故在于当SQL语句中包含汉字等一些专门字符时，由于这些字符的编码属于GBK，ORACLE没有进行字符转换，而是直接把SQL语句送到 服务器上进行解析。现在服务器的字符集是UTF8，因此它按UTF8编码格式对SQL语句中GBK编码的字符解析时就会产生错误。假如把客户端的 NLS_LANG设置为本地环境的字符集，如ZHS16GBK，现在能够直接在SQL*PLUS中输入包含中文的SQL语句，ORACLE在把SQL语句 提交到服务器时会自动转换成UTF8编码格式，因此SQL语句能够正常运行。关于英文字母，由于它在UTF8中的编码数值采纳的依旧ASCII的编码数 值

23、，因此英文字母能够直接使用而不需要转换，这确实是假如SQL语句或输出结果全是英文时可不能出现错误的缘故。 正确的做法是先把需要运行的SQL做成脚本文件，用代码转换工具把它转换成UTF8编码格式的文件，（注意！XP中的记事本是提供了代码转换功能的，能够 在保存文件或选择文件另存为的时候，弹出的对话框最后一项，编码，选择UTF8，再保存，即可把文件转换成UTF8编码格式）。完成后用IE打开那个脚 本，选择编码UTF8，观看现在SQL脚本是否含有乱码或“？”符号。假如没有，讲明编码格式差不多是UTF8了，现在在SQL*PLUS中运行那个脚 本就可不能产生错误了。运行结束后，输出的结果中假如包含中文，

24、需要把结果SPOOL输出到一个文件中，然后用代码转换工具把那个结果文件由UTF8转换成 本地编码格式，再用写字板打开，才能看到正常显示的汉字。由于IE具有代码转换功能，因此也能够不用代码转换工具，直接在IE中打开输出的结果文件，选择 UTF8编码，也能正常显示含中文的结果文件。 4.2、数据库出现乱码的问题： 数据库出现乱码的问题要紧和客户的本地化环境，客户端NLS_LANG设置，服务器端的数据库字符集设置这三者有关，假如它们的设置不一致或者某个设置错误，就会专门容易出现乱码，下面我们简要介绍以下几种情况： 4.2.1、数据库字符集设置不当引起的乱码： 这种错误是由于数据库字符集选择错误而引起

25、的。我们前面讲过，由于每种语言文字都有一些自己专门的字符，甚至一些字符的写法都有不同的讲究，因此即使关于 欧美国家来讲，也不是能够随便通用的。像西欧的字符集标准ISO 8859-1是8位编码，它就有自己的一些专门符号，这些字符在US7ASCII编码中找不到对应的编码值。假如需要使用这些专门符号，就必须选用本地字 符集或者是它的超集的字符集。假如选用的字符集两者都不是，那么在数据库存储的数据实际编码和数据库字符集的设置就产生了不一致，专门容易产生乱码。例如：一个存储简体中文字符的数据库，它的字符集选用了US7ASCII，当它的客户端NLS_LANG也选用US7ASCII时，那个系统单独使用是没

26、有问题的，因为两者设置一致，因此ORACLE可不能进行字符集的转换，客户输入的GBK码被直接在数据库中存储起来，当查询数据时，实际客户端取出来的数 据也是GBK的编码，因此显示也是正常的。但当其它的系统需要从那个数据库取数据，或者它的数据要EXP出来，IMP到其它数据库时，问题就会开始出现 了。其它系统的字符集一般是ZHS16GBK，或者其它系统客户端的NLS_LANG设置为ZHS16GBK，现在必定会产生字符集的转换。尽管数据库字 符集设置为US7ASCII，但我们明白，实际存储的数据编码是ZHS16GBK的。惋惜ORACLE可不能明白，它会把存储的ZHS16GBK编码数据当 作US7ASC

27、II编码的数据，按照US7ASCII转换成ZHS16GBK的转换算法进行转换，能够想象，这种情况下，乱码的产生是必定的。结论是：假如要选择一个非本地环境的数据库字符集，在不需要考虑和其它系统的数据接口和数据交换的情况下，或者你有面对这种苦恼的心理预备的话，那么这种选择是可行的，然而不忘了数据库字符集一定要和客户端的NLS_LANG保持一致。 4.2.2、数据库字符集与客户端NLS_LANG设置不同引起的乱码： 由于ORACLE提供了字符集的转换功能，因此数据库字符集与客户端NLS_LANG设置不同是能够同意的，前提条件是数据库的字符集必须是客户端 NLS_LANG设置字符集的超集，那么由于客户

28、端使用的字符是属于数据库字符集中的一部分，因此可不能产生转换时数据丢失及乱码的情况。 例如：关于一个需要存储简体文信息的数据库来讲，它的字符集设置和客户端NLS_LANG设置一般能够使用ZHS16GBK编码。然而假如数据库字符集选 用了UTF8的话，也是能够的，因为ZHS16GBK编码属于UTF8的子集。ORACLE在数据库与客户端进行数据交换时自动进行编码的转换，在数据库 中实际存储的也是UTF8编码的数据。现在其它数据库和此数据库也能够正常的进行数据交换，因为ORACLE会自动进行数据的转换。在实际使用中，遇到过 繁体XP的字符集ZHT16MSWIN950转换成AL32UTF8字符集时，一

29、些专门的字符和个不冷僻的汉字会变成乱码。后来证实是XP需要安装一个字 库补丁软件，最后顺利解决此问题。 结论：关于数据库字符集为UTF8，而客户端采纳本地字符集的情况，最好进行测试验证，因为UNICODE标准本身进展专门快，一些客户端的操作系统对 UNICODE标准支持的力度不一致，有些操作系统支持不行，有些专门字符在转换后会产生乱码。由于那个话题差不多超出了本文的范畴，在此就不详细讨论了。 4.2.3、客户端NLS_LANG与本地化环境不同引起的乱码： 一般情况下，客户端NLS_LANG与本地化环境采纳了不同的字符集会出现乱码，除非本地化环境的字符集是客户端NLS_LANG设置字符集的子集。假如 把客户端NLS_LANG设置为UTF8就属于这种情况，由于目前还没有能够直接使用UNICODE字符集的操作系统，因此客户本地化环境使用的字符集只 能是某种语言支持的字符集，它属于UTF8的子集。下面我们就着重讨论这种情况。 尽管目前WINDOWS的内核是支持UNICODE的，然而WINDOWS并不支持直接显示UNICODE编码的字符,而且它并不明白目前的字符采纳了何 种字符集，因此默认