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
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

Oracle真实案例之闪回区存储空间耗尽解决方法（ORA-19815解决方法）Oracle database filesystem （DBFS）简单配置文档相关资讯 Oracle存储过程

Oracle存储过程拼接in语句 & 自定（今 09:21）
【PL/SQL系列】Oracle存储过程使用（04月23日）
Oracle存储过程及Java调用（05/28/2015 20:29:33）

Java调用Oracle存储过程返回多条结（04月29日）
Oracle中的存储过程简单应用（04月10日）
判断点是否落在面中的Oracle存储过（05/09/2015 09:39:30）

本文评论查看全部评论（0）

评论声明

尊重网上道德，遵守中华人民共和国的各项有关法律法规
承担一切因您的行为而直接或间接导致的民事或刑事法律责任