详细介绍oracle数据库字符集

一 什么是oracle字符集

Oracle字符集是一个字节数据的解释的符号集合 有大小之分 有相互的包容关系 ORACLE 支持国家语言的体系结构允许你使用本地化语言来存储 处理 检索数据 它使数据库工具 错误消息 排序次序 日期 时间 货币 数字 和日历自动适应本地化语言和平台

影响oracle数据库字符集最重要的参数是NLS_LANG参数 它的格式如下:

NLS_LANG = language_territory charset

它有三个组成部分(语言 地域和字符集) 每个成分控制了NLS子集的特性 其中:

Language 指定服务器消息的语言 territory 指定服务器的日期和数字格式 charset 指定字符集 如:AMERICAN _ AMERICA ZHS GBK

从NLS_LANG的组成我们可以看出 真正影响数据库字符集的其实是第三部分 所以两个数据库之间的字符集只要第三部分一样就可以相互导入导出数据 前面影响的只是提示信息是中文还是英文

二 如何查询Oracle的字符集

很多人都碰到过因为字符集不同而使数据导入失败的情况 这涉及三方面的字符集 一是oracel server端的字符集 二是oracle client端的字符集三是dmp文件的字符集 在做数据导入的时候 需要这三个字符集都一致才能正确导入

查询oracle server端的字符集

有很多种方法可以查出oracle server端的字符集 比较直观的查询方法是以下这种:SQL>select userenv( language ) from dual

结果类似如下:AMERICAN _ AMERICA ZHS GBK

如何查询dmp文件的字符集

用oracle的exp工具导出的dmp文件也包含了字符集信息 dmp文件的第 和第 个字节记录了dmp文件的字符集 如果dmp文件不大 比如只有几M或几十M 可以用UltraEdit打开( 进制方式) 看第 第 个字节的内容 如 然后用以下SQL查出它对应的字符集:

SQL>select nls_charset_name(to_number( xxxx )) from dual

ZHS GBK

如果dmp文件很大 比如有 G以上(这也是最常见的情况) 用文本编辑器打开很慢或者完全打不开 可以用以下命令(在unix主机上):

cat exp dmp |od x|head |awk {print $ $ } |cut c

然后用上述SQL也可以得到它对应的字符集

查询oracle client端的字符集

这个比较简单 在windows平台下 就是注册表里面相应OracleHome的NLS_LANG 还可以在dos窗口里面自己设置 比如:

set nls_lang=AMERICAN_AMERICA ZHS GBK

这样就只影响这个窗口里面的环境变量

在unix平台下 就是环境变量NLS_LANG

$echo $NLS_LANG

AMERICAN_AMERICA ZHS GBK

如果检查的结果发现server端与client端字符集不一致 请统一修改为同server端相同的字符集

三 修改oracle的字符集

上文说过 oracle的字符集有互相的包容关系 如us ascii就是zhs gbk的子集 从us ascii到zhs gbk不会有数据解释上的问题 不会有数据丢失 在所有的字符集中utf 应该是最大 因为它基于unicode 双字节保存字符(也因此在存储空间上占用更多)

一旦数据库创建后 数据库的字符集理论上讲是不能改变的 因此 在设计和安装之初考虑使用哪一种字符集十分重要 根据Oracle的官方说明 字符集的转换是从子集到超集受支持 反之不行 如果两种字符集之间根本没有子集和超集的关系 那么字符集的转换是不受oracle支持的 对数据库server而言 错误的修改字符集将会导致很多不可测的后果 可能会严重影响数据库的正常运行 所以在修改之前一定要确认两种字符集是否存在子集和超集的关系 一般来说 除非万不得已 我们不建议修改oracle数据库server端的字符集 特别说明 我们最常用的两种字符集ZHS GBK和ZHS CGB 之间不存在子集和超集关系 因此理论上讲这两种字符集之间的相互转换不受支持

修改server端字符集(不建议使用)

在oracle 之前 可以用直接修改数据字典表props$来改变数据库的字符集 但oracle 之后 至少有三张系统表记录了数据库字符集的信息 只改props$表并不完全 可能引起严重的后果 正确的修改方法如下:

$sqlplus /nolog

SQL>conn / as sysdba

若此时数据库服务器已启动 则先执行SHUTDOWN IMMEDIATE命令关闭数据库服务器 然后执行以下命令:

SQL>STARTUP MOUNT

SQL>ALTER SYSTEM ENABLE RESTRICTED SESSION

SQL>ALTER SYSTEM SET JOB_QUEUE_PROCESSES=

SQL>ALTER SYSTEM SET AQ_TM_PROCESSES=

SQL>ALTER DATABASE OPEN

SQL>ALTER DATABASE CHARACTER SET ZHS GBK

SQL>ALTER DATABASE national CHARACTER SET ZHS GBK

SQL>SHUTDOWN IMMEDIATE

SQL>STARTUP

修改dmp文件字符集

上文说过 dmp文件的第 第 字节记录了字符集信息 因此直接修改dmp文件的第 第 字节的内容就可以 骗 过oracle的检查 这样做理论上也仅是从子集到超集可以修改 但很多情况下在没有子集和超集关系的情况下也可以修改 我们常用的一些字符集 如US ASCII WE ISO P ZHS CGB ZHS GBK基本都可以改 因为改的只是dmp文件 所以影响不大

具体的修改方法比较多 最简单的就是直接用UltraEdit修改dmp文件的第 和第 个字节 比如想将dmp文件的字符集改为ZHS GBK 可以用以下SQL查出该种字符集对应的 进制代码:

SQL>select to_char(nls_charset_id( ZHS GBK ) xxxx ) from dual

然后将dmp文件的 字节修改为 即可

lishixinzhi/Article/program/Oracle/201311/17875

在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>MITCommit plete SQL> 服务器指定字符集与客户字符集相同 与加载数据字符集不一致 解决方法 强制加载数据字符集与服务器端字符集一致 要做到这一点 可以通过重新创建数据库 并选择与原卸出数据一致的字符集 然后IMP数据 这种情况仅仅适用于空库和具有同一种字符集的数据 解决这类问题 也可以先将数据加载到具有相同字符集的服务器上 然后用转换工具卸出为foxbase 格式或access格式数据库 再用转换工具转入到不同字符集的Oracle数据库中 这样就避免了Oracle字符集的困扰 目前数据库格式转换的工具很多 像power builder 以上版本提供的pipeline及Microsoft Access数据库提供的数据导入/导出功能等 服务器指定字符集与客户字符集不同 与输入数据字符集不一致 对于这种情况 目前为止都还没有太好的解决方法 通过上面的了解 我们知道 导致在后期使用数据库时出现种种关于字符集的问题 多半是由于在数据库设计 安装之初没有很好地考虑到以后的需要 所以 我们完全可以通过在服务器上和客户端使用相同的字符集来避免由此类问题引出的麻烦 lishixinzhi/Article/program/Java/hx/201311/27019

---