Unicode (统一码)顾名思义是一个将世界上各种文字统一在一起的东东。由美国各大电脑厂商组成的Unicode策进会来推动。目的,推广一个世界通用的编码体制,惊世界上所有常用的文字都涵盖进去,从而减少个电脑商开发国外市场遇到的问题。
为了将成千上万的文字统统收集到一个共同的编码机制下,在兼顾经济的原则下,不管是东方还是西方文字,每个字在Unicode中一律以两个Bytes来表示,这样至少有2的16次方65536种不同的组合,足以应付目前绝大多数场合的需要。
基本上,计算机只是处理数字。它们指定一个数字,来储存字母或其他字符。在创造Unicode之前,有数百种指定这些数字的编码系统。没有一个编码可以包含足够的字符:例如,单单欧州共同体就需要好几种不同的编码来包括所有的语言。即使是单一种语言,例如英语,也没有哪一个编码可以适用于所有的字母,标点符号,和常用的技术符号。
这些编码系统也会互相冲突。也就是说,两种编码可能使用相同的数字代表两个不同的字符,或使用不同的数字代表相同的字符。任何一台特定的计算机(特别是服务器)都需要支持许多不同的编码,但是,不论什么时候数据通过不同的编码或平台之间,那些数据总会有损坏的危险。
Unicode给每个字符提供了一个唯一的数字,不论是什么平台,不论是什么程序,不论什么语言。Unicode标准已经被这些工业界的领导们所采用,例如:Apple, HP, IBM, JustSystem, Microsoft, Oracle, SAP, Sun, Sybase, Unisys和其它许多公司。最新的标准都需要Unicode,例如XML, Java, ECMAScript (JavaScript), LDAP, CORBA 3.0, WML等等,并且,Unicode是实现ISO/IEC 10646的正规方式。许多操作系统,所有最新的浏览器和许多其他产品都支持它。Unicode标准的出现和支持它工具的存在,是近来全球软件技术最重要的发展趋势。
将Unicode与客户服务器或多层应用程序和网站结合,比使用传统字符集节省费用。Unicode使单一软件产品或单一网站能够贯穿多个平台,语言和国家,而不需要重建。它可将数据传输到许多不同的系统,而无损坏。
在与Unicode相关的各技术文件中,经常会看到ISO 10646和UCS这两个名词。
ISO是位于瑞士的国际标准局的缩写。
UCS为ISO颁布的第10646号标准 Universal Character Set,就是世界通用字符集。
UCS通用字符集采用4个Bytes来编码,将世界上所有的官用和商用编码大小通吃,一网打尽。Unicode自1991年便和ISO的UCS小组密切配合,让Unicode和ISO 10646保持一致。因此Unicode 自2.0版开始,便和 ISO 10646-1使用相同的编码。
康熙字典中的汉字有4万7千,如果再加上里面没有的简体字,和不同写法的日文字,那么 Unicode6万多的分配空间,光用来分配汉字就显得捉禁见昼,更别说什么泰文,阿拉伯等其他文字了。针对这个问题Unicode和UCS采用了[中日韩文整合](CJK Unification)的解决方案,把中日韩笔画详尽的汉字用同一个单码表示。
经过[中日韩文整合]的Unicode称为统汉字Unihan。
完整的Unicode4.0版可由 http://www.unicode.org/Public/UNIDATA/Unihan.txt 下载。
UTF (Unicode/UCS Transformation Format),Unicode推荐使用UTF-8和UTF-16两种格式其中8和16指的是Bits数而不是Bytes数。
UTF-16基本就是Unicode双字节的实现,加上一个应付未来需要的扩充编码机制(很少用)
UTF-8 是一种不等幅的编码方式,英数字(Ascii字码)保持原状,完全不受影响(因此不需要做转换),而其他汉字资料须透过程序来转换,会[变胖],因为每个字需要额外一个或两个Bytes来编码。
UCS字符集中,有UCS-2和UCS-4等编码方式其中的2和4指的是bytes数,对应UTF-8和UTF-16.
UCS-2基本和Unicode双byte 编码差不多
UCS-4四 byte编码表示一个字,在每个 UCS-2前面加上两个空白的Byte,便可得到对应的 UCS-4。
Unicode的空间分配:
以下Unicode区位码均以16进制表示
Unicode的前256个字符和ISO-8859-1(西欧字母)完全相同,其中前半段就是Ascii(u+0000到u+00FF)。每个ISO-8859-1码前面补上一个空byte(0x00)后才是相应的Unicode码。
和我们切身相关的Unihan主要分布在u+3400到u+F9FFF之间,GB2312和BIG5主要分布在u+4E00到U+9FFF之间。
UTF-8的编码原理和特性:
知道了西欧字符和汉字在Unicode中的位置后,来看看UTF-8
U+0000~U+007E 1 _ _ _ _ _ _ _ (7bits)
U+0080~U+07FF 1 1 0_ _ _ _ _ 1 0_ _ _ _ _ _ (11bits)
U+0800~U+FFFF 1 1 1 0 _ _ _ _ 1 0 _ _ _ _ _ _ 1 0 _ _ _ _ _ _ (16bits)
看一看Unicode三种格式提出自由的bits(下划线空位)是否足以用来代表区位中各Unicode码,刚好够用。
那么当程序处理UTF-8编码文件时,如何得知一个字符的疆界落在哪里?还有到底他是以三种形式那一中出现呢?
每个以UTF-8编码的字符,不管是以一、二、三个bytes出现,第一个byte前端都清楚地标示了该字符的byte总数。如110种有两个1,代表这种字符是以第二种方式出现,由两个bytes组成。而1110有三个1,表示这种字符一点种方式出现,由三个字节组成。
每个多重byte的UTF-8编码有一个共同的通性,即其中的第二个第三个byte, 一律以10两个bits开头。由于其中的最高位总设成1,可以很容易和那些在UTF-8中只用一个Byte的ASCII字元区分开来,方便侦错。
因为上述设计特点,UTF-8和Unicode之间,可以很容易做双向自由转换,而不会丢失任何资料。
解决办法:乱码问题在 NT操作系统我没怎么碰到过,但是在UNIX 或LINUX系统上出现的比较多
由于操作系统和使用环境不一样,产生乱码的方式也不一样,但是如果掌握了上面的Unicode 编码原理,自己仔细分析一下,很多问题便可迎刃而解。
下面看看几个常见的例子。
1. 如果一些网站服务器例如Tomcat 如果遇到中文乱码问题,可以修改conf目录下的server.xml
<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100" debug="0"connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="GBK"/>
URIENcoding 设成GBK或GB2312
2. 表单中或传递字符串:本来输入的汉字是正常的,但是提交后再显示出来是乱码,因为提交的一般是 ISO8859编码,所以显示的时候要转成GB2312编码:
String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
//rs为待转换的字符串
然后使用S字符串的值就可以了
3. 有的服务器端的语言环境如果设成简体中文的也可以解决此类问题
4. 插入数据库中的字符是乱码
看看数据库中支持的是何种编码方式,用类似2中的方式作一下转换即可。
5. 总之,用jsp开发,碰到乱码,你得分析是读的时候发生乱码,还是写的时候发生乱码,用2中的转换,基本就能解决问题,有些时候写的时候做一次转换,例如:
String S=new String(rs.getString("news").getBytes("gb2312"),"ISO8859_1");
//读的时候在转换回来
String S=new String(rs.getString("news").getBytes("ISO8859_1"),"GB2312");
或者把ISO8859-1和GB2312 的位置换一下,自己多试试,就能找到解决问题的办法。
来自:http://blog.csdn.net/softj/archive/2006/03/15/625193.aspx