深入解析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中一般需要两到三个字节存储,需要的数据库空间增加,而且转换的工作量也相对大一些,性能会有一些损失。


4、与字符集相关的问题分析
4.1、在UTF8环境下运行SQL语句报错的问题:
    SQL*PLUS工具不提供编码自动转换的功能,当数据库字符集为UTF8,客户端的NLS_LANG如果也是UTF8,那么在SQL*PLUS中运行SQL语句时,语句全是英文,不会出现问题,如果语句包含了中文或其它一些特殊字符,SQL语句运行时就会报错。对于返回的含中文的结果,SQL*PLUS也会显示乱码。造成此错误的原因在于当SQL语句中包含汉字等一些特殊字符时,由于这些字符的编码属于GBK,ORACLE没有进行字符转换,而是直接把SQL语句送到服务器上进行解析。此时服务器的字符集是UTF8,因此它按UTF8编码格式对SQL语句中GBK编码的字符解析时就会产生错误。如果把客户端的NLS_LANG设置为本地环境的字符集,如ZHS16GBK,此时可以直接在SQL*PLUS中输入包含中文的SQL语句,ORACLE在把SQL语句提交到服务器时会自动转换成UTF8编码格式,因此SQL语句可以正常运行。对于英文字母,由于它在UTF8中的编码数值采用的还是ASCII的编码数值,因此英文字母可以直接使用而不需要转换,这就是如果SQL语句或输出结果全是英文时不会出现错误的原因。正确的做法是先把需要运行的SQL做成脚本文件,用代码转换工具把它转换成UTF8编码格式的文件,(注意!XP中的记事本是提供了代码转换功能的,可以在保存文件或选择文件另存为的时候,弹出的对话框最后一项,编码,选择UTF8,再保存,即可把文件转换成UTF8编码格式)。完成后用IE打开这个脚本,选择编码-》UTF8,观察此时SQL脚本是否含有乱码或“?”符号。如果没有,说明编码格式已经是UTF8了,此时在SQL*PLUS中运行这个脚本就不会产生错误了。运行结束后,输出的结果中如果包含中文,需要把结果SPOOL输出到一个文件中,然后用代码转换工具把这个结果文件由UTF8转换成本地编码格式,再用写字板打开,才能看到正常显示的汉字。由于IE具有代码转换功能,因此也可以不用代码转换工具,直接在IE中打开输出的结果文件,选择UTF8编码,也能正常显示含中文的结果文件。


4.2、数据库出现乱码的问题:
    数据库出现乱码的问题主要和客户的本地化环境,客户端NLS_LANG设置,服务器端的数据库字符集设置这三者有关,如果它们的设置不一致或者某个设置错误,就会很容易出现乱码,下面我们简要介绍以下几种情况:
4.2.1、数据库字符集设置不当引起的乱码:
    例如:一个存储简体中文字符的数据库,它的字符集选用了US7ASCII,当它的客户端NLS_LANG也选用US7ASCII时,这个系统单独使用是没有问题的,因为两者设置一致,因此ORACLE不会进行字符集的转换,客户输入的GBK码被直接在数据库中存储起来,当查询数据时,实际客户端取出来的数据也是GBK的编码,因此显示也是正常的。但当其它的系统需要从这个数据库取数据,或者它的数据要EXP出来,IMP到其它数据库时,问题就会开始出现了。其它系统的字符集一般是ZHS16GBK,或者其它系统客户端的NLS_LANG设置为ZHS16GBK,此时必然会产生字符集的转换。虽然数据库字符集设置为US7ASCII,但我们知道,实际存储的数据编码是ZHS16GBK的。可惜ORACLE不会知道,它会把存储的ZHS16GBK编码数据当作US7ASCII编码的数据,按照US7ASCII转换成ZHS16GBK的转换算法进行转换,可以想象,这种情况下,乱码的产生是必然的。

4.2.2、数据库字符集与客户端NLS_LANG设置不同引起的乱码:
    例如:对于一个需要存储简体文信息的数据库来说,它的字符集设置和客户端NLS_LANG设置一般可以使用ZHS16GBK编码。但是如果数据库字符集选用了UTF8的话,也是可以的,因为ZHS16GBK编码属于UTF8的子集。ORACLE在数据库与客户端进行数据交换时自动进行编码的转换,在数据库中实际存储的也是UTF8编码的数据。此时其它数据库和此数据库也可以正常的进行数据交换,因为ORACLE会自动进行数据的转换。在实际使用中,遇到过繁体XP的字符集ZHT16MSWIN950转换成AL32UTF8字符集时,一些特殊的字符和个别冷僻的汉字会变成乱码。后来证实是XP需要安装一个字库补丁软件,最后顺利解决此问题。

4.2.3、客户端NLS_LANG与本地化环境不同引起的乱码:
    一般情况下,客户端NLS_LANG与本地化环境采用了不同的字符集会出现乱码,除非本地化环境的字符集是客户端NLS_LANG设置字符集的子集。如果把客户端NLS_LANG设置为UTF8就属于这种情况,由于目前还没有可以直接使用UNICODE字符集的操作系统,因此客户本地化环境使用的字符集只能是某种语言支持的字符集,它属于UTF8的子集。下面我们就着重讨论这种情况。
    虽然目前WINDOWS的内核是支持UNICODE的,但是WINDOWS并不支持直接显示UNICODE编码的字符,而且它并不知道目前的字符采用了何种字符集,所以默认情况下,它使用缺省的代码页来解释字符。因此,对于其它类型的编码,需要先进行转换,变成系统目前的缺省代码页支持的字符集才能正常使用。
    WINDOWS中的缺省代码页是由控制面板设置中的语言及区域的选择所决定的,属于客户本地化的环境设置。简体中文WINDOWS的字符编码就是GBK,它的缺省代码页是936。对于其它非WINDOWS的操作系统,我们可以把它们目前缺省使用的字符集作为用户的本地化环境设置。另外,我们使用的大部分工具,如写字板,SQL*PLUS等,它们没有提供编码转换功能,因此在客户端直接输入或查询数据往往都会遇到乱码的问题,必须由应用程序或一些工具去做编码的转换,才能保证正常的使用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值