|
关于字符集的一些问题：
博主最近开始学习oracle啦，不得不说oracle的内容真的太广了，学好它不仅仅是数据库本身的问题，好多时候会牵扯各种操作系统，记得刚刚在redhat下开始安装oracle的时候差不多鼓捣了一天啊！OK，言归正传，最近博主在测试一些简单的SQL语句时发现一个问题：
哇哦，这是什么鬼，不能识别我大天朝的语言吗？吓得我赶快从网上查了查原因，貌似牵扯字符集的原因？其实很简答啦，仅仅是在安装数据库的时候字符设置默认语言没有选对！
（这里字符集要解释一下:字符集（也称字元集，Character Set）就是字符编码表(codepage)，一个字符不论英文、中文、韩文等在计算机系统内存或硬盘中通过二进制的字节（Byte）保存，这个二进制的编码就是字符编码（也称内码），字符集就是字符与内码的对应（映射）表。
因为多国语言的原因，就出现了根据本国语言制作的字符集。如使用最广泛的ASCII编码，由美国国家标准局(即ANSI)制定，适用于所有拉丁、英文字符。中国大陆使用GB2312,GBK,GB18030等字符集，这些字符集包含所有汉字字符的内码，其中GBK,GB18030称为大字符集，对繁体中文也进行了编码。香港、台湾、澳门地区使用Big5编码，Big5收录了繁体中文（有些繁体与中国大陆繁体字符有差异）的编码，不包含简体中文的字符编码。
本段话转自：
http://www.cnblogs.com/zhwl/p/3745257.html）
utf-8:可变长度,当utf-8用来表示英文时,会直接使用一位字节来表示,但是查询汉字的时候可能使用多位字节来表示
utf-16:固定长度,全部使用两位字节来表示,这样的话表示英文会很占空间,但是读起来会更快
上图中database character set 即为数据库字符集的设置（要注意，以上为服务器端的字符集设置。客户端的字符集则是在用户的环境变量中），若使用默认的话，若插入数据库汉字，查询时会出现乱码的情况（原因见后面描述）。这里的选项为包含所有汉字字符的GBK字符集。
characterset:控制客户端应用程序使用的字符集。最后一个选项defult territory也好理解，这个是选择的地区，会对货币和数字格式，地区和计算星期及日期的习惯等有影响，而defualt language 有什么作用呢？它其实是对Oracle消息使用的语言，日期中月份和日显示有影响的。
服务端字符集的构成体现在数据字典表V$NLS_PARAMETERS的NLS_LANGUAGE、NLS_TERRITORY、NLS_CHARACTERSET三项取值上，其中NLS_CHARACTERSET的取值就是具体的数据库字符集。如利用查询语句SQL>SELECT * FROM V$NLS_PARAMETERS;可得到如下结果：
PARAMETER VALUE
NLS_LANGUAGE SIMPLIFIED CHINESE
NLS_TERRITORY CHINA
NLS_CHARACTERSET ZHS16GBK
即当前数据库使用的字符集是ZHS16GBK。
Ps:根据ORACLE官方文档的说明，一旦数据库创建后，数据库的字符集是不能改变的。数据库服务端的字符集是在创建数据时设定的。但可通过如下方法对已设定的字符集进行修改：
方法一：重建数据库。建立数据库时将数据库的字符集设定为所需字符集。
方法二：修改SYS.PROPS$表。即用SYS用户登陆ORACLE后，利用下面语句修改相应的字符集并提交：SQL>UPDATE PROPS$ SET VALUE$=’ZHS16GBK‘WHERE NAME=’NLS_CHARACTERSET’;SQL>COMMIT;通过此种方法来更改数据库字符集，只对更改后的数据有效，即数据库中原来的数据仍以原字符集被存储。【很野的路子！改的是oracle的基表】
在SQL语句中可以使用：SQL>select userenv (‘language’) from dual;
来查询，比如，
查询客户端字符集：$echo $NLS_LANG $env | grep NLS_LANG
1、可以在.bash_profile 文件中添加：export NLS_LANG=AMERICAN_AMERICA.ZHS16GBK的方法来更改（永久设置 instance级别？）
2、alter session set nls_language='american' nls_territory='america';
alter session set nls_language='american';
alter session set nls_territory='america';（session级别）
操作系统字符集：
查看：echo $LANG / env | grep LANG
GDM - The GNOME Display Manager
G:图形 D:桌面 M:管理器
1、直接设置变量的方式修改，命令如下两条命令：
[root@david ~]# LANG=xxx 或者 export LANG=xxx；
[root@david ~]# LC_ALL=”xxx” 或者 export LC_ALL=”xxx”；
2、修改文件方式，通过修改/etc/sysconfig/i18n文件控制
[root@david ~]# vim /etc/sysconfig/i18n
LANG="zh_CN.GB18030" 即为系统的语言
SUPPORTED="zh_CN.UTF-8:zh_CN.GB18030:zh_CN:zh:en_US.UTF-8:en_US:en"
SYSFONT="lat0-sun16"
修改文件保存退出之后要生效要执行如下命令才可生效
[test@pan ~]$ source /etc/sysconfig/i18n
问题：
如果操作系统字符集与客户端字符集不一致会怎么样？
通过SQL> select userenv ('language') from dual;查询出USERENV('LANGUAGE')AMERICAN_AMERICA.ZHS16GBK其中AMERICAN_AMERICA是和当前session同一水平的吗（保持一致）？还是只与sever端有关系？
可以在.bash_profile 文件中添加：EXPORT NLS_LANG=AMERICAN_AMERICA.ZHS16GBK 是对instance级别客户端字符集的更改吗？
乱码的真正原因：
NLS( National Language Support)国家语言支持。NLS是数据库的一个非常强大的特性，它控制着数据的许多方面：比如数据如何存储，一般来说它控制着以下两个方面：
1、文本数据持久存储在磁盘上时如何编码
2、透明的将数据从一个字符集转换到另外一个字符集。
假设你在数据库中用WE8ISO8859P1 字符集存储8 位的数据，但是你的某些客户使用的是一种7位字符集，如US7ASCII字符集转换过程通常会修改数据，而你往往会把一个较大的字符集（在此例中就是8位字符集）映射到一个较小的字符集（此例中的7位字符集）。这是一种有损转换（lossy conversion），字符就会被修改，这只是因为：较小的字符集不可能表示较大字符集中的每一个字符。但是这种转换必须发生。这也是乱码产生的原因。如果数据库以一种单字节字符集存储数据，但是客户（如一个Java应用，因为Java语言使用Unicode）希望数据采用多字节表示，就必须执行转换，只有这样客户应用才能使用这些数据。（http://www.cnblogs.com/kerrycode/p/3749085.html）
参考文献：
http://blog.itpub.net/29519108/viewspace-1298298/（大部分是英文文献）
http://www.cnblogs.com/kerrycode/p/3749085.html（基础概念描述）
http://www.cnblogs.com/zhwl/p/3745257.html（oracle数据库文字存储解决方案，很详细的中文文献）
http://blog.csdn.net/jovitang/article/details/5174062（一位技术达人的总结）
| 
转播
