Oracle字符集运用中易出现的问题分析

数据库 Oracle
以下的文章主要是对Oracle字符集相关问题的分析,你如果是Oracle字符集的疯狂一族的话,以下的文章,你一定不要错过。

以下的文章主要介绍的是Oracle字符集相关的问题分析,如果你是Oracle字符集相关实际应用方面的新手,你就可以通过以下的文章对Oracle字符集是如何正确使用的方法有一个更好的了解,以下就是文章的详细内容的介绍。

1、在UTF8环境下运行SQL语句报错的问题:

 

SQL*PLUS工具不提供编码自动转换的功能,当数据库字符集为UTF8,客户端的NLS_LANG如果也是UTF8,那么在SQL*PLUS中运行SQL语句时,语句全是英文,不会出现问题,如果语句包含了中文或其它一些特殊字符,SQL语句运行时就会报错。对于返回的含中文的结果,SQL*PLUS也会显示乱码。

造成此错误的原因在于当SQL语句中包含汉字等一些特殊字符时,由于这些字符的编码属于GBK,ORACLE没有进行字符转换,而是直接把SQL语句送到服务器上进行解析。此时服务器的Oracle字符集是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编码,也能正常显示含中文的结果文件。

 

 

数据库出现乱码的问题:

 

数据库出现乱码的问题主要和客户的本地化环境,客户端NLS_LANG设置,服务器端的数据库Oracle字符集设置这三者有关,如果它们的设置不一致或者某个设置错误,就会很容易出现乱码,下面我们简要介绍以下几种情况:

 

1、数据库字符集设置不当引起的乱码:

 

例如:一个存储简体中文字符的数据库,它的字符集选用了US7ASCII,当它的客户端NLS_LANG也选用US7ASCII时,这个系统单独使用是没有问题的,因为两者设置一致,因此ORACLE不会进行字符集的转换,客户输入的GBK码被直接在数据库中存储起来,当查询数据时,实际客户端取出来的数据也是GBK的编码,因此显示也是正常的。

但当其它的系统需要从这个数据库取数据,或者它的数据要EXP出来,IMP到其它数据库时,问题就会开始出现了。其它系统的Oracle字符集一般是ZHS16GBK,或者其它系统客户端的NLS_LANG设置为ZHS16GBK,此时必然会产生字符集的转换。虽然数据库字符集设置为US7ASCII,但我们知道,实际存储的数据编码是ZHS16GBK的。

可惜ORACLE不会知道,它会把存储的ZHS16GBK编码数据当作US7ASCII编码的数据,按照US7ASCII转换成ZHS16GBK的转换算法进行转换,可以想象,这种情况下,乱码的产生是必然的。

 

2、数据库字符集与客户端NLS_LANG设置不同引起的乱码:

例如:对于一个需要存储简体文信息的数据库来说,它的字符集设置和客户端NLS_LANG设置一般可以使用ZHS16GBK编码。但是如果数据库字符集选用了UTF8的话,也是可以的,因为ZHS16GBK编码属于UTF8的子集。ORACLE在数据库与客户端进行数据交换时自动进行编码的转换,在数据库中实际存储的也是UTF8编码的数据。

此时其它数据库和此数据库也可以正常的进行数据交换,因为ORACLE会自动进行数据的转换。在实际使用中,遇到过繁体XP的字符集ZHT16MSWIN950转换成AL32UTF8字符集时,一些特殊的字符和个别冷僻的汉字会变成乱码。后来证实是XP需要安装一个字库补丁软件,***顺利解决此问题。

 

3、客户端NLS_LANG与本地化环境不同引起的乱码:

一般情况下,客户端NLS_LANG与本地化环境采用了不同的字符集会出现乱码,除非本地化环境的字符集是客户端NLS_LANG设置字符集的子集。如果把客户端NLS_LANG设置为UTF8就属于这种情况,由于目前还没有可以直接使用UNICODE字符集的操作系统,因此客户本地化环境使用的Oracle字符集只能是某种语言支持的字符集,它属于UTF8的子集。下面我们就着重讨论这种情况。

 

虽然目前WINDOWS的内核是支持UNICODE的,但是WINDOWS并不支持直接显示UNICODE编码的字符,而且它并不知道目前的字符采用了何种字符集,所以默认情况下,它使用缺省的代码页来解释字符。因此,对于其它类型的编码,需要先进行转换,变成系统目前的缺省代码页支持的字符集才能正常使用。

 

WINDOWS中的缺省代码页是由控制面板设置中的语言及区域的选择所决定的,属于客户本地化的环境设置。简体中文WINDOWS的字符编码就是GBK,它的缺省代码页是936。对于其它非WINDOWS的操作系统,我们可以把它们目前缺省使用的Oracle字符集作为用户的本地化环境设置。

另外,我们使用的大部分工具,如写字板,SQL*PLUS等,它们没有提供编码转换功能,因此在客户端直接输入或查询数据往往都会遇到乱码的问题,必须由应用程序或一些工具去做编码的转换,才能保证正常的使用。

【编辑推荐】

  1. Oracle创建Split 与Map 函数的代码示例
  2. Oracle索引整理的详细描述
  3. Oracle 权限入门如何管理
  4. Oracle 10G for linux常用命令浅析
  5. Oracle数据库缓冲区命中率的概述
责任编辑:佚名 来源: 博客园
相关推荐

2010-04-07 09:21:03

Oracle RAC

2010-04-13 12:42:59

Oracle连接

2010-04-22 09:08:30

Oracle 8i

2010-04-13 13:41:47

Oracle 字符集

2010-05-05 17:29:40

Oracle 8i

2010-05-05 11:06:32

Oracle存储过程

2009-07-29 13:42:04

Oracle中文显示

2010-04-13 13:11:34

Oracle汉字显示

2011-04-11 10:59:33

Oracle字符集

2010-04-21 16:07:16

Oracle 8i

2010-06-10 13:34:17

MySQL5

2010-05-04 15:59:05

Oracle字符集

2011-04-11 11:05:12

Oracle字符集

2010-05-11 13:25:18

Mysql大小写

2009-11-20 16:52:35

Oracle字符集

2010-04-30 10:16:22

Oracle字符集

2011-05-20 13:24:39

oracle字符集

2010-04-28 17:29:07

Oracle字符集

2010-06-17 14:16:24

SQL Server补

2010-05-06 14:40:59

Oracle字符集
点赞
收藏

51CTO技术栈公众号