《Oracle数据库常见字符集问题解析.doc》由会员分享，可在线阅读，更多相关《Oracle数据库常见字符集问题解析.doc（17页珍藏版）》请在金锄头文库上搜索。
1、Oracle数据库常见字符集问题解析 Author : ZengYungangDOCUMENT NUMBER: NGNMSPRODUCT: RELEASE: Confidential Level: Netman GroupDate: 2005-8-23DISTRIBUTE TO: QA&PTREVISION HISTORYDateVersion #AuthorRevision Description2005-08-230.9Zeng YungangDraftOracle数据库常见字符集问题解析1常用字符集合介绍41.1字符集ASCII介绍41.2字符集ISO8859介绍41.3字符集GB231
2、2介绍41.4字符集UTF8介绍52Oracle数据库中数据库字符集的选择62.1Oracle数据库字符集选用原则62.1.1测试结论：62.1.2测试方法概述：72.2数据库服务器字符集为ASCII的测试说明72.2.1客户端字符集为ASCII的情况82.2.2客户端字符集为ISO8859的情况92.2.3客户端字符集为GB2312的情况92.2.4客户端字符集为UTF8的情况102.3数据库服务器字符集为ISO8859的测试说明112.3.1客户端字符集为ASCII的情况112.3.2客户端字符集为ISO8859的情况112.3.3客户端字符集为GB2312的情况122.3.4客户端字符集
3、为UTF8的情况122.4数据库服务器字符集为GB2312的测试说明132.4.1客户端字符集为ASCII的情况132.4.2客户端字符集为ISO8859的情况132.4.3客户端字符集为GB2312的情况142.4.4客户端字符集为UTF8的情况142.5数据库服务器字符集为UTF8的测试说明152.5.1客户端字符集为ASCII的情况152.5.2客户端字符集为ISO8859的情况152.5.3客户端字符集为GB2312的情况162.5.4客户端字符集为UTF8的情况162.6GB2312，UTF8和UTF16存储性能对比173Java编程中字符集的选择17Oracle数据库乱码，Java
4、乱码是每个开发者经常碰到的问题，如何解决，如果避免乱码问题是每个开发者需要解决的问题。同时，随着Netman国际化的发展，其需要存储越来越多的国际字符，如何让我们Netman支持这一点？以下通过一些测试案例，来说明乱码的产生的原因，解决方法，以及我们Netman系统字符集的设置原则！1 常用字符集合介绍我们知道，电子计算机最初是用来进行科学计算的（所以叫做“计算机”），但随着技术的发展，还需要计算机进行其它方面的应用处理。这就要求计算机不仅能处理数值，还能处理诸如文字、特殊符号等其它信息，而计算机本身能直接处理的只有数值信息，所以就要求对这些文字、符号信息进行数值编码！ 字符集的实质就是对一组
5、特定的符号，分别赋予不同的数值编码，以便于计算机的处理。最初的字符集是我们都非常熟悉的ASCII，它是用7个二进制位来表示128个字符，而后来随着不同国家、组织的需要，出现了许许多多的字符集，如表示西欧字符的ISO8859系列的字符集，表示汉字的GB2312-80、GBK等字符集。1.1 字符集ASCII介绍ASCII是我们非常熟悉的字符集， 它是用7个二进制位来表示128个字符！目前，目前几乎所有的其他字符集都兼容ASCII，这也是英文字符不会出现乱码的原因！1.2 字符集ISO8859介绍ISO8859是表示西欧字符的字符集，他是一个8位的字符集！在Oracle数据库中， WE8ISO88
6、59P1就是表示这种字符集，在网络上，这种字符集合有时候被错误的认为是:”万能字符集”，有时候，很多人用他来存储中文(我们的Netman很大一部分也是这么做的)！事实上，这种字符集并不支持中文，如果用他来存储中文是错误的，以下我们会通过一些测试例子来说明这一点！1.3 字符集GB2312介绍为了处理汉字，程序员设计了用于简体中文的GB2312， GB2312(1980年)一共收录了7445个字符，包括6763个汉字和682个其它符号。汉字区的内码范围高字节从B0-F7，低字节从A1-FE，占用的码位是72*94=6768。其中有5个空位是D7FA-D7FE。GB2312支持的汉字太少。1995
7、年的汉字扩展规范GBK1.0收录了21886个符号，它分为汉字区和图形符号区。汉字区包括21003个字符。2000年的GB18030是取代GBK1.0的正式国家标准。该标准收录了27484个汉字，同时还收录了藏文、蒙文、维吾尔文等主要的少数民族文字。现在的PC平台必须支持GB18030。从ASCII、GB2312、GBK到GB18030，这些编码方法是向下兼容的，即同一个字符在这些方案中总是有相同的编码，后面的标准支持更多的字符。在这些编码中，英文和中文可以统一地处理。区分中文编码的方法是高字节的最高位不为0。按照程序员的称呼，GB2312、GBK到GB18030都属于双字节字符集 (DBCS
8、)。有的中文Windows的缺省内码还是GBK，可以通过GB18030升级包升级到GB18030。不过GB18030相对GBK增加的字符，普通人是很难用到的，通常我们还是用GBK指代中文Windows内码。在Oracle数据库中，ZHS16CGB231280就是指这种字符集！由于这种字符集只支持英文和简体中文，不支持其他语种，比如：日文，韩文，繁体中文如果我们的系统需要采用以上语种，我们就不能采用这个字符集！1.4 字符集UTF8介绍Unicode也是一种字符编码方法，不过它是由国际组织（http:/www.unicode.org）设计，可以容纳全世界所有语言文字的编码方案。Unicode的学
9、名是Universal Multiple-Octet Coded Character Set，简称为UCS。UCS可以看作是Unicode Character Set的缩写。UCS有两种格式：UCS-2和UCS-4。顾名思义，UCS-2就是用两个字节编码，UCS-4就是用4个字节（实际上只用了31位，最高位必须为0）编码。目前我们大部分采用UCS-2！UCS规定了怎么用多个字节表示各种文字。怎样传输这些编码，是由UTF(UCS Transformation Format)规范规定的，常见的UTF规范包括UTF-8、UTF-16。UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-
10、8的编码方式如下：UCS-2编码(16进制)UTF-8 字节流(二进制)0000 - 007F0xxxxxxx0080 - 07FF110xxxxx 10xxxxxx0800 - FFFF1110xxxx 10xxxxxx 10xxxxxx例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001， 用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。也就是说，UTF-8是个变
11、长的字符集，英文字符（0000 - 007F）只需要一个字节的存储空间，中文字符（0800 - FFFF）需要三个字节的存储空间！UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF-16和UCS-2基本相同。也就是说，UTF-16是个定长的字符集，英文，中文都需要两个字节的存储空间！2 Oracle数据库中数据库字符集的选择2.1 Oracle数据库字符集选用原
12、则2.1.1 测试结论： Client ASCII7Client ISO8859Client GB2312Client UTF8Server ASCII7存储错误信息丢失信息丢失信息丢失Server ISO8859信息丢失存储错误信息丢失信息丢失Server GB2312信息丢失存储正确(显示错误)存储正确信息丢失ServerUTF8信息丢失存储错误存储正确存储错误说明:0，字符集分为数据库服务器端的字符集设置和测试客户端的字符集设置，Server表示服务器端的字符集，Client表示客服端的字符集设置1，信息丢失:存储的中文信息完全丢失，在任何情况下都无法正确显示2，存储错误:存储的中文信息
13、在一定的情况下可以正确显示，但是，其物理储存是错误的，可能带来其他操作上的隐患3，存储正确(显示错误):存储的中文信息完全正确，但是，在同样的条件下其无法正确显示！4，存储正确: 存储的中文信息完全正确，同时，在同样的条件下也可以正确显示！在以上的测试结论中，如果我们需要存储中文，而且测试客户端操作系统的默认语言是简体中文的化，必须将客户端字符集设为GB2312，将数据库服务器的字符集设为GB2312或者UTF8，我们才能得到正确的测试结果！其他的情况都有错误！也就是：在数据库端：选择需要的字符集。也就是说如果你只存储英文，你可以选择ASCII7或者ISO8859，如果你需要存储中文，你可以选
14、择GB2312或者GBK，如果需要存储多国语言，要选择：UTF8或者UTF16在客户端：设置操作系统实际使用的字符集目前的网管系统当中，主要使用以下两种字符集：ZHS16CGB231280，WE8ISO8859P1WE8ISO8859P1：只支持英文和西欧的字符集，不支持中文，用他来存储中文是错误的，以下会通过以下测试例子来说明这些！ZHS16CGB231280：支持中文，英文！但是不支持日文，韩文，繁体中文为了应对Netman国际化的需要，同时，平衡储存效率，我建议使用UTF8作为我们网管数据库的字符集！以下我们进行一些测试，并且分析产生各种乱码的原因！2.1.2 测试方法概述：我们将创建4个数据库，US7ASCII，WE8ISO8859P1，ZHS16CGB231280，UTF8，然后在每个数据库中，创建一个测试表：create table charset_test(server_charset varchar2(7), os_charset varchar2(7), client_charset varchar2(7), cn_char varchar2(8) )；然后往里面插入，读取中文，进行测试，然后在同样的条件下，参看显示的数据和物理存储的数据！在这过程中，我们使用
