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等，它们没有提供编码转换功能，因此在客户端直接输入或查询数据往往都会遇到乱码的问题，必须由应用程序或一些工具去做编码的转换，才能保证正常的使用。

【编辑推荐】