oracle经典乱码问题——靠靠靠靠

         最近在做一个项目的时候，遇到了一个问题，在window 2003 系统oracle 11g数据库进行select的时候，结果为“靠靠靠靠”，当时的运维人员对oracle不太了解，所以就找到了我，我查看服务端与客户端的字符集，发现服务端为zhs16gbk,客户端为american_america.we8iso8858p1，当我把客户端修改与服务端一致字符集的时候，问题解决了。

下面是我做的一个技术文档，为以后的人员学习oracle做个实例说明。

环境为：

window 2003 32系统、oracle 11g数据库

1、连接windows 2003的oracle 11g

C:\>sqlplus / as sysdba

 SQL*Plus: Release 11.2.0.1.0 Production on 星期一 5月 21 15:03:29 2012

 Copyright (c) 1982, 2010, Oracle. All rights reserved.

 连接到:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

2、查看客户端的字符集

SQL> select userenv('language') from dual;  

USERENV('LANGUAGE')  

----------------------------------------------------  

AMERICAN_AMERICA.ZHS16GBK  

3、查看服务端的字符集

SQL> set linesize 100  

SQL> col parameter for a40  

SQL> col value for a40  

SQL> select * from nls_database_parameters where parameter like '%CHARACTERSET%%';  

PARAMETER                VALUE  

---------------------------------------- ----------------------------------------  

NLS_CHARACTERSET             ZHS16GBK  

NLS_NCHAR_CHARACTERSET       AL16UTF16  

可以看到客户端与服务端的字符集都是一致的，均为ZHS16GBK。

4、创建dl_char表

SQL> create table dl_char (name varchar2(20));  

表已创建。  

5、插入数据

SQL> insert into dl_char values ('字符集的乱码问题');  

已创建 1 行。  

6、进行select查询

SQL> select * from dl_char;  

NAME  

--------------------  

字符集的乱码问题  

可以看得，现在显示为我刚才输入的值

7、更改客户端的字符集

C:\>SET NLS_LANG=AMERICAN_AMERICA.WE8ISO8859P1 

8、然后重新登录

C:\>sqlplus / as sysdba  

SQL*Plus: Release 11.2.0.1.0 Production on Mon May 21 15:06:55 2012  

Copyright (c) 1982, 2010, Oracle.  All rights reserved.  

Connected to:  

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production  

With the Partitioning, OLAP, Data Mining and Real Application Testing options  

9、查看客户端的字符集

SQL> select userenv('language') from dual;  

USERENV('LANGUAGE')  

----------------------------------------------------  

AMERICAN_AMERICA.ZHS16GBK  

可以看到客户端的字符集已经变为AMERICAN_AMERICA.ZHS16GBK了

10、然后查看dl_char的值

SQL> select * from dl_char;  

NAME  

--------------------  

靠靠靠靠  

现在就出现了我前面说的4个靠字的问题，从上面的实验，可以看到产生4靠的原因为：客户端与服务端的字符集不一致，所以解决这个问题的方法就是在客户端设置与服务端一致的字符集

11、现在把客户端的字符集改成与服务端一致的字符集

C:\>SET NLS_LANG=ZHS16GBK 

12、然后登陆

C:\>sqlplus / as sysdba  

SQL*Plus: Release 11.2.0.1.0 Production on 星期一 5月 21 15:13:11 2012  

Copyright (c) 1982, 2010, Oracle.  All rights reserved.  

连接到:  

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production  

With the Partitioning, OLAP, Data Mining and Real Application Testing options  

13、查看客户端与服务端的字符集

SQL> select userenv('language') from dual;  

USERENV('LANGUAGE')  

----------------------------------------------------  

SIMPLIFIED CHINESE_CHINA.ZHS16GBK  

SQL> select * from nls_database_parameters where parameter like '%CHARACTERSET%%';  

PARAMETER                VALUE  

---------------------------------------- ----------------------------------------  

NLS_CHARACTERSET             ZHS16GBK  

NLS_NCHAR_CHARACTERSET       AL16UTF16  

14、现在客户端与服务端的字符集都一致了，在查看一下dl_char里的内容

SQL> select * from dl_char;  

NAME  

--------------------  

字符集的乱码问题  

         现在显示为正常的、我之前输入的值了，4个靠字也没用在出现，所以提醒大家一下，以后在做exp/imp导出/导入或者客户端查询数据等操作的时候，一定要把客户端的字符集与服务端的字符集设置为同一个。

©著作权归作者所有：来自51CTO博客作者dl528888的原创作品，如需转载，请注明出处，否则将追究法律责任

靠靠靠靠oracle 4靠解决方法oracle应用专题