日期:2014-05-16 浏览次数:20476 次
?
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这样的通用解决方案,即使会有一些空间和运行