oracle数据库中文乱码 oracle中的数据库乱码的原因与解决
这篇文章给大家聊聊关于oracle数据库中文乱码，以及oracle中的数据库乱码的原因与解决对应的知识点，希望对各位有所帮助，不要忘了收藏本站哦。
如何解决Oracle数据库中文乱码问题
1.服务器指定字符集与客户字符集不同，而与加载数据字符集一致。
解决方法：对于这种情况，只需要设置客户端字符集与服务器端字符集一致就可以了，具体操作如下：
*查看当前字符集：
SQL> select* from sys.props$
2 WHERE NAME=‘NLS_CHARACTERSET’;
NAME value$
NLS_CHARACTERSET ZHS16GBK
可以看出，现在服务器端Oracle数据库的字符集为‘ZHS16GBK’
*根据服务器的字符集在客户端作相应的配置或者安装Oracle的客户端软件时指定：
如果还没安装客户端，那么在安装客户端时，指定与服务器相吻合的字符集即可；如果已经安装好了客户端，并且客户端为 sql*net 2.0以下版本，进入Windows的系统目录，编辑oracle.ini文件，用US7ASCII替换原字符集，重新启动计算机，设置生效；否则，如果，客户端为 sql*net 2.0以上版本，在Win98下运行REGEDIT,第一步选HKEY_LOCAL_MACHINE,第二步选择SOFTWARE，第三步选择 Oracle，第四步选择 NLS_LANG，键入与服务器端相同的字符集
（本例为：HKEY_LOCAL_MACHINE/
SOFTWARE/ORACLE/NLS_LANG：AMERICAN _ AMERICA. ZHS16GBK）。
如果是UNIX客户端，则：
SQL> conn/ as sysdba
Connected.
SQL> SQL> UPDATE sys.PROPS$ SET value$=‘SIMPLIFIED CHINESE’
2 WHERE NAME=‘NLS_LANGUAGE’;
2.服务器指定字符集与客户字符集相同,与加载数据字符集不一致。
解决方法：强制加载数据字符集与服务器端字符集一致。要做到这一点，可以通过重新创建数据库，并选择与原卸出数据一致的字符集，然后IMP数据，这种情况仅仅适用于空库和具有同一种字符集的数据。
解决这类问题，也可以先将数据加载到具有相同字符集的服务器上，然后用转换工具卸出为foxbase格式或access格式数据库，再用转换工具转入到不同字符集的Oracle数据库中，这样就避免了Oracle字符集的困扰。目前数据库格式转换的工具很多,像power builder5.0以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等。
3.服务器指定字符集与客户字符集不同,与输入数据字符集不一致。
对于这种情况，目前为止都还没有太好的解决方法。
通过上面的了解，我们知道，导致在后期使用数据库时出现种种关于字符集的问题，多半是由于在数据库设计、安装之初没有很好地考虑到以后的需要，所以，我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦
怎样修改查看Oracle字符集
a.数据库服务器字符集select* from nls_database_parameters，其来源于props$，是表示数据库的字符集。
b.客户端字符集环境select* from nls_instance_parameters,其来源于v$parameter，
表示客户端的字符集的设置，可能是参数文件，环境变量或者是注册表
c.会话字符集环境 select* from nls_session_parameters，其来源于v$nls_parameters，表示会话自己的设置，可能是会话的环境变量或者是alter session完成，如果会话没有特殊的设置，将与nls_instance_parameters一致。
客户端的字符集要求与服务器一致，才能正确显示数据库的非Ascii字符。如果多个设置存在的时候，alter session>环境变量>注册表>参数文件
实际情况
我用select* from nls_database_parameters
PARAMETER VALUE
------------------------------------------------------------
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY$
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS.,
NLS_CHARACTERSET ZHS16GBK
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
PARAMETER VALUE
------------------------------------------------------------
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY$
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET AL16UTF16
NLS_RDBMS_VERSION 10.2.0.1.0
说明我在创建数据库时指定的字符集是ZHS16GBK，我用
update sys.props$ set value$='AL32UTF8' where name='NLS_CHARACTERSET';
修改了字符集，但插入中文时仍然有问题，这或许就如上面资料所说的通过修改SYS.PROPS$来修改主要是对应客户端的显示，与存储无关，
所以仍旧是乱码。
然后我重新创建了个数据库，指定字符集为AL32UTF8，插入中文就没问题了。
可见我们如果要在数据库中显示中文，在创建数据库时一定哟指定好所用的字符集。
oracle数据库中文乱码怎么解决
在Oracle数据库中出现中文乱码的情况，可能是因为以下几个方面：
字符集不匹配：Oracle数据库默认使用的字符集为AL32UTF8，如果在创建数据库或者表时没有指定字符集或者指定了其他的字符集，则可能会出现乱码问题。在创建表时，可以使用以下语句指定字符集：
CREATE TABLE table_name(column_name1 data_type1,
column_name2 data_type2,
...
) CHARACTER SET utf8;
数据库连接时没有指定字符集：在连接数据库时，如果没有指定字符集，可能会出现乱码问题。在连接数据库时，可以使用以下语句指定字符集：
DriverManager.getConnection(url, user, password).createStatement();statement.execute("SET NAMES'utf8'");
字段类型不匹配：在创建表时，如果字段类型不匹配，也可能会导致乱码问题。例如，在使用VARCHAR2类型存储中文字符时，需要指定字符长度，如果长度不够，则可能会出现乱码问题。
如果出现了中文乱码问题，可以使用以下方法解决：
修改字符集：在创建表时，指定正确的字符集；或者在连接数据库时，指定正确的字符集。
修改字段类型：如果存储中文字符的字段类型不正确，可以修改字段类型为NVARCHAR2或者NCHAR类型，这两种类型都支持Unicode字符集，可以正确存储中文字符。
修改数据：如果出现了中文乱码问题，可以通过修改数据的方式解决。可以使用UPDATE语句更新乱码数据，或者使用INSERT语句重新插入正确的数据。
解决中文乱码问题的方法有很多种，需要根据具体情况来选择合适的方法。
oracle中的数据库乱码的原因与解决
在SQL*Plus中用insert***的都是中文的为什么一存入服务器后再select出的就是???有的时候服务器数据先导出重装服务器再导入数据结果发生数据查询成???……这些问题一般是因为字符集设置不对造成的很久以来字符集一直是困扰著众多Oracle爱好者的问题笔者从事Oracle数据库管理和应用已经几年了经常接到客户的类似上面提到的有关数据库字符集的告急和求救在此我们就这个问题做一些分析和探讨首先我们要明确什么是字符集？字符集是一个字节数据的解释的符号集合有大小之分有相互的包括关系如us ascii就是zhs gbk的子集从us ascii到zhs gbk不会有数据解释上的问题不会有数据丢失 Oracle对这种问题也要求从子集到超集的导出受支持反之不行在所有的字符集中utf应该是最大因为它基于unicode双字节保存字符(也因此在存储空间上占用更多)其次一旦数据库创建后数据库的字符集是不能改变的因此在设计和安装之初考虑使用哪一种字符集是十分重要的数据库字符集应该是操作系统本地字符集的一个超集存取数据库的客户使用的字符集将决定选择哪一个超集即数据库字符集应该是所有客户字符集的超集在实际应用中和字符集问题关系最大的恐怕就是exp/imp了在做exp/imp时如果Client和Server的nls_lang设置是一样的一般就没有问题的但是要在两个不同字符集的系统之间导数据就经常会有这样或那样的问题如导出时数据库的显示正常是中文当导入到其他系统时就成了乱码这也是一类常见问题现在介绍一些与字符集有关的NLS_LANG参数 NLS_LANG格式 NLS_LANG= language_territory charset有三个组成部分（语言地域和字符集）每个成分控制了NLS子集的特性其中 language指定服务器消息的语言 territory指定服务器的日期和数字格式 charset指定字符集例如 AMERICAN_AMERICA US SCII AMERICAN _ AMERICA ZHS GBK还有一些子集可以更明确定义NLS_LANG参数 DICT BASE数据字典基本表版本 DBTIMEZONE数据库时区 NLS_LANGUAGE语言 NLS_TERRITORY地域 NLS_CURRENCY本地货币字符 NLS_ISO_CURRENCY ISO货币字符 NLS_NUMERIC_CHARACTERS小数字符和组分隔开 NLS_CHARACTERSET字符集 NLS_CALENDAR日历系统 NLS_DATE_FORMAT缺省的日期格式 NLS_DATE_LANGUAGE缺省的日期语言 NLS_SORT字符排序序列 NLS_TIME_FORMAT时间格式 NLS_TIMESTAMP_FORMAT时间戳格式……通过props$动态性能视图我们可以查看数据库的字符集信息$> sqlplus internal SQL> desc props$ Name Type Nullable Default Comments NAME VARCHAR() VALUE$ VARCHAR() Y MENT$ VARCHAR() Y SQL> set arraysize SQL> col value$ format a SQL> select name value$ from props$ where name= NLS_CHARACTERSET; NAME VALUE$ NLS_CHARACTERSET ZHS GBK SQL> select* from sys props$; NAME VALUE$ DICT BASE DBTIMEZONE: NLS_LANGUAGE AMERICAN NLS_TERRITORY AMERICA NLS_CURRENCY$ NLS_ISO_CURRENCY AMERICA NLS_NUMERIC_CHARACTERS NLS_CHARACTERSET ZHS GBK NLS_CALENDAR GREGORIAN NLS_DATE_FORMAT DD MON RR NLS_DATE_LANGUAGE AMERICAN NLS_SORT BINARY NLS_TIME_FORMAT HH MI SSXFF AM NLS_TIMESTAMP_FORMAT DD MON RR HH MI SSXFF AM NLS_TIME_TZ_FORMAT HH MI SSXFF AM TZH:TZM NLS_TIMESTAMP_TZ_FORMAT DD MON RR HH MI SSXFF AM TZH:TZM NLS_DUAL_CURRENCY$ NLS_P BINARY NLS_NCHAR_CHARACTERSET ZHS GBK NLS_RDBMS_VERSION NAME VALUE$ GLOBAL_DB_NAME SCPDB EXPORT_VIEWS_VERSION rows selected SQL>从结果可以看出 NLS_LANG= AMERICAN _ AMERICA ZHS GBK虽然数据库的字符集是在create database的时候指定的以后不允许改变但在一个已经建立好的数据库上我们可以通过修改SYS PROPS$来修改主要是对应客户端的显示与存储无关如 SQL> conn/ as sysdba Connected SQL> SQL> select* from sys props$ WHERE NAME= NLS_LANGUAGE; NAME VALUE$ NLS_LANGUAGE AMERICAN SQL> SQL> UPDATE sys PROPS$ SET VALUE$= SIMPLIFIED CHINESE WHERE NAME= NLS_LANGUAGE; row updated SQL> SQL> select* from sys props$ WHERE NAME= NLS_LANGUAGE; NAME VALUE$ NLS_LANGUAGE SIMPLIFIED CHINESE SQL>通常出现问题的原因可分为三种服务器指定字符集与客户字符集不同而与加载数据字符集一致解决方法对于这种情况只需要设置客户端字符集与服务器端字符集一致就可以了具体操作如下*查看当前字符集 SQL> select* from sys props$ WHERE NAME= NLS_CHARACTERSET; NAME VALUE$ NLS_CHARACTERSET ZHS GBK SQL>可以看出现在服务器端Oracle数据库的字符集为 ZHS GBK*根据服务器的字符集在客户端作相应的配置或者安装Oracle的客户端软件时指定如果还没安装客户端那么在安装客户端时指定与服务器相吻合的字符集即可如果已经安装好了客户端并且客户端为 sql*net以下版本进入Windows的系统目录编辑oracle ini文件用US ASCII替换原字符集重新启动计算机设置生效否则如果客户端为 sql*net以上版本在Win下运行REGEDIT第一步选HKEY_LOCAL_MACHINE第二步选择SOFARE第三步选择 Oracle第四步选择 NLS_LANG键入与服务器端相同的字符集（本例为 HKEY_LOCAL_MACHINE\ SOFARE\ORACLE\NLS_LANG AMERICAN _ AMERICA ZHS GBK）如果是UNIX客户端则 SQL> conn/ as sysdba Connected SQL> SQL> UPDATE sys PROPS$ SET VALUE$= SIMPLIFIED CHINESE WHERE NAME= NLS_LANGUAGE; row updated SQL> MIT; Commit plete SQL>服务器指定字符集与客户字符集相同与加载数据字符集不一致解决方法强制加载数据字符集与服务器端字符集一致要做到这一点可以通过重新创建数据库并选择与原卸出数据一致的字符集然后IMP数据这种情况仅仅适用于空库和具有同一种字符集的数据解决这类问题也可以先将数据加载到具有相同字符集的服务器上然后用转换工具卸出为foxbase格式或access格式数据库再用转换工具转入到不同字符集的Oracle数据库中这样就避免了Oracle字符集的困扰目前数据库格式转换的工具很多像power builder以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等服务器指定字符集与客户字符集不同与输入数据字符集不一致对于这种情况目前为止都还没有太好的解决方法通过上面的了解我们知道导致在后期使用数据库时出现种种关于字符集的问题多半是由于在数据库设计安装之初没有很好地考虑到以后的需要所以我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦 lishixinzhi/Article/program/Java/hx/201311/27019
好了，关于oracle数据库中文乱码和oracle中的数据库乱码的原因与解决的问题到这里结束啦，希望可以解决您的问题哈！