字体编码学习-Java 编程技术中汉字问题的分析及解决
---JAVA汉字显示问题的解决方案
分类：java相关2007-06-07 02:31 1593人阅读评论(0) 收藏举报
字体编码学习-
关键字：USC,Unicode,utf-8,gb2312,字库
什么是编码
为了交流信息，所以对字符进行了统一的编码。
UCS和ISO10646
ISO10646定义了通用字符集(Universal Character Set,UCS).UCS是国际标准编码，包含了全球
所有字符。UCS使用31bit进行编码。现在只分配了前65534个码位，这个16位的子集称为基本多语言面
(BMP)。
什么Unicode
Unicode编码是UCS级别３的实现。Unicode编码全码为4个字节，所有字符都使用等的编码方式，现
在只使用两个字节编码。兼容UCS定义的BMP
GB2313与Unicode
GB2312是中国定制的国际准标编码，由两个字节组成，最高位为1表示汉字，最高为0表示是英
文。
GB2312与区位码存在数值关系,区位码+20H＝GB2312
GB2312与Unicode的转换不成数学关系，只能通过映射表来实现。
GB2312为８０年定义的基本编码扩展编码有
GBK
GB18030
GB13000与GBK不兼容，只是使用了相同的词汇.
最新为GB16500-95与unicode3.0兼容
Unicode与UTF-8
Utf-8是为了兼容软件处理的编码，是unicode的另一种表示方式。使用变化的方式编码，第一
字节表示字符的长度，后面的字符以10开头表示编码。0开头表示ascii编码。
例如：
Unicode 字符U+00A9 = 1010 1001 (版权符号) 在UTF-8 里的编码为
11000010 10101001 = 0xC2 0xA9
字库与编码关系
字库是编码表字符显示的描述文件。字符编码是在字库中查询需要显示的字符的索引值。
不同的编码就应该有不同的字库，比如unicode编码就有unicode的字库。Gb2312编码就有
gb2312的字库。
字库格式
字库的格式主要有TrueType(ttf),PostScript(rip),OpenType等
TrueType是微软定义的字库格式，主要用于软件显示这种要求精度不高的环境，
PostScript是Adobe定义的字库格式，主要用于排版印刷等大字打印精度要求很高的环境。
OpenType是TrueType与PostScript的综合格式，并且是使用了unicode的编码。
字体引擎
字体引擎用于读取字库，显示文字，文字转换等操作。现在免费的字体引擎有FreeType.
参考文献
UTF-8 and Unicode FAQ by Markus Kuhn
https://www.doczj.com/doc/fd5055769.html,/linux/TrueType-HOWTO.html
https://www.doczj.com/doc/fd5055769.html,/Info/55/Info16006/
https://www.doczj.com/doc/fd5055769.html,/fonts/TTRefMan/index.html
////////////////////////////////////////////////////////////////////////////////////
以前一直对utf、unicode、ascII还有GBK编码方式不太了解，只知道如果有中文的话一般用utf-8或GBK
存储，今天正好又接触到了这个问题就google了下。ASCII是用来表示英文的一种编码规范，表示的最
大字符数为256个，每个字符占1个字节。如果只用来表示英文应该是绰绰有余了，可是还要表示中文、
阿拉伯文所以就有很大的不足了，于是就产生了GB2312。很多人应该对这个比较了解，很多国内网页指
定的编码都是GB2312的，它其实是对ASCII的一种扩展，是每个国家自己制定的编码规范，比如一个中
文字符是由两个扩展ASCII字符表示。但因为GB2312是国家标准所以会有一些问题，记得我们小时候玩
一些繁体游戏时需要借助一些南极星之类的软件转换编码吗？因为台湾很多用的都是big5编码，他和
GB2312的编码格式还是类似的，会显示出一些奇怪的文字或是偶尔也会有个别汉字。后来因为GB2312所
包含的汉字太少了，所以又扩展出来GBK编码。GBK包括了大部分的汉字，并且还加入了big5中几乎所有
的繁体字体（但big5和GBK中的繁体字体并不兼容）。之后还有GB18030编码，其实主要还是字符集的变
化。ASCII—GB2312—GBK—GB18030他们都是向下兼容的，区分英文编码和中文编码的方法是高字节的
最高位不为0，其实GB中文编码都是双字节字符集。
因为GB编码都是国家标准，所以如果要解决中文问题不能从扩展ASCII角度入手了，于是出现了unicode
和utf。unicode分为UCS-2、UCS-4，目前常用的是UCS-2是用2个字节为字符编码，可以表示的数为
2^16=65535，基本可以表示欧美和大部分亚洲汉字，并且因为UCS-2是双字节的所以每个汉字或英文都
是由1个unicode构成，那拆字和统计字数比ASCII方便了很多。似乎unicode是比较完美了，可是它却有
一个很致命的缺点，就是并不能和ASCII兼容。ASCII字符是单个字节的，比如"A"的ASCII 是65。而
Unicode是双字节的，比如"A"的Unicode是0065，这就造成了一个非常大的问题：以前处理ASCII的那套
机制不能被用来处理Unicode了。另一个更加严重的问题是，C语言使用'/0'作为字符串结尾，而
Unicode里恰恰有很多字符都有一个字节为0，这样一来，C语言的字符串函数将无法正常处理Unicode，
除非把世界上所有用C写的程序以及他们所用的函数库全部换掉。
于是出现了utf，它是将Unicode编码规则和计算机的实际编码对应起来的一个规则。现在流行的UTF有2
种：UTF-8和UTF-16。UTF-8是以8位为单元对UCS进行编码，它定义了一种"区间规则"，这种规则可以和
ASCII编码保持最大程度的兼容。具体的编码方式大家可以搜索一下，俺也只是一些浅显的了解，如果
有不对的地方请大家指出来~~~~
/////////////////////////////////////////////////////////////////////////////////////////
Unicode:
https://www.doczj.com/doc/fd5055769.html,制定的编码机制, 要将全世界常用文字都函括进去.
在1.0中是16位编码, 由U+0000到U+FFFF. 每个2byte码对应一个字符; 在2.0开始抛弃了16位限制, 原
来的16位作为基本位平面, 另外增加了16个位平面, 相当于20位编码, 编码范围0到
0x10FFFF.
UCS:
ISO制定的ISO10646标准所定义的Universal Character Set, 采用4byte编码.
Unicode与UCS的关系:
ISO与https://www.doczj.com/doc/fd5055769.html,是两个不同的组织, 因此最初制定了不同的标准; 但自从unicode2.0开始, unicode
采用了与ISO 10646-1相同的字库和字码, ISO也承诺ISO10646将不会给超出0x10FFFF 的UCS-4编码赋值,
使得两者保持一致.
UCS的编码方式:
UCS-2, 与unicode的2byte编码基本一样.
UCS-4, 4byte编码, 目前是在UCS-2前加上2个全零的byte.
UTF: Unicode/UCS Transformation Format
UTF-8, 8bit编码, ASCII不作变换, 其他字符做变长编码, 每个字符1-3 byte. 通常作为外码. 有以下
优点:
* 与CPU字节顺序无关, 可以在不同平台之间交流
* 容错能力高, 任何一个字节损坏后, 最多只会导致一个编码码位损失, 不会链锁错误(如GB码错一个
字节就会整行乱码)
UTF-16, 16bit编码, 是变长码, 大致相当于20位编码, 值在0到0x10FFFF之间, 基本上就是unicode编
码的实现. 它是变长码, 与CPU字序有关, 但因为最省空间, 常作为网络传输的外码.
UTF-16是unicode的preferred encoding.
UTF-32, 仅使用了unicode范围(0到0x10FFFF)的32位编码, 相当于UCS-4的子集.
UTF与unicode的关系:
Unicode是一个字符集, 可以看作为内码.
而UTF是一种编码方式, 它的出现是因为unicode不适宜在某些场合直接传输和处理. UTF-16直接就是
unicode编码, 没有变换, 但它包含了0x00在编码内, 头256字节码的第一个byte都是
0x00, 在操作系统
(C语言)中有特殊意义, 会引起问题. 采用UTF-8编码对unicode的直接编码作些变换可以避免这问题,
并带来一些优点.
中国国标编码:
GB 13000: 完全等同于ISO 10646-1/Unicode 2.1, 今后也将随ISO 10646/Unicode的标准更改而同步更
改.
GBK: 对GB2312的扩充, 以容纳GB2312字符集范围以外的Unicode 2.1的统一汉字部分, 并且增加了部分
unicode中没有的字符.
GB 18030-2000: 基于GB 13000, 作为Unicode 3.0的GBK扩展版本, 覆盖了所有unicode 编码, 地位等同
于UTF-8, UTF-16, 是一种unicode编码形式. 变长编码, 用单字节/双字节/4字节对字符编码. GB18030
向下兼容GB2312/GBK.
GB 18030是中国所有非手持/嵌入式计算机系统的强制实施标准.
////////////////////////////////////////////////////////////////////////////////////////
彻底解决程序乱码问题
由于程序编程过程中存在众多的编码集，而这些编码集又各自有自己的方法来表示一个中文字
符。由此，造成我们的程序显示中文的时候乱码。最多的是本来是中文，但结果显示为问号？
这篇文章从我碰到过的问题来从根本上解决乱码的问题，反正我用这个方法是百战百胜^_^嘎嘎
我们知道，在我们的中文系统中使用的是―GBK‖编码集。
也就是说，比如我们从本地系统中读入一个包含中文内容的.txt文件，那么我们从这个磁盘空
间所获得是流文件是个经过―GBK‖的。
但是，假如我们的JVM默认的编码集是―ISO-8859-1‖，那么这个流文件经过我们的JVM 编码就变
成一个Unicode的字符或者字符串。
是不是说的很抽象。
下面我具体解释一下。
什么是编码？编码说白了就是从字节到字符(Unicode）的过程，因为我们的字符或字符串在JVM
中是用Unicode表示的，也就是说编码实质上是获取一个Unicode码的过程。
我再来解释一下解码？解码就是把JVM里的Unicode码转换成我们本地字符集所表示的字节流。
如果在编程过程中，JVM默认的字符集和我们的中文系统，或者数据库文件等采用的字符集不一样
。
这样的情况下，如果我们仅仅是编码，而不去解码。也就说把本来用―GBK‖的字节流采用―ISO-
8859-1‖转换成字符或字符串，这个时候就产生了乱码。
当然，现在JVM和中文系统默认的编码集已经一样了，所以产生这种情况的很少。但是在读取数据
库文件的时候依然会经常碰到这种情况。所以，我一贯主张从本质上来了解一个知识，然后才能融会贯
通，应用自如，这是高手的境界，当然，我不能算高手^_^哈哈
好了，如果你现在还不明白编码解码怎么回事？以及乱码产生的原因。我想你可以去撞墙了。
那么，编码的时候两个系统的字符集不一致，该怎么办呢？怎么样把他们变成一致？
如果有可以直接改变系统字符集的方法，那当然是最好的了。比如在JVM里
Properties pps = System.getProperties();
pps.put("file.encoding","GBK");
这样，就把JVM的默认字符集改变成―GBK‖了。
那么，如果没有改怎么办？
什么？没办法？那是不可能滴，没有程序解决不了的问题，这也是偶滴名言，嘎嘎！
当然要再次编码了，或者说重新编码！
还记得不？刚才我们解码的时候得到一个利用JVM解码的字符或字符串（也可以说Unicode）
好，如果不记得，麻烦你再看看上面写的，记性太差了！
我们利用这个字符或字符串再重新编码。
我们把这个字符或字符串再次现出原形，也就是字节数组。
byte[] data = str.getBytes("ISO-8859-1");
好，现在又获得了―ISO-8859-1‖字符集下的字节数组。
这个里面就完整的存放着我们想要的汉字，哈哈。
得到了字节数组，不就好办了吗？
还不会？没关系，我教你！
String newstr = new String(data,―GBK‖);
好了，得到了我们完整的字符串了！编码变成！
这个字符串就是我们要的中文系统下的字符串，它又经过我们―GBK‖编码过了！
可以放心的输出到中文系统下了。
其实说白了，编码解码就是把我们从系统得到的字符转换成字节数组，然后对它用系统字符集加工，加
工完后再重新包装，再把它输出。
//////////////////////////////////////////////////////////////////////////////////////////
Java 编程技术中汉字问题的分析及解决
在基于Java 语言的编程中，我们经常碰到汉字的处理及显示的问题。一大堆看不懂的
乱码肯定不是我们愿意看到的显示效果，怎样才能够让那些汉字正确显示呢？Java 语言
默认的编码方式是UNICODE ，而我们中国人通常使用的文件和数据库都是基于GB2312 或者BIG5 等方式编码的，怎样才能够恰当地选择汉字编码方式并正确地处理汉字的编
码呢？本文将从汉字编码的常识入手，结合Java 编程实例，分析以上两个问题并提出
解决它们的方案。
----------------------------------------------------------------------------
----
现在Java 编程语言已经广泛应用于互联网世界，早在Sun 公司开发Java 语言的时候，就已经考虑到对非英文字符的支持了。Sun 公司公布的Java 运行环境（JRE）本身就分英文版和国际版，但只有国际版才支持非英文字符。不过在Java 编程语言的应用中
，对中文字符的支持并非如同Java Soft 的标准规范中所宣称的那样完美，因为中文字
符集不只一个，而且不同的操作系统对中文字符的支持也不尽相同，所以会有许多和汉
字编码处理有关的问题在我们进行应用开发中困扰着我们。有很多关于这些问题的解答
，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于Java 中文问题的系统
研究并不多，本文从汉字编码常识出发，分析Java 中文问题，希望对大家解决这个问
题有所帮助。
汉字编码的常识
我们知道，英文字符一般是以一个字节来表示的，最常用的编码方法是ASCII 。但一个
字节最多只能区分256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。我们经常碰到的编码方式有GB2312、BIG5、UNICODE 等。关于具体编码方式的详细资
料，有兴趣的读者可以查阅相关资料。我肤浅谈一下和我们关系密切的GB2312 和UNI CODE。GB2312 码，中华人民共和国国家标准汉字信息交换用编码，是一个由中华人民共
和国国家标准总局发布的关于简化汉字的编码，通行于中国大陆地区及新加坡，简称国
标码。两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）的值为位号值加32（20H），用这两个值来表示一个汉字的编码。UNICODE 码是微
软提出的解决多国字符问题的多字节等长编码，它对英文字符采取前面加―0‖字节的策
略实现等长兼容。如―A‖ 的ASCII 码为0x41，UNICODE 就为0x00，0x41。利用特殊的工具各种编码之间可以互相转换。
Java 中文问题的初步认识
我们基于Java 编程语言进行应用开发时，不可避免地要处理中文。Java 编程语言默认
的编码方式是UNICODE，而我们通常使用的数据库及文件都是基于GB2312 编码的，我们经常碰到这样的情况：浏览基于JSP 技术的网站看到的是乱码，文件打开后看到的也是乱码，被Java 修改过的数据库的内容在别的场合应用时无法继续正确地提供信息。
String sEnglish = ―apple‖;
String sChinese = ―苹果‖;
String s = ―苹果apple ‖;
sEnglish 的长度是5，sChinese的长度是4，而s 默认的长度是14。对于sEnglish来说，Java 中的各个类都支持得非常好，肯定能够正确显示。但对于sChinese 和s 来说，虽然Java Soft 声明Java 的基本类已经考虑到对多国字符的支持（默认UNICODE 编码），但是如果操作系统的默认编码不是UNICODE ，而是国标码等。从Java 源代码到得到正确的结果，要经过―Java 源代码-> Java 字节码-> ;虚拟机->操作系统->显
示设备‖的过程。在上述过程中的每一步骤，我们都必须正确地处理汉字的编码，才能
够使最终的显示结果正确。
― Java 源代码-> Java 字节码‖，标准的Java 编译器javac 使用的字符集是系统默
认的字符集，比如在中文Windows 操作系统上就是GBK ,而在Linux 操作系统上就是ISO-8859-1，所以大家会发现在Linux 操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在编译的时候添加encoding 参数，这样才能够与平台无关。
用法是
javac –encoding GBK。
― Java 字节码->虚拟机->操作系统‖，Java 运行环境（JRE）分英文版和国际版，
但只有国际版才支持非英文字符。Java 开发工具包（JDK）肯定支持多国字符，但并非所有的计算机用户都安装了JDK 。很多操作系统及应用软件为了能够更好的支持Ja va ，都内嵌了JRE 的国际版本，为自己支持多国字符提供了方便。
―操作系统->显示设备‖，对于汉字来说，操作系统必须支持并能够显示它。英文操作
系统如果不搭配特殊的应用软件的话，是肯定不能够显示中文的。
还有一个问题，就是在Java 编程过程中，对中文字符进行正确的编码转换。例如，向
网页输出中文字符串的时候，不论你是用
out.println(string); // string 是含中文的字符串
还是用
<%=string%>，都必须作UNICODE 到GBK 的转换，或者手动，或者自动。在JSP 1.0中
，可以定义输出字符集，从而实现内码的自动转换。用法是
<%@page ContentType=‖text/html;charset=gb2312‖ %>
但是在一些JSP 版本中并没有提供对输出字符集的支持，（例如JSP 0.92），这就需
要手动编码输出了，方法非常多。最常用的方法是
String s1 = request.getParameter(―keyword‖);
String s2 = new String(s1.getBytes(―ISO-8859-1‖),‖GBK‖);
getBytes 方法用于将中文字符以―ISO-8859-1‖编码方式转化成字节数组，而―GBK‖
是目标编码方式。我们从以ISO-8859-1方式编码的数据库中读出中文字符串s1 ，经过上述转换过程，在支持GBK 字符集的操作系统和应用软件中就能够正确显示中文字符串 s2 。
Java 中文问题的表层分析及处理
背景
开发环境
JDK1.15
Vcafe2.0
JPadPro
服务器端
NT IIS
Sybase System
Jconnect（JDBC）
客户端
IE5.0
Pwin98
.CLASS 文件存放在服务器端，由客户端的浏览器运行APPLET ，APPLET 只起调入FR
AME 类等主程序的作用。界面包括Textfield ，TextArea，List，Choice 等。
I. 取中文
用JDBC 执行SELECT 语句从服务器端读取数据（中文）后，将数据用APPEND 方法加
到TextArea（TA），不能正确显示。但加到List 中时，大部分汉字却可正确显示。
将数据按―ISO-8859-1‖ 编码方式转化为字节数组，再按系统缺省编码方式（Defaul
t Character Encoding）转化为STRING ，即可在TA 和List 中正确显示。
程序段如下：
dbstr2 = results.getString(1);
//After reading the result from DB server，converting it to string.
dbbyte1 = dbstr2.getBy tes(―iso-8859-1‖);
dbstr1 = new String(dbbyte1);
在转换字符串时不采用系统默认编码方式，而直接采用― GBK‖ 或者―GB2312‖ ,在
A 和
B 两种情况下，从数据库取数据都没有问题。
II. 写中文到数据库
处理方式与―取中文‖相逆，先将SQL 语句按系统缺省编码方式转化为字节数组，再按
―ISO-8859-1‖编码方式转化为STRING ，最后送去执行，则中文信息可正确写入数据库。
程序段如下：
sqlstmt = tf_input.getText();
//Before sending statement to DB server，converting it to sql statement.
dbbyte1 = sqlstmt.getBytes();
sqlstmt = newString(dbbyte1,‖iso-8859-1‖);
_stmt = _con.createStatement();
_stmt.executeUpdate(sqlstmt);
……
问题：如果客户机上存在CLASSPATH 指向JDK 的CLASSES.ZIP 时（称为A 情况），上述程序代码可正确执行。但是如果客户机只有浏览器，而没有JDK 和CLASSPATH 时（称为B 情况），则汉字无法正确转换。
我们的分析：
1.经过测试，在A 情况下，程序运行时系统的缺省编码方式为GBK 或者GB2312 。在
B 情况下，程序启动时浏览器的JAVA 控制台中出现如下错误信息：
Can't find resource for sun.awt.windows.awtLocalization_zh_CN
然后系统的缺省编码方式为―8859-1‖。
2.如果在转换字符串时不采用系统缺省编码方式，而是直接采用―GBK‖ 或―GB2312‖
，则在A 情况下程序仍然可正常运行，在B 情况下，系统出现错误：UnsupportedEncodingException。
3.在客户机上，把JDK 的CLASSES.ZIP 解压后，放在另一个目录中，CLASSPATH 只包
含该目录。然后一边逐步删除该目录中的 .CLASS 文件，另一边运行测试程序，最后发
现在一千多个CLASS 文件中，只有一个是必不可少的，该文件是：
sun.io.CharToByteDoubleByte.class。
将该文件拷到服务器端和其它的类放在一起，并在程序的开头IMPORT 它，在B 情况下程序仍然无法正常运行。
4.在A 情况下，如果在CLASSPTH 中去掉sun.io.CharToByteDoubleByte.class ，则程序运行时测得默认编码方式为―8859-1‖，否则为―GBK‖ 或―GB2312‖ 。
如果JDK 的版本为1.2以上的话，在B 情况下遇到的问题得到了很好的解决，测试的步骤同上，有兴趣的读者可以尝试一下。
[/b]Java 中文问题的根源分析及解决[/b]
在简体中文MS Windows 98 + JDK 1.3 下，可以用System.getProperties() 得到Ja va 运行环境的一些基本属性，类PoorChinese 可以帮助我们得到这些属性。
类PoorChinese 的源代码：
public class PoorChinese {
public static void main(String[] args) {
System.getProperties().list(System.out);
}
}
执行java PoorChinese 后，我们会得到:
系统变量file.encoding 的值为GBK ，https://www.doczj.com/doc/fd5055769.html,nguage 的值为zh ，user.region 的值为CN ，这些系统变量的值决定了系统默认的编码方式是GBK 。
在上述系统中，下面的代码将GB2312 文件转换成Big5 文件，它们能够帮助我们理解 Java 中汉字编码的转化:
import java.io.*;
import java.util.*;
public class gb2big5 {
static int iCharNum=0;
public static void main(String[] args) {
System.out.println("Input GB2312 file, output Big5 file.");
if (args.length!=2) {
System.err.println("Usage: jview gb2big5 gbfile big5file");
System.exit(1);
}
String inputString = readInput(args[0]);
writeOutput(inputString,args[1]);
System.out.println("Number of Characters in file: "+iCharNum+".");
}
static void writeOutput(String str, String strOutFile) {
try {
FileOutputStream fos = new FileOutputStream(strOutFile);
Writer out = new OutputStreamWriter(fos, "Big5");
out.write(str);
out.close();
}
catch (IOException e) {
e.printStackTrace();
e.printStackTrace();
}
}
static String readInput(String strInFile) {
StringBuffer buffer = new StringBuffer();
try {
FileInputStream fis = new FileInputStream(strInFile);
InputStreamReader isr = new InputStreamReader(fis, "GB2312");
Reader in = new BufferedReader(isr);
int ch;
while ((ch = in.read()) > -1) {
iCharNum += 1;
buffer.append((char)ch);
}
in.close();
return buffer.toString();
}
catch (IOException e) {
e.printStackTrace();
return null;
}
}
}
编码转化的过程如下：
ByteToCharGB2312 CharToByteBig5
GB2312------------------>Unicode------------->Big5
执行java gb2big5 gb.txt big5.txt ，如果gb.txt 的内容是―今天星期三‖，则得
到的文件big5.txt 中的字符能够正确显示；而如果gb.txt 的内容是―情人节快乐‖
，则得到的文件big5.txt 中对应于―节‖和―乐‖的字符都是符号―？‖（0x3F），
可见sun.io.ByteToCharGB2312 和sun.io.CharToByteBig5 这两个基本类并没有编好。
正如上例一样，Java 的基本类也可能存在问题。由于国际化的工作并不是在国内完成的，所以在这些基本类发布之前，没有经过严格的测试，所以对中文字符的支持并不像 Java Soft 所声称的那样完美。前不久，我的一位技术上的朋友发信给我说，他终于找
到了Java Servlet 中文问题的根源。两周以来，他一直为Java Servlet 的中文问题
所困扰，因为每面对一个含有中文字符的字符串都必须进行强制转换才能够得到正确的结果（这好象是大家公认的唯一的解决办法）。后来，他确实不想如此继续安分下去了，因为这样的事情确实不应该是高级程序员所要做的工作，他就找出Servlet 解码的源代码进行分析，因为他怀疑问题就出在解码这部分。经过四个小时的奋斗，他终于找到了问题的根源所在。原来他的怀疑是正确的，Servlet 的解码部分完全没有考虑双字节，直接把%XX 当作一个字符。（原来Java Soft 也会犯这幺低级的错误！）
如果你对这个问题有兴趣或者遇到了同样的烦恼的话，你可以按照他的步骤对Servlet .jar 进行修改：
找到源代码HttpUtils 中的static private String parseName ，在返回前将sb（S tringBuffer）复制成byte bs[] ，然后return new String(bs,‖GB2312‖)。作上
述修改后就需要自己解码了：
HashTable form=HttpUtils .parseQueryString(request.getQueryString())或者
form=HttpUtils.parsePostData(……)
千万别忘了编译后放到Servlet.jar 里面。
五、关于Java 中文问题的总结
Java 编程语言成长于网络世界，这就要求Java 对多国字符有很好的支持。Java 编程语言适应了计算的网络化的需求，为它能够在网络世界迅速成长奠定了坚实的基础。J ava 的缔造者（Java Soft）已经考虑到Java 编程语言对多国字符的支持，只是现在的解决方案有很多缺陷在里面，需要我们付诸一些补偿性的措施。而世界标准化组织也在努力把人类所有的文字统一在一种编码之中，其中一种方案是ISO10646 ，它用四个字节来表示一个字符。当然，在这种方案未被采用之前，还是希望Java Soft 能够严格地测试它的产品，为用户带来更多的方便。
附一个用于从数据库和网络中取出中文乱码的处理函数，入参是有问题的字符串，出参是问题已经解决了的字符串。
String parseChinese(String in)
{
String s = null;
byte temp [];
if (in == null)
{
System.out.println("Warn:Chinese null founded!");
return new String("");
}
try
{
temp=in.getBytes("iso-8859-1");
temp=in.getBytes("iso-8859-1");
s = new String(temp);
}
{
System.out.println("Warn:Chinese null founded!");
return new String("");
}
try
{
temp=in.getBytes("iso-8859-1");
s = new String(temp);
}
catch(UnsupportedEncodingException e)
{
System.out.println (e.toString());
}
return s;
}
作者简介
段明辉，清华大学电子工程系学生
现在正在清华大学微电子学研究所从事Java 智能卡微处理器的研究和开发yaya_316 www68207295领导
BBS 水木清华站的Java 讨论组，为众多Java 技术应用者提供解决方案
//////////////////////////////////////////////////////////////////////////////////////////
/
JAVA汉字显示问题的解决方案
在基于Java 语言的编程中，我们经常碰到汉字的处理及显示的问题。一大堆看不懂的乱码肯定
不是我们愿意看到的显示效果，怎样才能够让那些汉字正确显示呢？Java 语言默认的编码方式是
UNICODE ，而我们中国人通常使用的文件和数据库都是基于GB2312 或者BIG5 等方式编码的，怎样才
能够恰当地选择汉字编码方式并正确地处理汉字的编码呢？本文将从汉字编码的常识入手，结合Java
编程实例，分析以上两个问题并提出解决它们的方案。
现在Java 编程语言已经广泛应用于互联网世界，早在Sun 公司开发Java 语言的时候，就已经
考虑到对非英文字符的支持了。Sun 公司公布的Java 运行环境（JRE）本身就分英文版和国际版，但
只有国际版才支持非英文字符。不过在Java 编程语言的应用中，对中文字符的支持并非如同Java
Soft 的标准规范中所宣称的那样完美，因为中文字符集不只一个，而且不同的操作系统对中文字符的
支持也不尽相同，所以会有许多和汉字编码处理有关的问题在我们进行应用开发中困扰着我们。有很多
关于这些问题的解答，但都比较琐碎，并不能够满足大家迫切解决问题的愿望，关于Java 中文问题的
系统研究并不多，本文从汉字编码常识出发，分析Java 中文问题，希望对大家解决这个问题有所帮助
。
一、汉字编码的常识
我们知道，英文字符一般是以一个字节来表示的，最常用的编码方法是ASCII 。但一个字节最多
只能区分256个字符，而汉字成千上万，所以现在都以双字节来表示汉字，为了能够与英文字符分开，
每个字节的最高位一定为1，这样双字节最多可以表示64K格字符。我们经常碰到的编码方式有GB2312
、BIG5、UNICODE 等。关于具体编码方式的详细资料，有兴趣的读者可以查阅相关资料。我肤浅谈一下
和我们关系密切的GB2312 和UNICODE。GB2312 码，中华人民共和国国家标准汉字信息交换用编码，
是一个由中华人民共和国国家标准总局发布的关于简化汉字的编码，通行于中国大陆地区及新加坡，简
称国标码。两个字节中，第一个字节（高字节）的值为区号值加32（20H），第二个字节（低字节）的
值为位号值加32（20H），用这两个值来表示一个汉字的编码。UNICODE 码是微软提出的解决多国字符
问题的多字节等长编码，它对英文字符采取前面加―0‖字节的策略实现等长兼容。如―A‖ 的ASCII
码为0x41，UNICODE 就为0x00，0x41。利用特殊的工具各种编码之间可以互相转换。
二、Java 中文问题的初步认识
我们基于Java 编程语言进行应用开发时，不可避免地要处理中文。Java 编程语言默认的编码方
式是UNICODE，而我们通常使用的数据库及文件都是基于GB2312 编码的，我们经常碰到这样的情况：
浏览基于JSP 技术的网站看到的是乱码，文件打开后看到的也是乱码，被Java 修改过的数据库的内
容在别的场合应用时无法继续正确地提供信息。
String sEnglish = ―apple‖;
String sChinese = ―苹果‖;
String s = ―苹果apple ‖;
sEnglish 的长度是5，sChinese的长度是4，而s 默认的长度是14。对于sEnglish 来说，Java
中的各个类都支持得非常好，肯定能够正确显示。但对于sChinese 和s 来说，虽然Java Soft 声明
Java 的基本类已经考虑到对多国字符的支持（默认UNICODE 编码），但是如果操作系
统的默认编码不
是UNICODE ，而是国标码等。从Java 源代码到得到正确的结果，要经过―Java 源代
码-> Java 字
节码-> ;虚拟机->操作系统->显示设备‖的过程。在上述过程中的每一步骤，我们都必须正确地处理汉
字的编码，才能够使最终的显示结果正确。
― Java 源代码-> Java 字节码‖，标准的Java 编译器javac 使用的字符集是系统默认的字符
集，比如在中文Windows 操作系统上就是GBK ,而在Linux 操作系统上就是ISO-8859-1，所以大家会
发现在Linux 操作系统上编译的类中源文件中的中文字符都出了问题，解决的办法就是在
编译的时候
添加encoding 参数，这样才能够与平台无关。用法是
javac –encoding GBK。
― Java 字节码->虚拟机->操作系统‖，Java 运行环境（JRE）分英文版和国际版，
但只有国
概念 先说一说基本的概念，这包括什么是Unicode，什么是UTF-8，什么是UTF-16。 Unicode，UTF-8，UTF-16完整的说明请参考Wiki（Unicode，UTF-8，UTF-16）。用比较简单的话来说就是，Unicode定义了所有可以用来表示字符的数值集合（称之为Code Point）。UTF-8和UTF-16等UTF标准定义了这些数值和字符的映射关系。 UTF-8 优势 UTF-8最大的优势是，没有字节序的概念。所以特别适合用于字符串的网络数据传输，不用考虑大小端问题。 劣势 本地字符串处理过程中，如果使用UTF-8，对于英文字符的处理没有太大的问题。一个char 变量表示一个英文字符。但是对于中文等远东字符集来说，就比较坑爹了。char str[]; str[0]并不能完整表示一个汉字。UTF-8编码格式下，一个汉字需要至少3个char才能表示。这对于通过下标来操作字符串的操作来说是非常痛苦的一件事情。 另外，一个汉字需要至少3个char来表示，也让汉字在网络传输上存在劣势，占用太多流量。 UTF-16 优势 UTF-16 LE是windows上默认的Unicode编码方式，使用wchar_t表示。所有wchar_t *类型的字符串(包括硬编码在.h/.cpp里的字符串字面值)，VC都自动采用UTF-16的编码(字符串字面值，literal string，存在很多坑。特别是char *类型的字面值，最终内存使用何种编码方式完全取决于当前文件的编码方式。也就是说当前文件如果是GBK编码的，那么文件里char * str = "中午"，str指向的内存字符串二进制是使用GBK编码的。如果文件编码是UTF-8，那么内存是使用UTF-8编码。所以为什么一直要强调字符串应该放在资源文件里，而不是硬编码在.h/.cpp文件里！)。 UTF-16另外一个优势就是常用字符都可以使用两个个字节表示，也就是一个wchar_t(这里指Windows平台)。所以，在Windows平台上，特别适合使用wchar_t来作为字符串的存储基类型。一个wchar_t表示一个字符。操作使用非常方便。 劣势 没有统一的表示UTF-16编码的字符类型。C++98/03里对wchar_t的定义是非常宽泛的。这导致在Windows平台上，wchar_t是2字节的；在Unix-like系统上是4字节的。代码移植上，可能会遇到挑战(我没移植过，所以不确定会有什么难度，以及难度有多大)。 即使最新的C++11里已经定义除了char16_t表示UTF-16，MS的VS2013还不支持char16_t。所以目前使用char16_t还不具移植性。 据我了解，UTF-16编码和GBK编码相比，还存在一个排序的劣势。也就是说，如果要按照
Unicode汉字编码表 1 unicode编码表 Unicode目前普遍采用的是UCS-2,它用两个字节来编码一个字符, 比如汉字"经"的编码是0x7ECF,注意字符编码一般用十六进制来表示,为了与十进制区分,十六进制以0x开头,0x7ECF转换成十进制就是32463,UCS-2用两个字节来编码字符,两个字节就是16位二进制, 2的16次方等于65536,所以UCS-2最多能编码65536个字符。 编码从0到127的字符与ASCII编码的字符一样,比如字母"a"的Unicode 编码是0x0061,十进制是97,而"a"的ASCII编码是0x61,十进制也是97, 对于汉字的编码,事实上Unicode 对汉字支持不怎么好,这也是没办法的, 简体和繁体总共有六七万个汉字,而UCS-2最多能表示65536个,才六万多个,所以Unicode只能排除一些几乎不用的汉字,好在常用的简体汉字也不过七千多个,为了能表示所有汉字,Unicode也有UCS-4规范,就是用4个字节来编码字符,不过现在普遍采用的还是UCS-2，只用两个字节来编码,看一下Unicode对汉字的编码: ------------------------------------------------------------------------ 2 汉字编码表 U+ 0 1 2 3 4 5 6 7 8 9 A B C D E F ----------------------------------------------------- 4e00 一丁丂七丄丅丆万丈三上下丌不与丏 4e10 丐丑丒专且丕世丗丘丙业丛东丝丞丟 4e20 丠両丢丣两严並丧丨丩个丫丬中丮丯
ASCII ASCII码是7位编码，编码范围是0x00-0x7F。ASCII字符集包括英文字母、阿拉伯数字和标点符号等字符。其中0x00-0x20和0x7F共33个控制字符。 只支持ASCII码的系统会忽略每个字节的最高位，只认为低7位是有效位。HZ字符编码就是早期为了在只支持7位ASCII系统中传输中文而设计的编码。早期很多邮件系统也只支持ASCII编码，为了传输中文邮件必须使用BASE64或者其他编码方式。 GB2312 GB2312是基于区位码设计的，区位码把编码表分为94个区，每个区对应94个位，每个字符的区号和位号组合起来就是该汉字的区位码。区位码一般用10进制数来表示，如1601就表示16区1位，对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。 区位码中01-09区是符号、数字区，16-87区是汉字区，10-15和88-94是未定义的空白区。它将收录的汉字分成两级：第一级是常用汉字计3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。一级汉字是按照拼音排序的，这个就可以得到某个拼音在一级汉字区位中的范围，很多根据汉字可以得到拼音的程序就是根据这个原理编写的。 GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。可以用繁体汉字测试某些系统是不是只支持GB2312编码。 GB2312的编码范围是0xA1A1-0x7E7E，去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。 EUC-CN可以理解为GB2312的别名，和GB2312完全相同。 区位码更应该认为是字符集的定义，定义了所收录的字符和字符位置，而GB2312及EUC-CN是实际计算机环境中支持这种字符集的编码。HZ和ISO- 2022-CN是对应区位码字符集的另外两种编码，都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像Unicode和UTF-8。 GBK GBK编码是GB2312编码的超集，向下完全兼容GB2312，同时GBK收录了Unicode基本多文种平面中的所有CJK汉字。同GB2312一样，GBK也支持希腊字母、日文假名字母、俄语字母等字符，但不支持韩语中的表音字符（非汉字字符）。GBK还收录了GB2312不包含的汉字部首符号、竖排标点符号等字符。 GBK的整体编码范围是为0x8140-0xFEFE，不包括低字节是0×7F的组合。高字节范围是0×81-0xFE，低字节范围是0x40-7E和0x80-0xFE。
编码表 平面0 (0000–FFFF): 基本多文种平面（Basic Multilingual Plane, BMP）. 平面1 (10000–1FFFF): 多文种补充平面（Supplementary Multilingual Plane, SMP）. 平面2 (20000–2FFFF): 表意文字补充平面（Supplementary Ideographic Plane, SIP）. 平面3 (30000–3FFFF): 表意文字第三平面（Tertiary Ideographic Plane, TIP）. 平面4 to 13 (40000–DFFFF)尚未使用 平面14 (E0000–EFFFF): 特别用途补充平面（Supplementary Special-purpose Plane, SSP） 平面15 (F0000–FFFFF)保留作为私人使用区（Private Use Area, PUA） 平面16 (100000–10FFFF)，保留作为私人使用区（Private Use Area, PUA） 注意1 现在网上大多数用于判断中文字符的是U+4E00..U+9FA5这个范围是只是“中日韩统一表意文字”这个区间，但这不是全部，如果要全部包含，则还要他们的扩展集、部首、象形字、注间字母等等; 2E80－A4CF加上F900-FAFF加上FE30-FE4F。 其中： 2E80－A4CF 包含了中日朝部首补充、康熙部首、表意文字描述符、中日朝符号和标点、日文平假名、日文片假名、注音字母、谚文兼容字母、象形字注释标志、注音字母扩展、中日朝笔画、日文片假名语音扩展、带圈中日朝字母和月份、中日朝兼容、中日朝统一表意文字扩展A、易经六十四卦符号、中日韩统一表意文字、彝文音节、彝文字根 F900-FAFF 中日朝兼容表意文字 FE30-FE4F 中日朝兼容形式 所以，一般用4E00－9FA5已经可以，如果要更广，则用2E80－A4CF || F900-FAFF||FE30-FE4F 注意2 全角ASCII、全角中英文标点、半宽片假名、半宽平假名、半宽韩文字母：FF00-FFEF
包含汉字： 的一是了我不人在他有这个上们来到时大地为子中你说生国年着就那和要她出也得里后自以会家可下而过天去能对小多然于心学么之 都好看起发当没成只如事把还用第样道想作种开美总从无情己面最女但现前些所同日手又行意动方期它头经长儿回位分爱老因很给 名法间斯知世什两次使身者被高已亲其进此话常与活正感见明问力理尔点文几定本公特做外孩相西果走将月十实向声车全信重 三机工物气每并别真打太新比才便夫再书部水像眼等体却加电主界门利海受听表德少克代员许稜先口由死安写性马光白或住难 望教命花结乐色更拉东神记处让母父应直字场平报友关放至张认接告入笑内英军候民岁往何度山觉路带万男边风解叫任金快原 吃妈变通师立象数四失满战远格士音轻目条呢病始达深完今提求清王化空业思切怎非找片罗钱紶吗语元喜曾离飞科言干流欢约 各即指合反题必该论交终林请医晚制球决窢传画保读运及则房早院量苦火布品近坐产答星精视五连司巴奇管类未朋且婚台夜青 北队久乎越观落尽形影红爸百令周吧识步希亚术留市半热送兴造谈容极随演收首根讲整式取照办强石古华諣拿计您装似足双妻 尼转诉米称丽客南领节衣站黑刻统断福城故历惊脸选包紧争另建维绝树系伤示愿持千史谁准联妇纪基买志静阿诗独复痛消社算 义竟确酒需单治卡幸兰念举仅钟怕共毛句息功官待究跟穿室易游程号居考突皮哪费倒价图具刚脑永歌响商礼细专黄块脚味灵改 据般破引食仍存众注笔甚某沉血备习校默务土微娘须试怀料调广蜖苏显赛查密议底列富梦错座参八除跑亮假印设线温虽掉京初 养香停际致阳纸李纳验助激够严证帝饭忘趣支春集丈木研班普导顿睡展跳获艺六波察群皇段急庭创区奥器谢弟店否害草排背止 组州朝封睛板角况曲馆育忙质河续哥呼若推境遇雨标姐充围案伦护冷警贝著雪索剧啊船险烟依斗值帮汉慢佛肯闻唱沙局伯族低 玩资屋击速顾泪洲团圣旁堂兵七露园牛哭旅街劳型烈姑陈莫鱼异抱宝权鲁简态级票怪寻杀律胜份汽右洋范床舞秘午登楼贵吸责 例追较职属渐左录丝牙党继托赶章智冲叶胡吉卖坚喝肉遗救修松临藏担戏善卫药悲敢靠伊村戴词森耳差短祖云规窗散迷油旧适 乡架恩投弹铁博雷府压超负勒杂醒洗采毫嘴毕九冰既状乱景席珍童顶派素脱农疑练野按犯拍征坏骨余承置臓彩灯巨琴免环姆暗 换技翻束增忍餐洛塞缺忆判欧层付阵玛批岛项狗休懂武革良恶恋委拥娜妙探呀营退摇弄桌熟诺宣银势奖宫忽套康供优课鸟喊降 夏困刘罪亡鞋健模败伴守挥鲜财孤枪禁恐伙杰迹妹藸遍盖副坦牌江顺秋萨菜划授归浪听凡预奶雄升碃编典袋莱含盛济蒙棋端腿 招释介烧误 unicode 编码 的一是了我不人在他有这%u4e2a上们来
Java中编码以及Unicode总结 1.基本概念 ●bit 位只能是0或者1 ●byte 字节一个字节是8位，1 byte=8 bits 计算机表示的基本单位 ●KB,MB,GB,TB,PB是以1024与byte进行换算 ●进制用符号进行计数十进制、二进制、八进制(011)、十六进制(0xFF) 字符文字和符号的总称 ●字符集多个字符集合的总称。ASCII字符集、GB2312字符集、GBK字符集、BIG5 字符集、GB18003字符集、Unicode字符集 ●byte可表示2^8=256个字符的表示 0 0×00 0000,0000 1 0×01 0000,0001 2 0×01 0000,0010 127 0×7F 0111,1111 -128 0×80 1000,0000 -2 0xFE 1111,1110 -1 0xFF 1111,1111 ●以补码的形式表示的二进制编码。 -2的表示,2=0000,0010,反码1111,1101,补码=反码+1= 1111,1110表示的就是1111,1110-1=1111,1101,取反就是0000,0010也就是2,所以 就是-2 2.字符集和编码 2.1.字符(Character) 字符(Character)是文字与符号的总称，包括文字、图形符号、数学符号等。 2.2.字符集(Character Set) 一组抽象字符的集合就是字符集(Character Set)。字符集常常和一种具体的语言文字对应起来，该文字中的所有字符或者大部分常用字符就构成了该文字的字符集，比如英文字符集。一组有共同特征的字符也可以组成字符集，比如繁体汉字字符集、日文汉字字符集。字符集的子集也是字符集。 计算机要处理各种字符，就需要将字符和二进制内码对应起来，这种对应关系就是字符编码(Encoding)。制定编码首先要确定字符集，并将字符集内的字符排序，然后和二进制数字对应起来。根据字符集内字符的多少，会确定用几个字节来编码。每种编码都限定了一个明确的字符集合，叫做被编码过的字符集(Coded Character Set)，这是字符集的另外一个含义。通常所说的字符集大多都是指编码字符集(Coded Character Set)。
常用汉字的U n i c o d e 码表 集团标准化工作小组 #Q8QGGQT-GX8G08Q8-GNQGJ8-MHHGN#
包含汉字： 的一是了我不人在他有这个上们来到时大地为子中你说生国年着就那和要她出也得里后自以会家可下而过天去能对小多然于心学么之 都好看起发当没成只如事把还用第样道想作种开美总从无情己面最女但现前些所同日手又行意动方期它头经长儿回位分爱老因很给 名法间斯知世什两次使身者被高已亲其进此话常与活正感见明问力理尔点文几定本公特做外孩相西果走将月十实向声车全信重 三机工物气每并别真打太新比才便夫再书部水像眼等体却加电主界门利海受听表德少克代员许棱先口由死安写性马光白或住难 望教命花结乐色更拉东神记处让母父应直字场平报友关放至张认接告入笑内英军候民岁往何度山觉路带万男边风解叫任金快原 吃妈变通师立象数四失满战远格士音轻目条呢病始达深完今提求清王化空业思切怎非找片罗钱紶吗语元喜曾离飞科言干流欢约 各即指合反题必该论交终林请医晚制球决窢传画保读运及则房早院量苦火布品近坐产答星精视五连司巴奇管类未朋且婚台夜青 北队久乎越观落尽形影红爸百令周吧识步希亚术留市半热送兴造谈容极随演收首根讲整式取照办强石古华諣拿计您装似足双妻 尼转诉米称丽客南领节衣站黑刻统断福城故历惊脸选包紧争另建维绝树系伤示愿持千史谁准联妇纪基买志静阿诗独复痛消社算 义竟确酒需单治卡幸兰念举仅钟怕共毛句息功官待究跟穿室易游程号居考突皮哪费倒价图具刚脑永歌响商礼细专黄块脚味灵改
据般破引食仍存众注笔甚某沉血备习校默务土微娘须试怀料调广蜖苏显赛查密议底列富梦错座参八除跑亮假印设线温虽掉京初 养香停际致阳纸李纳验助激够严证帝饭忘趣支春集丈木研班普导顿睡展跳获艺六波察群皇段急庭创区奥器谢弟店否害草排背止 组州朝封睛板角况曲馆育忙质河续哥呼若推境遇雨标姐充围案伦护冷警贝着雪索剧啊船险烟依斗值帮汉慢佛肯闻唱沙局伯族低 玩资屋击速顾泪洲团圣旁堂兵七露园牛哭旅街劳型烈姑陈莫鱼异抱宝权鲁简态级票怪寻杀律胜份汽右洋范床舞秘午登楼贵吸责 例追较职属渐左录丝牙党继托赶章智冲叶胡吉卖坚喝肉遗救修松临藏担戏善卫药悲敢靠伊村戴词森耳差短祖云规窗散迷油旧适 乡架恩投弹铁博雷府压超负勒杂醒洗采毫嘴毕九冰既状乱景席珍童顶派素脱农疑练野按犯拍征坏骨余承置臓彩灯巨琴免环姆暗 换技翻束增忍餐洛塞缺忆判欧层付阵玛批岛项狗休懂武革良恶恋委拥娜妙探呀营退摇弄桌熟诺宣银势奖宫忽套康供优课鸟喊降 夏困刘罪亡鞋健模败伴守挥鲜财孤枪禁恐伙杰迹妹藸遍盖副坦牌江顺秋萨菜划授归浪听凡预奶雄升碃编典袋莱含盛济蒙棋端腿 招释介烧误 unicode 编码 \u7684\u4e00\u662f\u4e86\u6211\u4e0d\u4eba\u5728\u4ed6\u6709\u8fd9\u4e2a\u4e 0a\u4eec\u6765 \u5230\u65f6\u5927\u5730\u4e3a\u5b50\u4e2d\u4f60\u8bf4\u751f\u56fd\u5e74\u77 40\u5c31\u90a3 \u548c\u8981\u5979\u51fa\u4e5f\u5f97\u91cc\u540e\u81ea\u4ee5\u4f1a\u5bb6\u53 ef\u4e0b\u800c
Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。1990年开始研发，1994年正式公布。随着计算机工作能力的增强，Unicode也在面世以来的十多年里得到普及。 Unicode 是基于通用字符集（Universal Character Set）的标准来发展，并且同时也以书本的形式（The Unicode Standard，目前第五版由Addison-Wesley Professional出版，ISBN-10: 0321480910）对外发表。 2006年6月的最新版本的 Unicode 是 2005年3月31日推出的Unicode 4.1.0 。另外，5.0 Beta已于2005年12月12日推出，以供各会员评价。 大概来说，Unicode 编码系统可分为编码方式和实现方式两个层次。 1.编码方式 Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。 Unicode字符集可以简写为UCS（Unicode Character Set）。早期的Unicode 标准有UCS-2、UCS-4的说法。UCS-2用两个字节编码，UCS-4用4个字节编码。UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个平面（plane）。每个平面根据第3个字节分为256行（row），每行有256个码位（cell）。group 0的平面0被称作BMP（Basic Multilingual Plane）。将UCS-4的BMP去掉前面的两个零字节就得到了UCS-2。 每个平面有2^16=65536个码位。Unicode计划使用了17个平面，一共有17*65536=1114112个码位。在Unicode 5.0.0版本中，已定义的码位只有238605
Unicode汉字编码表 1 Unicode编码表 Unicode目前普遍采用的是UCS-2,它用两个字节来编码一个字符, 比如汉字"经"的编码是0x7ECF,注意字符编码一般用十六进制来 表示,为了与十进制区分,十六进制以0x开头,0x7ECF转换成十进制 就是32463,UCS-2用两个字节来编码字符,两个字节就是16位二进制, 2的16次方等于65536,所以UCS-2最多能编码65536个字符。 编码从0到127的字符与ASCII编码的字符一样,比如字母"a"的Unicode 编码是0x0061,十进制是97,而"a"的ASCII编码是0x61,十进制也是97, 对于汉字的编码,事实上Unicode对汉字支持不怎么好,这也是没办法的, 简体和繁体总共有六七万个汉字,而UCS-2最多能表示65536个,才六万 多个,所以Unicode只能排除一些几乎不用的汉字,好在常用的简体汉字 也不过七千多个,为了能表示所有汉字,Unicode也有UCS-4规范,就是用 4个字节来编码字符,不过现在普遍采用的还是UCS-2，只用两个字节来 编码,看一下Unicode对汉字的编码:
------------------------------------------------------------------------ 2 汉字编码表 U+ 0 1 2 3 4 5 6 7 8 9 A B C D E F ----------------------------------------------------- 4e00 一丁丂七丄丅丆万丈三上下丌不与丏 4e10 丐丑丒专且丕世丗丘丙业丛东丝丞丟 4e20 丠両丢丣两严並丧丨丩个丫丬中丮丯 4e30 丰丱串丳临丵丶丷丸丹为主丼丽举丿 4e40 乀乁乂乃乄久乆乇么义乊之乌乍乎乏 4e50 乐乑乒乓乔乕乖乗乘乙乚乛乜九乞也 4e60 习乡乢乣乤乥书乧乨乩乪乫乬乭乮乯 4e70 买乱乲乳乴乵乶乷乸乹乺乻乼乽乾乿 4e80 亀亁亂亃亄亅了亇予争亊事二亍于亏 4e90 亐云互亓五井亖亗亘亙亚些亜亝亞亟 4ea0 亠亡亢亣交亥亦产亨亩亪享京亭亮亯 4eb0 亰亱亲亳亴亵亶亷亸亹人亻亼亽亾亿 4ec0 什仁仂仃仄仅仆仇仈仉今介仌仍从仏 4ed0 仐仑仒仓仔仕他仗付仙仚仛仜仝仞仟 4ee0 仠仡仢代令以仦仧仨仩仪仫们仭仮仯 4ef0 仰仱仲仳仴仵件价仸仹仺任仼份仾仿 4f00 伀企伂伃伄伅伆伇伈伉伊伋伌伍伎伏 4f10 伐休伒伓伔伕伖众优伙会伛伜伝伞伟 4f20 传伡伢伣伤伥伦伧伨伩伪伫伬伭伮伯
\u7684\u4e00\u662f\u4e86\u6211\u4e0d\u4eba\u5728\u4ed6\u6709\u8fd9\u4e2a\u4e0a\u4 eec\u6765\u5230\u65f6\u5927\u5730\u4e3a\u5b50\u4e2d\u4f60\u8bf4\u751f\u56fd\u5e74\u 7740\u5c31\u90a3\u548c\u8981\u5979\u51fa\u4e5f\u5f97\u91cc\u540e\u81ea\u4ee5\u4f1a\ u5bb6\u53ef\u4e0b\u800c\u8fc7\u5929\u53bb\u80fd\u5bf9\u5c0f\u591a\u7136\u4e8e\u5fc3 \u5b66\u4e48\u4e4b\u90fd\u597d\u770b\u8d77\u53d1\u5f53\u6ca1\u6210\u53ea\u5982\u4 e8b\u628a\u8fd8\u7528\u7b2c\u6837\u9053\u60f3\u4f5c\u79cd\u5f00\u7f8e\u603b\u4ece\u 65e0\u60c5\u5df1\u9762\u6700\u5973\u4f46\u73b0\u524d\u4e9b\u6240\u540c\u65e5\u624 b\u53c8\u884c\u610f\u52a8\u65b9\u671f\u5b83\u5934\u7ecf\u957f\u513f\u56de\u4f4d\u52 06\u7231\u8001\u56e0\u5f88\u7ed9\u540d\u6cd5\u95f4\u65af\u77e5\u4e16\u4ec0\u4e24\u 6b21\u4f7f\u8eab\u8005\u88ab\u9ad8\u5df2\u4eb2\u5176\u8fdb\u6b64\u8bdd\u5e38\u4e0e \u6d3b\u6b63\u611f\u89c1\u660e\u95ee\u529b\u7406\u5c14\u70b9\u6587\u51e0\u5b9a\u6 72c\u516c\u7279\u505a\u5916\u5b69\u76f8\u897f\u679c\u8d70\u5c06\u6708\u5341\u5b9e\ u5411\u58f0\u8f66\u5168\u4fe1\u91cd\u4e09\u673a\u5de5\u7269\u6c14\u6bcf\u5e76\u522 b\u771f\u6253\u592a\u65b0\u6bd4\u624d\u4fbf\u592b\u518d\u4e66\u90e8\u6c34\u50cf\u7 73c\u7b49\u4f53\u5374\u52a0\u7535\u4e3b\u754c\u95e8\u5229\u6d77\u53d7\u542c\u8868 \u5fb7\u5c11\u514b\u4ee3\u5458\u8bb8\u7a1c\u5148\u53e3\u7531\u6b7b\u5b89\u5199\u6 027\u9a6c\u5149\u767d\u6216\u4f4f\u96be\u671b\u6559\u547d\u82b1\u7ed3\u4e50\u8272 \u66f4\u62c9\u4e1c\u795e\u8bb0\u5904\u8ba9\u6bcd\u7236\u5e94\u76f4\u5b57\u573a\u5e 73\u62a5\u53cb\u5173\u653e\u81f3\u5f20\u8ba4\u63a5\u544a\u5165\u7b11\u5185\u82f1\u 519b\u5019\u6c11\u5c81\u5f80\u4f55\u5ea6\u5c71\u89c9\u8def\u5e26\u4e07\u7537\u8fb9\ u98ce\u89e3\u53eb\u4efb\u91d1\u5feb\u539f\u5403\u5988\u53d8\u901a\u5e08\u7acb\u8c6 1\u6570\u56db\u5931\u6ee1\u6218\u8fdc\u683c\u58eb\u97f3\u8f7b\u76ee\u6761\u5462\u7 5c5\u59cb\u8fbe\u6df1\u5b8c\u4eca\u63d0\u6c42\u6e05\u738b\u5316\u7a7a\u4e1a\u601d\ u5207\u600e\u975e\u627e\u7247\u7f57\u94b1\u7d36\u5417\u8bed\u5143\u559c\u66fe\u79 bb\u98de\u79d1\u8a00\u5e72\u6d41\u6b22\u7ea6\u5404\u5373\u6307\u5408\u53cd\u9898 \u5fc5\u8be5\u8bba\u4ea4\u7ec8\u6797\u8bf7\u533b\u665a\u5236\u7403\u51b3\u7aa2\u4f 20\u753b\u4fdd\u8bfb\u8fd0\u53ca\u5219\u623f\u65e9\u9662\u91cf\u82e6\u706b\u5e03\u5 4c1\u8fd1\u5750\u4ea7\u7b54\u661f\u7cbe\u89c6\u4e94\u8fde\u53f8\u5df4\u5947\u7ba1\u 7c7b\u672a\u670b\u4e14\u5a5a\u53f0\u591c\u9752\u5317\u961f\u4e45\u4e4e\u8d8a\u89c2 \u843d\u5c3d\u5f62\u5f71\u7ea2\u7238\u767e\u4ee4\u5468\u5427\u8bc6\u6b65\u5e0c\u4e 9a\u672f\u7559\u5e02\u534a\u70ed\u9001\u5174\u9020\u8c08\u5bb9\u6781\u968f\u6f14\u 6536\u9996\u6839\u8bb2\u6574\u5f0f\u53d6\u7167\u529e\u5f3a\u77f3\u53e4\u534e\u8ae3 \u62ff\u8ba1\u60a8\u88c5\u4f3c\u8db3\u53cc\u59bb\u5c3c\u8f6c\u8bc9\u7c73\u79f0\u4e3d \u5ba2\u5357\u9886\u8282\u8863\u7ad9\u9ed1\u523b\u7edf\u65ad\u798f\u57ce\u6545\u5 386\u60ca\u8138\u9009\u5305\u7d27\u4e89\u53e6\u5efa\u7ef4\u7edd\u6811\u7cfb\u4f24\ u793a\u613f\u6301\u5343\u53f2\u8c01\u51c6\u8054\u5987\u7eaa\u57fa\u4e70\u5fd7\u975 9\u963f\u8bd7\u72ec\u590d\u75db\u6d88\u793e\u7b97\u4e49\u7adf\u786e\u9152\u9700\u 5355\u6cbb\u5361\u5e78\u5170\u5ff5\u4e3e\u4ec5\u949f\u6015\u5171\u6bdb\u53e5\u606f \u529f\u5b98\u5f85\u7a76\u8ddf\u7a7f\u5ba4\u6613\u6e38\u7a0b\u53f7\u5c45\u8003\u7a8 1\u76ae\u54ea\u8d39\u5012\u4ef7\u56fe\u5177\u521a\u8111\u6c38\u6b4c\u54cd\u5546\u7 93c\u7ec6\u4e13\u9ec4\u5757\u811a\u5473\u7075\u6539\u636e\u822c\u7834\u5f15\u98df\ u4ecd\u5b58\u4f17\u6ce8\u7b14\u751a\u67d0\u6c89\u8840\u5907\u4e60\u6821\u9ed8\u52 a1\u571f\u5fae\u5a18\u987b\u8bd5\u6000\u6599\u8c03\u5e7f\u8716\u82cf\u663e\u8d5b\u 67e5\u5bc6\u8bae\u5e95\u5217\u5bcc\u68a6\u9519\u5ea7\u53c2\u516b\u9664\u8dd1\u4ea
计算机常见编码 一．有关编码的基础知识 1. 位 bit 最小的单元 字节 byte 机器语言的单位 1byte=8bits 1KB=1024byte 1MB=1024KB 1GB=1024MB 2. 二进制 binary 八进制 octal 十进制 decimal 十六进制 hex 3. 字符：是各种文字和符号的总称，包括各个国家的文字，标点符号，图形符号，数字等。 字符集：字符集是多个符号的集合，每个字符集包含的字符个数不同。 字符编码：字符集只是规定了有哪些字符，而最终决定采用哪些字符，每一 个字符用多少字节表示等问题，则是由编码来决定的。计算机要 准确的处理各种字符集文字，需要进行字符编码，以便计算机能 够识别和存储各种文字。 二．常见字符集的编码介绍： 常见的字符集有：ASCII 字符集，GB2312 字符集，BIG5 字符集，GB18030 字符集，Unicode 字符集，下面一一介绍： 1. ASCII 字符集： 定义： 美国信息互换标准代码，是基于罗马字母表的一套电脑编码系统，主要显示 英语和一些西欧语言，是现今最通用的单字节编码系统。 包含内容： 控制字符（回车键，退格，换行键等） 可显示字符（英文大小写，阿拉伯数字，西文符号） 扩展字符集（表格符号，计算符号，希腊字母，拉丁符号） 编码方式： 第 0-31 号及 127 号是控制字符或通讯专用字符； 第 32-126 号是字符，其中 48-57 号为 0-9 十个阿拉伯数字，65-90 号为 26 个大写英文字母，97-122 号为 26 个英文小写字母，其余为一些标点符号，运 算符号等。 在计算机存储单元中，一个 ASCII 码值占一个字节（8 个二进制位），最高位 是用作奇偶检验位。【奇偶校验是指：在代码传送的过程中，用来检验是否 出错的一种方法。】奇偶校验分为奇校验和偶校验。奇校验规定：正确的代 码一个字节中 1 的个数必须是奇数，若非奇数，则在最高位添 1；偶校验规 定：正确的代码一个字节中 1 的个数必须是奇数，若非奇数，则在最高位添 1。
Unicode通用字符集 Unicode（统一码、万国码、单一码）是一种在计算机上使用的字符编码。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。1990年开始研发，1994年正式公布。随着计算机工作能力的增强，Unicode 也在面世以来的十多年里得到普及。 Unicode 是基于通用字符集（Universal Character Set）的标准来发展，并且同时也以书本的形式（The Unicode Standard，目前第五版由Addison-Wesley Professional出版 unicode，ISBN-10: 0321480910）对外发表。 2006年7月的最新版本的Unicode 是5.0版本。2005年3月31日推出的Unicode 4.1.0 。另外，5.0 Beta于2005年12月12日推出，5.2版本（unicode standard）于2009年10月1日正式推出，以供各会员评价。 目前Unicode标准，6.1版已发布（2012年1月31日）。在unicode联盟网站上可以查看完整的6.1的核心规范。 Unicode定义了大到足以代表人类所有可读字符的字符集。 Java语言就用到了Unicode编码，从而实现了该语言的国际通用性。 编辑本段Unicode 的编码和实现 大概来说，Unicode 编码系统可分为编码方式和实现方式两个层次。 编码方式 Unicode是国际组织制定的可以容纳世界上所有文字和符号的字符编码方案。Unicode 用数字0-0x10FFFF来映射这些字符，最多可以容纳1114112个字符，或者说有1114112个码位。码位就是可以分配给字符的数字。UTF-8、UTF-16、UTF-32都是将数字转换到程序数据的编码方案。 通用字符集（Universal Character Set，UCS）是由ISO制定的ISO 10646（或称ISO/IEC 10646）标准所定义的标准字符集。UCS-2用两个字节编码，UCS-4用4个字节编码。 历史上存在两个独立的尝试创立单一字符集的组织，即国际标准化组织（ISO）和多语言软件制造商组成的统一码联盟。前者开发的ISO/IEC 10646 项目，后者开发的统一码项目。因此最初制定了不同的标准。 1991年前后，两个项目的参与者都认识到，世界不需要两个不兼容的字符集。于是，它们开始合并双方的工作成果，并为创立一个单一编码表而协同工作。从Unicode 2.0开始，Unicode采用了与ISO 10646-1相同的字库和字码；ISO也承诺，ISO 10646将不会替超出U+10FFFF的UCS-4编码赋值，以使得两者保持一致。两个项目仍都存在，并独立地公布各自的标准。但统一码联盟和ISO/IEC JTC1/SC2都同意保持两者标准的码表兼容，并紧密地共同调整任何未来的扩展。在发布的时候，Unicode一般都会采用有关字码最常见的字型，但ISO 10646一般都尽可能采用Century字型。 UCS-4根据最高位为0的最高字节分成2^7=128个group。每个group再根据次高字节分为256个平面（plane）。每个平面根据第3个字节分为256行（row），每行有256个码位（cell）。group 0的平面0被称作BMP（Basic Multilingual Plane）。将UCS-4的BMP去掉前
選擇題共33題(共0分) ( )1. 萬國碼（Unicode）編碼系統是使用多少位元來表示一個字元？(A)2 (B)8 (C)16 (D)32 ( )2. 下列敘述何者正確？(A)某些二進位數字，無法以十進位數字表示(B)八個位元可以表示128種二進位值(C)以二進位表示數值資料時，一般均以數值的最右邊位元作為正負符號位元(D)數值進行數系轉換時，一個十六進位數字等於四個二進位數字 ( )3. 請問十進位數字2004，轉為十六進位數字的結果為何？(A)3724 (B)07D4 (C)083E (D)D470 ( )4. 某電腦以8bit表示一整數，其負數以2的補數方式表示，則–31的二進位表示為何？ (A)11100010 (B)11100001 (C)11100011 (D)11100100 ( )5. 十六進位數字1B，其二的補數表示法（2's Complement）的值為(A)E4 (B)E5 (C)FB (D)B1 ( )6. 政府所公佈適用於微型電子計算機的中文交換碼為(A)全漢字交換碼（CCCII）(B)電信碼(C)通用漢字交換碼（CISCII）(D)BIG-5 ( )7. 下列何者正確？(A)(1011.101)2 = (23.11)4(B)(1101.011)2 = (15.11)8(C)(3.23)16 = (11.1011)2(D)(101.01)4 = (11.1)16 ( )8. 當以八個位元來表示整數資料，且最左邊位元作為正負符號位元時，其所能表示之最大值為(A)255 (B)256 (C)127 (D)128 ( )9. 將(7.625)10轉換為二進位制，則為？(A)(0111.101)2(B)(0111.111)2 (C)(1101.101)2(D)(0111.011)2 ( )10. 下列各不同進位制的值，何者為最大？(A)1101(2)(B)21(8)(C)12(16) (D)15(10) ( )11. 若系統使用2的補數法來儲存負數，將十進位數–17轉換為八位元之二進位數表示時，正確值應為(A)00010001 (B)11101110 (C)11101111 (D)00010000 ( )12. 十進位(38)10等於二進位值(A)100111 (B)100110 (C)100101 (D)100011 ( )13. 不同進位制之間的計算(014)16–(0.02)8，其答案為何？(A)(0.02)8(B)(0.06)8 (C)(0.03)16(D)(0.0C)16 ( )14. 下列哪一個數值和(1100)2的值相等？(A)(111)3(B)(24)4(C)(12)8 (D)(0C)16 ( )15. 下列哪一個數值與(62.3)8–(36.5)8的運算結果相等？(A)(23.6)8(B)(23.8)8 (C)(25.8)8(D)(26.0)8 ( )16. 八進位(127)8等於十六進位值(A)55 (B)57 (C)59 (D)5B ( )17. 下列何者在八進或十進位數字系統之下，其基底不同但其值皆相同？(A)7 (B)10 (C)13 (D)16 ( )18. (2B)16的2的補數是？(A)(11010100)2(B)(11010101)2(C)(00101100)2 (D)(00101011)2 ( )19. 目前個人電腦最常使用的資訊交換碼是美國國家資訊交換標準碼簡稱為：(A)ASCII (B)BCD (C)ANSI (D)EBCDIC ( )20. 以符號位元表示法（Signed-magnitude）之11位元整數，可以表達之最小負整數值
Unicode字符列表（超完整）Unicode, 字符, 列表 代码显示描述 U+0020 空格 U+0021 ! 叹号 U+0022 " 双引号 U+0023 # 井号 U+0024 $ 价钱／货币符号 U+0025 % 百分比符号 U+0026 & 英文“and”的简写符号U+0027 ' 引号 U+0028 ( 开圆括号 U+0029 ) 关圆括号 U+002A * 星号 U+002B + 加号 U+002C , 逗号 U+002D - 连字号／减号 U+002E . 句号 U+002F / 由右上至左下的斜线 U+0030 0 数字 0 U+0031 1 数字 1 U+0032 2 数字 2 U+0033 3 数字 3 U+0034 4 数字 4 U+0035 5 数字 5 U+0036 6 数字 6 U+0037 7 数字 7 U+0038 8 数字 8 U+0039 9 数字 9 U+003A : 冒号 U+003B ; 分号 U+003C < 小于符号 U+003D = 等于号 U+003E > 大于符号 U+003F ? 问号 U+0040 @ 英文“at”的简写符号U+0041 A 拉丁字母 A U+0042 B 拉丁字母 B U+0043 C 拉丁字母 C U+0044 D 拉丁字母 D U+0045 E 拉丁字母 E U+0046 F 拉丁字母 F U+0047 G 拉丁字母 G
U+0049 I 拉丁字母 I U+004A J 拉丁字母 J U+004B K 拉丁字母 K U+004C L 拉丁字母 L U+004D M 拉丁字母 M U+004E N 拉丁字母 N U+004F O 拉丁字母 O U+0050 P 拉丁字母 P U+0051 Q 拉丁字母 Q U+0052 R 拉丁字母 R U+0053 S 拉丁字母 S U+0054 T 拉丁字母 T U+0055 U 拉丁字母 U U+0056 V 拉丁字母 V U+0057 W 拉丁字母 W U+0058 X 拉丁字母 X U+0059 Y 拉丁字母 Y U+005A Z 拉丁字母 Z U+005B [ 开方括号 U+005C \ 由左上至右下的斜线 U+005D ] 关方括号 U+005E ^ 抑扬（重音）符号 U+005F _ 底线 U+0060 ` 重音符 U+0061 a 拉丁字母 a U+0062 b 拉丁字母 b U+0063 c 拉丁字母 c U+0064 d 拉丁字母 d U+0065 e 拉丁字母 e U+0066 f 拉丁字母 f U+0067 g 拉丁字母 g U+0068 h 拉丁字母 h U+0069 i 拉丁字母 i U+006A j 拉丁字母 j U+006B k 拉丁字母 k U+006C l 拉丁字母 l（L的小写）U+006D m 拉丁字母 m U+006E n 拉丁字母 n U+006F o 拉丁字母 o U+0070 p 拉丁字母 p U+0071 q 拉丁字母 q U+0072 r 拉丁字母 r U+0073 s 拉丁字母 s