Iorcale乱码原因与解决方法.docxVIP

解决方法1、insert之前先设定nls_lang环境变量为中文，然后再插入中文数据export NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS16GBKorexport NLS_LANG=SIMPLIFIED CHINESE_CHINA.ZHS32GB18030如果这样后，反而插不进去，或者仍然为乱码，表示当初再建库时，没有选择中文字符集（export NLS_LANG=AMERICAN_AMERICA.AL32UTF8）2、dbca一个新库，在字符集处选择中文3、强行修改服务器端ORACLE当前字符集（此方法没有试过，但应该是要在安装db的时候已经安装了此字符集，属猜测）在用cmp命令加载数据前，先在客户端用sql*plus登录system DBA用户，执行下列SQL语句进行当前ORACLE数据库字符集修改：SQL ; create database character set US7ASCII　*?create?database?character?set?US7ASCII???ERROR?at?line?1:???ORA-01031:?insufficient?privileges?你会发现语句执行过程中，出现上述错误提示信息，此时不用理会，实际上ORACLE数据库的字符集已被强行修改为US7ASCII，接着用cmp命令装载数据。等数据装载完成以后，shutdown 数据库，再startup 数据库，用合法用户登录ORACLE数据库，在sql;命令提示符下，运行select * from V$NLS_PARAMETERS，可以看到ORACLE数据库字符集已复原，这时再查看有汉字字符数据的表时，汉字已能被正确显示。????4、利用数据格式转储，避开字符集限制这种方法主要用于加载外来ORACLE数据库的不同字符集数据。其方法如下：先将数据加载到具有相同字符集的服务器上，然后用转换工具卸出为foxbase 格式或Access格式数据库，再用转换工具转入到不同字符集的ORACLE数据库中，这样就避免了ORACLE字符集的困扰。目前数据库格式转换的工具很多,象Power Builder5.0以上版本提供的oracle中的数据库乱码的原因与解决??“在SQL*Plus中用insert插进的都是中文的，为什么一存入服务器后，再select出的就是???”　　　　“有的时候，服务器数据先导出，重装服务器，再导入数据，结果，发生数据查询成???”　　　　……　　　　这些问题，一般是因为字符集设置不对造成的。　　　　很久以来，字符集一直是困扰着众多Oracle爱好者的问题，笔者从事Oracle数据库管理和应用已经几年了，经常接到客户的类似上面提到的有关数据库字符集的“告急”和“求救”，在此我们就这个问题做一些分析和探讨。　　　　首先，我们要明确什么是字符集？字符集是一个字节数据的解释的符号集合,有大小之分,有相互的包括关系,如us7ascii就是zhs16gbk的子集,从us7ascii到zhs16gbk不会有数据解释上的问题,不会有数据丢失,Oracle对这种问题也要求从子集到超集的导出受支持,反之不行。在所有的字符集中utf8应该是最大,因为它基于unicode,双字节保存字符(也因此在存储空间上占用更多)。　　　　其次，一旦数据库创建后，数据库的字符集是不能改变的。因此，在设计和安装之初考虑使用哪一种字符集是十分重要的。数据库字符集应该是操作系统本地字符集的一个超集。存取数据库的客户使用的字符集将决定选择哪一个超集，即数据库字符集应该是所有客户字符集的超集。Bbs.Svn8.Com　　　　在实际应用中，和字符集问题关系最大的恐怕就是exp/imp了。在做exp/imp时，如果Client 和Server的nls_lang设置是一样的，一般就没有问题的。但是，要在两个不同字符集的系统之间导数据就经常会有这样或那样的问题，如，导出时数据库的显示正常，是中文，当导入到其他系统时，就成了乱码，这也是一类常见问题。　　　　现在，介绍一些与字符集有关的NLS_LANG参数，　　　　NLS_LANG格式：　　NLS_LANG = language_territory.charset　　　　有三个组成部分（语言、地域和字符集），每个成分控制了NLS子集的特性。其中：language 指定服务器消息的语言。　　　　territory 指定服务器的日期和数字格式。　　　　charset 指定字符集　　　　例如：　　　AMERICAN_AMERICA.US7SCII　　　　AMERICAN_AMERICA.ZHS16GBK　　　　　　还有一些子集可以更明确定义NLS_LANG参数：　　　DICT.BASE 数据字典基本 表版本