Java字符编码知识简介 .

/article/9156527.html

1、基本信息

摘要：在Java应用程序特别是Web应用中，经常遇到字符的编码问题。为了防止出现乱码，首先需要了解字符编码的基本概念以及Java是如何处理字符编码的，这样就可以有目的地在输入/输出环节中增加必要的转码。本文将分以下几部分介绍：

1. 什么是字符集？什么是编码？

2. 常用字符集有哪些？

3. 为什么会有乱码？

4. Java字符编码

5. JSP编码

6. 有没有万金油？

7. 参考资料和推荐参阅

2、什么是字符集?什么是编码?

l 字符(Character)：是文字与符号的总称，包括文字、图形符号、数学符号等。

l 字符集(Charset)：就是一组抽象字符的集合。

字符集常常和一种具体的语言文字对应起来，该文字中的所有字符或者大部分常用字符就构成了该文字的字符集，比如英文字符集。

一组有共同特征的字符也可以组成字符集，比如繁体汉字字符集、日文汉字字符集。

字符集的子集也是字符集。

计算机要处理各种字符，就需要将字符和二进制内码对应起来，这种对应关系就是字符

l 编码(Encoding)：

制定编码首先要确定字符集，并将字符集内的字符排序，然后和二进制数字对应起来。根据字符集内字符的多少，会确定用几个字节来编码。

每种编码都限定了一个明确的字符集合，叫做被编码过的字符集(Coded Character Set)，这是字符集的另外一个含义。通常所说的字符集大多是这个含义。

3、常用字符集有哪些?

ASCII：

American Standard Code for Information Interchange，美国信息交换标准码。

目前计算机中用得最广泛的字符集及其编码，由美国国家标准局(ANSI)制定。 它已被国际标准化组织(ISO)定为国际标准，称为ISO 646标准。 ASCII字符集由控制字符和图形字符组成。 在计算机的存储单元中，一个ASCII码值占一个字节(8个二进制位)，其最高位(b7)用作奇偶校验位。所谓奇偶校验，是指在代码传送过程中用来检验是否出现错误的一种方法，一般分奇校验和偶校验两种。奇校验规定：正确的代码一个字节中1的个数必须是奇数，若非奇数，则在最高位b7添1。偶校验规定：正确的代码一个字节中1的个数必须是偶数，若非偶数，则在最高位b7添1。

ISO 8859-1：

全称ISO/IEC 8859，是国际标准化组织(ISO)及国际电工委员会(IEC)联合制定的一系列8位字符集的标准，现时定义了15个字符集。

ASCII收录了空格及94个“可印刷字符”，足以给英语使用。但是，其他使用拉丁字母的语言(主要是欧洲国家的语言)，都有一定数量的变音字母，故可以使用ASCII及控制字符以外的区域来储存及表示。除了使用拉丁字母的语言外，使用西里尔字母的东欧语言、希腊语、泰语、现代阿拉伯语、希伯来语等，都可以使用这个形式来储存及表示。

ISO 8859-1 (Latin-1) - 西欧语言

很明显，iso8859-1编码表示的字符范围很窄，无法表示中文字符。 但是，由于是单字节编码，和计算机最基础的表示单位一致，所以很多时候，仍旧使用iso8859-1编码来表示。 而且在很多协议上，默认使用该编码。

UCS：

通用字符集(Universal Character Set，UCS)是由ISO制定的ISO 10646(或称ISO/IEC 10646)标准所定义的字符编码方式，采用4字节编码。

UCS包含了已知语言的所有字符。除了拉丁语、希腊语、斯拉夫语、希伯来语、阿拉伯语、亚美尼亚语、格鲁吉亚语，还包括中文、日文、韩文这样的象形文字，UCS还包括大量的图形、印刷、数学、科学符号。

² UCS-2： 与unicode的2byte编码基本一样。

² UCS-4： 4byte编码, 目前是在UCS-2前加上2个全零的byte。

Unicode：

Unicode(统一码、万国码、单一码)是一种在计算机上使用的字符编码。

Unicode是http：//www.unicode.org制定的编码机制， 要将全世界常用文字都函括进去。它为每种语言中的每个字符设定了统一并且唯一的二进制编码，以满足跨语言、跨平台进行文本转换、处理的要求。 1990年开始研发，1994年正式公布。随着计算机工作能力的增强，Unicode也在面世以来的十多年里得到普及。但自从unicode2.0开始，unicode采用了与ISO 10646-1相同的字库和字码，ISO也承诺ISO10646将不会给超出0x10FFFF的UCS-4编码赋值，使得两者保持一致。

Unicode的编码方式与ISO 10646的通用字符集(Universal Character Set，UCS)概念相对应，目前的用于实用的Unicode版本对应于UCS-2，使用16位的编码空间。也就是每个字符占用2个字节，基本满足各种语言的使用。实际上目前版本的Unicode尚未填充满这16位编码，保留了大量空间作为特殊使用或将来扩展。

UTF： Unicode 的实现方式不同于编码方式。

一个字符的Unicode编码是确定的，但是在实际传输过程中，由于不同系统平台的设计不一定一致，以及出于节省空间的目的，对Unicode编码的实现方式有所不同。Unicode的实现方式称为Unicode转换格式(Unicode Translation Format，简称为 UTF)。

UTF-8： 8bit变长编码，对于大多数常用字符集(ASCII中0~127字符)它只使用单字节，而对其它常用字符(特别是朝鲜和汉语会意文字)，它使用3字节。

UTF-16： 16bit编码，是变长码，大致相当于20位编码，值在0到0x10FFFF之间，基本上就是unicode编码的实现，与CPU字序有关。

汉字编码：

GB2312字集是简体字集，全称为GB2312(80)字集，共包括国标简体汉字6763个。

BIG5字集是台湾繁体字集，共包括国标繁体汉字13053个。

GBK字集是简繁字集，包括了GB字集、BIG5字集和一些符号，共包括21003个字符。

GB18030是国家制定的一个强制性大字集标准，全称为GB18030-2000，它的推出使汉字集有了一个“大一统”的标准。

ANSI和Unicode big endia：

我们在Windows系统中保存文本文件时通常可以选择编码为ANSI、Unicode、Unicode big endian和UTF-8，这里的ANSI和Unicode big endia是什么编码呢?

ANSI：使用2个字节来代表一个字符的各种汉字延伸编码方式，称为ANSI编码。 在简体中文系统下，ANSI编码代表GB2312编码，在日文操作系统下，ANSI编码代表JIS编码。

Unicode big endia： UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。 Unicode规范中推荐的标记字节顺序的方法是BOM(即Byte Order Mark)。 在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。 UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH
NO-BREAK SPACE"。 这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。 因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。 Windows就是使用BOM来标记文本文件的编码方式的。

4、为什么会乱码?

乱码是个老问题，字符在保存时的编码格式如果和要显示的编码格式不一样的话，就会出现乱码问题。在我们的Web应用中，从底层数据库编码、Web应用程序编码到HTML页面编码，如果有一项不一致的话，就会出现乱码。 所以，解决乱码问题说难也难说简单也简单，关键是让交互系统之间编码一致。

5、Java字符编码

Java在运行期一律以unicode来存储字符,这样有利的支持了多语言环境。

Java在读取文件的时候默认是按照系统默认语言（字符集）编码来解码文件，读取和保存时候的编码不一致也导致程序中参数值错误，用FileInputStream类读取文件可以指定编码读取。

Java在输出到系统显示时，会把内存中变量字符再通过系统默认语言（字符集）编码去转换，所以在输出过程中也会碰到一系列的编码问题。

　首先要了解JAVA处理字符的原理。JAVA使用UNICODE来存储字符数据，处理字符时通常有三个步骤：

　　- 按指定的字符编码形式，从源输入流中读取字符数据

　　- 以UNICODE编码形式将字符数据存储在内存中

　　- 按指定的字符编码形式，将字符数据编码并写入目的输出流中。

　　所以JAVA处理字符时总是经过了两次编码转换，一次是从指定编码转换为UNICODE编码，一次是从UNICODE编码转换为指定编码。如果在读入时用 错误的形式解码字符，则内存存储的是错误的UNICODE字符。而从最初文件中读出的字符数据，到最终在屏幕终端显示这些字符，期间经过了应用程序的多次 转换。如果中间某次字符处理，用错误的编码方式解码了从输入流读取的字符数据，或用错误的编码方式将字符写入输出流，则下一个字符数据的接收者就会编解码 出错，从而导致最终显示乱码。

　　这一点，是我们分析字符编码问题以及解决问题的指导思想。

　　好，现在我们开始一只只的解决这些乱码怪兽。

　　一、在JAVA文件中硬编码中文字符，在eclipse中运行，控制台输出了乱码。

　　例如，我们在JAVA文件中写入以下代码：

　　String text = "大家好";

　　System.out.println(text);

　　如果我们是在eclipse里编译运行，可能看到的结果是类似这样的乱码：????。那么，这是为什么呢？

　　我们先来看看整个字符的转换过程。

　　1. 在eclipse窗口中输入中文字符，并保存成UTF-8的JAVA文件。这里发生了多次字符编码转换。不过因为我们相信eclipse的正确性，所以我们不用分析其中的过程，只需要相信保存下的JAVA文件确实是UTF-8格式。

　　2. 在eclipse中编译运行此JAVA文件。这里有必要详细分析一下编译和运行时的字符编码转换。

　　- 编译：我们用javac编译JAVA文件时，javac不会智能到猜出你所要编译的文件是什么编码类型的，所以它需要指定读取文件所用的编码类型。默认 javac使用平台缺省的字符编码类型来解析JAVA文件。平台缺省编码是操作系统决定的，我们使用的是中文操作系统，语言区域设置通常都是中国大陆，所 以平台缺省编码类型通常是GBK。这个编码类型我们可以在JAVA中使用System.getProperty("file.encoding")来查 看。所以javac会默认使用GBK来解析JAVA文件。如果我们要改变javac所用的编码类型，就要加上-encoding参数，如javac
-encoding utf-8 Test.java。

　　这里要另外提一下的是eclipse使用的是内置的编译器，并不能添加参数，如果要为javac添加参数则建议使用ANT来编译。不过这并非出现乱码的原因，因为eclipse可以为每个JAVA文件设置字符编码类型，而内置编译器会根据此设置来编译JAVA文件。

　　- 运行：编译后字符数据会以UNICODE格式存入字节码文件中。然后eclipse会调用java命令来运行此字节码文件。因为字节码中的字符总是 UNICODE格式，所以java读取字节码文件并没有编码转换过程。虚拟机读取文件后，字符数据便以UNICODE格式存储在内存中了。

　　3. 调用System.out.println来输出字符。这里又发生了字符编码转换。

　　System.out.println使用了PrintStream类来输出字符数据至控制台。PrintStream会使用平台缺省的编码方式来输出字 符。我们的中文系统上缺省方式为GBK，所以内存中的UNICODE字符被转码成了GBK格式，并送到了操作系统的输出服务中。因为我们操作系统是中文系 统，所以往终端显示设备上打印字符时使用的也是GBK编码。如果到这一步，我们的字符其实不再是GBK编码的话，终端就会显示出乱码。

　　那么，在eclipse运行带中文字符的JAVA文件，控制台显示了乱码，是在哪一步转换错误呢？我们一步步来分析。

　　- 保存JAVA文件成UTF-8后，如果再次打开你没有看到乱码，说明这步是正确的。

　　- 用eclipse本身来编译运行JAVA文件，应该没有问题。

　　- System.out.println会把内存中正确的UNICODE字符编码成GBK，然后发到eclipse的控制台去。等等，我们看到在Run Configuration对话框的Common标签里，控制台的字符编码被设置成了UTF-8！问题就在这里。System.out.println已经把字符编码成了GBK，而控制台仍然以UTF-8的格式读取字符，自然会出现乱码。

　　将控制台的字符编码设置为GBK，乱码问题解决。

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

（个人认为：）此例子举的一点都不好，因为如果common设置成utf-8，输出的只要是中文肯定是乱码！

　　（这里补充一点：eclipse的控制台编码是继承了workspace的设置的，通常控制台编码里没有GBK的选项而且不能输入。我们可以先在 workspace的编码设置中输入GBK，然后在控制台的设置中就可以看到GBK的选项了，设置好后再把workspace的字符编码设置改回utf- 8就是。）

6、编码JSP

这里我们主要是介绍JSP页面的两个重要属性：pageEncoding、contentType、charset

pageEncoding是jsp文件本身的编码

contentType的charset是指服务器发送给客户端时的内容编码

charset有两个作用：一是JSP文件的编码方式：在读取JSP文件、生成JAVA类时，源JSP文件中汉字的编码；二是JSP输出流的编码方式：在执行JSP时，往response流里面写入数据的编码方式

当应用服务器将JSP编译成.java文件时，会根据pageEncoding的设定读取jsp，结果是由指定的编码方案翻译成统一的UTF-8 JAVA源码（即.java），如果pageEncoding设定错了，或没有设定，出来的就是中文乱码。

当应用服务器利用已经编译为二进制的JSP(.class)输出页面时，contentType这时则决定了输出页面的编码。

jsp文件不像.java，.java在被编译器读入的时候默认采用的是操作系统所设定的locale所对应的编码，比如中国大陆就是GBK，台湾就是BIG5或者MS950。而一般我们不管是在记事本还是在ue中写代码，如果没有经过特别转码的话，写出来的都是本地编码格式的内容。所以编译器采用的方法刚好可以让虚拟机得到正确的资料。

但是jsp文件不是这样，它没有这个默认转码过程，但是指定了pageEncoding就可以实现正确转码了。

举个例子：

<%@ page contentType="text/html;charset=utf-8" %>

大都会打印出乱码，因为我输入的“你好吗”是gbk的，但是服务器是否正确抓到“你好吗”不得而知。

但是如果更改为

<%@ page contentType="text/html;charset=utf-8" pageEncoding="GBK"%>

这样就服务器一定会是正确抓到“你好吗”了。

7、有没有万金油?

J2EE应用程序是运行在J2EE容器中。在这个系统中，输入途径有很多种：一种是通过页面表单打包成请求（request）发往服务器的；第二种是通过数据库读入；还有第3种输入比较复杂，JSP在第一次运行时总是被编译成Servlet，JSP中常常包含中文字符，那么编译使用javac时，Java将根据默认的操作系统编码作为初始编码。除非特别指定，如在Jbuilder/eclipse中可以指定默认的字符集。

输出途径也有几种：第一种是JSP页面的输出。由于JSP页面已经被编译成Servlet，那么在输出时，也将根据操作系统的默认编码来选择输出编码，除非指定输出编码方式；还有输出途径是数据库，将字符串输出到数据库。

由此看来，一个J2EE系统的输入输出是非常复杂，而且是动态变化的，而Java是跨平台运行的，在实际编译和运行中，都可能涉及到不同的操作系统，如果任由Java自由根据操作系统来决定输入输出的编码字符集，这将不可控制地出现乱码。

正是由于Java的跨平台特性，使得字符集问题必须由具体系统来统一解决，所以在一个Java应用系统中，解决中文乱码的根本办法是明确指定整个应用系统统一字符集。

指定统一字符集时，到底是指定ISO8859_1 、GBK还是UTF-8呢？

1）如统一指定为ISO8859_1，因为目前大多数软件都是西方人编制的，他们默认的字符集就是ISO8859_1，包括操作系统Linux和数据库MySQL等。这样，如果指定Jive统一编码为ISO8859_1，那么就有下面3个环节必须把握：

开发和编译代码时指定字符集为ISO8859_1。

运行操作系统的默认编码必须是ISO8859_1，如Linux。

在JSP头部声明。

2）如果统一指定为GBK中文字符集，上述3个环节同样需要做到，不同的是只能运行在默认编码为GBK的操作系统，如中文Windows。

统一编码为ISO8859_1和GBK虽然带来编制代码的方便，但是各自只能在相应的操作系统上运行。但是也破坏了Java跨平台运行的优越性，只在一定范围内行得通。例如，为了使得GBK编码在linux上运行，设置Linux编码为GBK。

那么有没有一种除了应用系统以外不需要进行任何附加设置的中文编码根本解决方案呢？

将Java/J2EE系统的统一编码定义为UTF-8。UTF-8编码是一种兼容所有语言的编码方式，惟一比较麻烦的就是要找到应用系统的所有出入口，然后使用UTF-8去“结扎”它。

一个J2EE应用系统需要做下列几步工作：

开发和编译代码时指定字符集为UTF-8。JBuilder和Eclipse都可以在项目属性中设置。

使用过滤器，如果所有请求都经过一个Servlet控制分配器，那么使用Servlet的filter执行语句，将所有来自浏览器的请求（request）转换为UTF-8，因为浏览器发过来的请求包根据浏览器所在的操作系统编码，可能是各种形式编码。关键一句：

request.setCharacterEncoding("UTF-8")

在JSP头部声明：

＜%@ page contentType="text/html;charset= UTF-8" %＞

在Jsp的html代码中，声明UTF-8：

＜ＭＥＴＡ http-equiv="Content-Type" ＣＯＮＴＥＴ="text/html; charset=utf-8"＞

设定数据库连接方式是UTF-8。例如连接MYSQL时配置URL如下：

jdbc：mysql：//localhost：3306/test?useUnicode=true&characterEncoding=UTF-8

一般数据库都可以通过管理设置设定UTF-8。其他和外界交互时能够设定编码时就设定UTF-8，例如读取文件，操作XML等。

参考资料

1 http：//java.ccidnet.com/art/3559/20070614/1112507_1.html

2 http：//www.jdon.com/idea/chinesejava.htm

3 http：//www.bitscn.com/java/webservice/200611/82116.html

4 http：//www.javaeye.com/article/97803

===========/article/4070428.html

各种字符集和字符编码

博客分类：
其它

相信大家一定碰到过，打开某个网页，却显示一堆像乱码，如"бЇЯАзЪСЯ"、"�????????"？还记得HTTP中的Accept-Charset、Accept-Encoding、Accept-Language、Content-Encoding、Content-Language等消息头字段？这些就是接下来我们要探讨的。

目录：

1.基础知识

2.常用字符集和字符编码

2.1. ASCII字符集&编码

2.2. GBXXXX字符集&编码

2.3. BIG5字符集&编码

3.伟大的创想Unicode

3.1.UCS & UNICODE

3.2.UTF-32
3.3.UTF-16
3.4.UTF-8

4.Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language

参考文献&进一步阅读

1.基础知识

计算机中储存的信息都是用二进制数表示的；而我们在屏幕上看到的英文、汉字等字符是二进制数转换之后的结果。通俗的说，按照何种规则将字符存储在计算机中，如'a'用什么表示，称为"编码"；反之，将存储在计算机中的二进制数解析显示出来，称为"解码"，如同密码学中的加密和解密。在解码过程中，如果使用了错误的解码规则，则导致'a'解析成'b'或者乱码。

字符集（Charset）：是一个系统支持的所有抽象字符的集合。字符是各种文字和符号的总称，包括各国家文字、标点符号、图形符号、数字等。

字符编码（Character Encoding）：是一套法则，使用该法则能够对自然语言的字符的一个集合（如字母表或音节表），与其他东西的一个集合（如号码或电脉冲）进行配对。即在符号集合与数字系统之间建立对应关系，它是信息处理的一项基本技术。通常人们用符号集合（一般情况下就是文字）来表达信息。而以计算机为基础的信息处理系统则是利用元件（硬件）不同状态的组合来存储和处理信息的。元件不同状态的组合能代表数字系统的数字，因此字符编码就是将符号转换为计算机可以接受的数字系统的数，称为数字代码。

2.常用字符集和字符编码

常见字符集名称：ASCII字符集、GB2312字符集、BIG5字符集、GB18030字符集、Unicode字符集等。计算机要准确的处理各种字符集文字，需要进行字符编码，以便计算机能够识别和存储各种文字。

2.1. ASCII字符集&编码

ASCII（American
Standard Code for Information
Interchange，美国信息交换标准代码）是基于拉丁字母的一套电脑编码系统。它主要用于显示现代英语，而其扩展版本EASCII则可以勉强显示其他西欧语言。它是现今最通用的单字节编码系统（但是有被Unicode追上的迹象），并等同于国际标准ISO/IEC
646。

ASCII字符集：主要包括控制字符（回车键、退格、换行键等）；可显示字符（英文大小写字符、阿拉伯数字和西文符号）。

ASCII编码：将ASCII字符集转换为计算机可以接受的数字系统的数的规则。使用7位（bits）表示一个字符，共128字符；但是7位编码的字符集只能支持128个字符，为了表示更多的欧洲常用字符对ASCII进行了扩展，ASCII扩展字符集使用8位（bits）表示一个字符，共256字符。ASCII字符集映射到数字编码规则如下图所示：



图1 ASCII编码表



图2 扩展ASCII编码表
ASCII的最大缺点是只能显示26个基本拉丁字母、阿拉伯数目字和英式标点符号，因此只能用于显示现代美国英语（而且在处理英语当中的外来词如naïve、café、élite等等时，所有重音符号都不得不去掉，即使这样做会违反拼写规则）。而EASCII虽然解决了部份西欧语言的显示问题，但对更多其他语言依然无能为力。因此现在的苹果电脑已经抛弃ASCII而转用Unicode。

2.2. GBXXXX字符集&编码

计算机发明之处及后面很长一段时间，只用应用于美国及西方一些发达国家，ASCII能够很好满足用户的需求。但是当天朝也有了计算机之后，为了显示中文，必须设计一套编码规则用于将汉字转换为计算机可以接受的数字系统的数。

天朝专家把那些127号之后的奇异符号们（即EASCII）取消掉，规定：一个小于127的字符的意义与原来相同，但两个大于127的字符连在一起时，就表示一个汉字，前面的一个字节（他称之为高字节）从0xA1用到 0xF7，后面一个字节（低字节）从0xA1到0xFE，这样我们就可以组合出大约7000多个简体汉字了。在这些编码里，还把数学符号、罗马希腊的 字母、日文的假名们都编进去了，连在ASCII里本来就有的数字、标点、字母都统统重新编了两个字节长的编码，这就是常说的"全角"字符，而原来在127号以下的那些就叫"半角"字符了。

上述编码规则就是GB2312。GB2312或GB2312-80是中国国家标准简体中文字符集，全称《信息交换用汉字编码字符集·基本集》，又称GB0，由中国国家标准总局发布，1981年5月1日实施。GB2312编码通行于中国大陆；新加坡等地也采用此编码。中国大陆几乎所有的中文系统和国际化的软件都支持GB2312。GB2312的出现，基本满足了汉字的计算机处理需要，它所收录的汉字已经覆盖中国大陆99.75%的使用频率。对于人名、古汉语等方面出现的罕用字，GB2312不能处理，这导致了后来GBK及GB
18030汉字字符集的出现。下图是GB2312编码的开始部分（由于其非常庞大，只列举开始部分，具体可查看GB2312简体中文编码表）：



图3 GB2312编码表的开始部分
由于GB 2312-80只收录6763个汉字，有不少汉字，如部分在GB 2312-80推出以后才简化的汉字（如"啰"），部分人名用字（如中国前总理朱镕基的"镕"字），台湾及香港使用的繁体字，日语及朝鲜语汉字等，并未有收录在内。于是厂商微软利用GB
2312-80未使用的编码空间，收录GB 13000.1-93全部字符制定了GBK编码。根据微软资料，GBK是对GB2312-80的扩展，也就是CP936字码表
(Code Page 936)的扩展（之前CP936和GB 2312-80一模一样），最早实现于Windows 95简体中文版。虽然GBK收录GB
13000.1-93的全部字符，但编码方式并不相同。GBK自身并非国家标准，只是曾由国家技术监督局标准化司、电子工业部科技与质量监督司公布为"技术规范指导性文件"。原始GB13000一直未被业界采用，后续国家标准GB18030技术上兼容GBK而非GB13000。

GB 18030，全称：国家标准GB 18030-2005《信息技术 中文编码字符集》，是中华人民共和国现时最新的内码字集，是GB
18030-2000《信息技术 信息交换用汉字编码字符集 基本集的扩充》的修订版。与GB 2312-1980完全兼容，与GBK基本兼容，支持GB 13000及Unicode的全部统一汉字，共收录汉字70244个。GB
18030主要有以下特点：

与UTF-8相同，采用多字节编码，每个字可以由1个、2个或4个字节组成。

编码空间庞大，最多可定义161万个字符。
支持中国国内少数民族的文字，不需要动用造字区。

汉字收录范围包含繁体汉字以及日韩汉字



图4 GB18030编码总体结构
本规格的初版使中华人民共和国信息产业部电子工业标准化研究所起草，由国家质量技术监督局于2000年3月17日发布。现行版本为国家质量监督检验总局和中国国家标准化管理委员会于2005年11月8日发布，2006年5月1日实施。此规格为在中国境内所有软件产品支持的强制规格。

2.3. BIG5字符集&编码

Big5，又称为大五码或五大码，是使用繁体中文（正体中文）社区中最常用的电脑汉字字符集标准，共收录13,060个汉字。中文码分为内码及交换码两类，Big5属中文内码，知名的中文交换码有CCCII、CNS11643。Big5虽普及于台湾、香港与澳门等繁体中文通行区，但长期以来并非当地的国家标准，而只是业界标准。倚天中文系统、Windows等主要系统的字符集都是以Big5为基准，但厂商又各自增加不同的造字与造字区，派生成多种不同版本。2003年，Big5被收录到CNS11643中文标准交换码的附录当中，取得了较正式的地位。这个最新版本被称为Big5-2003。

Big5码是一套双字节字符集，使用了双八码存储方法，以两个字节来安放一个字。第一个字节称为"高位字节"，第二个字节称为"低位字节"。"高位字节"使用了0x81-0xFE，"低位字节"使用了0x40-0x7E，及0xA1-0xFE。在Big5的分区中：

0x8140-0xA0FE	保留给用户自定义字符（造字区）
0xA140-0xA3BF	标点符号、希腊字母及特殊符号，包括在0xA259-0xA261，安放了九个计量用汉字：兙兛兞兝兡兣嗧瓩糎。
0xA3C0-0xA3FE	保留。此区没有开放作造字区用。
0xA440-0xC67E	常用汉字，先按笔划再按部首排序。
0xC6A1-0xC8FE	保留给用户自定义字符（造字区）
0xC940-0xF9D5	次常用汉字，亦是先按笔划再按部首排序。
0xF9D6-0xFEFE	保留给用户自定义字符（造字区）

Unicode字符集&UTF编码

3.伟大的创想Unicode

——不得不单独说Unicode

像天朝一样，当计算机传到世界各个国家时，为了适合当地语言和字符，设计和实现类似GB232/GBK/GB18030/BIG5的编码方案。这样各搞一套，在本地使用没有问题，一旦出现在网络中，由于不兼容，互相访问就出现了乱码现象。

为了解决这个问题，一个伟大的创想产生了——Unicode。Unicode编码系统为表达任意语言的任意字符而设计。它使用4字节的数字来表达每个字母、符号，或者表意文字(ideograph)。每个数字代表唯一的至少在某种语言中使用的符号。（并不是所有的数字都用上了，但是总数已经超过了65535，所以2个字节的数字是不够用的。）被几种语言共用的字符通常使用相同的数字来编码，除非存在一个在理的语源学(etymological)理由使不这样做。不考虑这种情况的话，每个字符对应一个数字，每个数字对应一个字符。即不存在二义性。不再需要记录"模式"了。U+0041总是代表'A'，即使这种语言没有'A'这个字符。

在计算机科学领域中，Unicode（统一码、万国码、单一码、标准万国码）是业界的一种标准，它可以使电脑得以体现世界上数十种文字的系统。Unicode
是基于通用字符集（Universal Character Set）的标准来发展，并且同时也以书本的形式[1]对外发表。Unicode
还不断在扩增， 每个新版本插入更多新的字符。直至目前为止的第六版，Unicode 就已经包含了超过十万个字符（在2005年，Unicode
的第十万个字符被采纳且认可成为标准之一）、一组可用以作为视觉参考的代码图表、一套编码方法与一组标准字符编码、一套包含了上标字、下标字等字符特性的枚举等。Unicode 组织（The Unicode Consortium）是由一个非营利性的机构所运作，并主导
Unicode 的后续发展，其目标在于：将既有的字符编码方案以Unicode 编码方案来加以取代，特别是既有的方案在多语环境下，皆仅有有限的空间以及不兼容的问题。

（可以这样理解：Unicode是字符集，UTF-32/ UTF-16/ UTF-8是三种字符编码方案。）

3.1.UCS & UNICODE

通用字符集（Universal Character Set，UCS）是由ISO制定的ISO 10646（或称ISO/IEC
10646）标准所定义的标准字符集。历史上存在两个独立的尝试创立单一字符集的组织，即国际标准化组织（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字型。

3.2.UTF-32

上述使用4字节的数字来表达每个字母、符号，或者表意文字(ideograph)，每个数字代表唯一的至少在某种语言中使用的符号的编码方案，称为UTF-32。UTF-32又称UCS-4是一种将Unicode字符编码的协定，对每个字符都使用4字节。就空间而言，是非常没有效率的。

这种方法有其优点，最重要的一点就是可以在常数时间内定位字符串里的第N个字符，因为第N个字符从第4×Nth个字节开始。虽然每一个码位使用固定长定的字节看似方便，它并不如其它Unicode编码使用得广泛。

3.3.UTF-16

尽管有Unicode字符非常多，但是实际上大多数人不会用到超过前65535个以外的字符。因此，就有了另外一种Unicode编码方式，叫做UTF-16(因为16位 = 2字节)。UTF-16将0–65535范围内的字符编码成2个字节，如果真的需要表达那些很少使用的"星芒层(astral plane)"内超过这65535范围的Unicode字符，则需要使用一些诡异的技巧来实现。UTF-16编码最明显的优点是它在空间效率上比UTF-32高两倍，因为每个字符只需要2个字节来存储（除去65535范围以外的），而不是UTF-32中的4个字节。并且，如果我们假设某个字符串不包含任何星芒层中的字符，那么我们依然可以在常数时间内找到其中的第N个字符，直到它不成立为止这总是一个不错的推断。其编码方法是：

如果字符编码U小于0x10000，也就是十进制的0到65535之内，则直接使用两字节表示；

如果字符编码U大于0x10000，由于UNICODE编码范围最大为0x10FFFF，从0x10000到0x10FFFF之间 共有0xFFFFF个编码，也就是需要20个bit就可以标示这些编码。用U'表示从0-0xFFFFF之间的值，将其前 10 bit作为高位和16 bit的数值0xD800进行 逻辑or 操作，将后10 bit作为低位和0xDC00做 逻辑or 操作，这样组成的 4个byte就构成了U的编码。

对于UTF-32和UTF-16编码方式还有一些其他不明显的缺点。不同的计算机系统会以不同的顺序保存字节。这意味着字符U+4E2D在UTF-16编码方式下可能被保存为4E 2D或者2D 4E，这取决于该系统使用的是大尾端(big-endian)还是小尾端(little-endian)。（对于UTF-32编码方式，则有更多种可能的字节排列。）只要文档没有离开你的计算机，它还是安全的——同一台电脑上的不同程序使用相同的字节顺序(byte
order)。但是当我们需要在系统之间传输这个文档的时候，也许在万维网中，我们就需要一种方法来指示当前我们的字节是怎样存储的。不然的话，接收文档的计算机就无法知道这两个字节4E 2D表达的到底是U+4E2D还是U+2D4E。

为了解决这个问题，多字节的Unicode编码方式定义了一个"字节顺序标记(Byte Order Mark)"，它是一个特殊的非打印字符，你可以把它包含在文档的开头来指示你所使用的字节顺序。对于UTF-16，字节顺序标记是U+FEFF。如果收到一个以字节FF FE开头的UTF-16编码的文档，你就能确定它的字节顺序是单向的(one way)的了；如果它以FE FF开头，则可以确定字节顺序反向了。

3.4.UTF-8

UTF-8（8-bit Unicode Transformation Format）是一种针对Unicode的可变长度字符编码（定长码），也是一种前缀码。它可以用来表示Unicode标准中的任何字符，且其编码中的第一个字节仍与ASCII兼容，这使得原来处理ASCII字符的软件无须或只须做少部份修改，即可继续使用。因此，它逐渐成为电子邮件、网页及其他存储或传送文字的应用中，优先采用的编码。互联网工程工作小组（IETF）要求所有互联网协议都必须支持UTF-8编码。

UTF-8使用一至四个字节为每个字符编码：

128个US-ASCII字符只需一个字节编码（Unicode范围由U+0000至U+007F）。
带有附加符号的拉丁文、希腊文、西里尔字母、亚美尼亚语、希伯来文、阿拉伯文、叙利亚文及它拿字母则需要二个字节编码（Unicode范围由U+0080至U+07FF）。

其他基本多文种平面（BMP）中的字符（这包含了大部分常用字）使用三个字节编码。

其他极少使用的Unicode辅助平面的字符使用四字节编码。

在处理经常会用到的ASCII字符方面非常有效。在处理扩展的拉丁字符集方面也不比UTF-16差。对于中文字符来说，比UTF-32要好。同时，（在这一条上你得相信我，因为我不打算给你展示它的数学原理。）由位操作的天性使然，使用UTF-8不再存在字节顺序的问题了。一份以utf-8编码的文档在不同的计算机之间是一样的比特流。

总体来说，在Unicode字符串中不可能由码点数量决定显示它所需要的长度，或者显示字符串之后在文本缓冲区中光标应该放置的位置；组合字符、变宽字体、不可打印字符和从右至左的文字都是其归因。所以尽管在UTF-8字符串中字符数量与码点数量的关系比UTF-32更为复杂，在实际中很少会遇到有不同的情形。

优点

UTF-8是ASCII的一个超集。因为一个纯ASCII字符串也是一个合法的UTF-8字符串，所以现存的ASCII文本不需要转换。为传统的扩展ASCII字符集设计的软件通常可以不经修改或很少修改就能与UTF-8一起使用。

使用标准的面向字节的排序例程对UTF-8排序将产生与基于Unicode代码点排序相同的结果。（尽管这只有有限的有用性，因为在任何特定语言或文化下都不太可能有仍可接受的文字排列顺序。）

UTF-8和UTF-16都是可扩展标记语言文档的标准编码。所有其它编码都必须通过显式或文本声明来指定。

任何面向字节的字符串搜索算法都可以用于UTF-8的数据（只要输入仅由完整的UTF-8字符组成）。但是，对于包含字符记数的正则表达式或其它结构必须小心。

UTF-8字符串可以由一个简单的算法可靠地识别出来。就是，一个字符串在任何其它编码中表现为合法的UTF-8的可能性很低，并随字符串长度增长而减小。举例说，字符值C0,C1,F5至FF从来没有出现。为了更好的可靠性，可以使用正则表达式来统计非法过长和替代值（可以查看W3 FAQ: Multilingual Forms上的验证UTF-8字符串的正则表达式）。

缺点

因为每个字符使用不同数量的字节编码，所以寻找串中第N个字符是一个O(N)复杂度的操作 — 即，串越长，则需要更多的时间来定位特定的字符。同时，还需要位变换来把字符编码成字节，把字节解码成字符。

4.Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language

在HTTP中，与字符集和字符编码相关的消息头是Accept-Charset/Content-Type，另外主区区分Accept-Charset/Accept-Encoding/Accept-Language/Content-Type/Content-Encoding/Content-Language：

Accept-Charset：浏览器申明自己接收的字符集，这就是本文前面介绍的各种字符集和字符编码，如gb2312，utf-8（通常我们说Charset包括了相应的字符编码方案）；

Accept-Encoding：浏览器申明自己接收的编码方法，通常指定压缩方法，是否支持压缩，支持什么压缩方法（gzip，deflate），（注意：这不是只字符编码）；

Accept-Language：浏览器申明自己接收的语言。语言跟字符集的区别：中文是语言，中文有多种字符集，比如big5，gb2312，gbk等等；

Content-Type：WEB服务器告诉浏览器自己响应的对象的类型和字符集。例如：Content-Type: text/html; charset='gb2312'

Content-Encoding：WEB服务器表明自己使用了什么压缩方法（gzip，deflate）压缩响应中的对象。例如：Content-Encoding：gzip

Content-Language：WEB服务器告诉浏览器自己响应的对象的语言。

参考文献&进一步阅读

百度百科. 字符集. http://baike.baidu.com/view/51987.htm, 2010-12-28

维基百科. 字符编码. http://zh.wikipedia.org/wiki/%E5%AD%97%E7%AC%A6%E7%BC%96%E7%A0%81, 2011-1-5

维基百科. ASCII. http://zh.wikipedia.org/wiki/ASCII, 2011-4-5

维基百科. GB2312. http://zh.wikipedia.org/wiki/GB_2312, 2011-3-17

维基百科. GB18030. http://zh.wikipedia.org/wiki/GB_18030, 2010-3-10

维基百科. GBK. http://zh.wikipedia.org/wiki/GBK, 2011-3-7

维基百科. Unicode. http://zh.wikipedia.org/wiki/Unicode, 2011-4-30

Laruence. 字符编码详解(基础). http://www.laruence.com/2009/08/22/1059.html, 2009-8-22

Jan Hunt. Character Sets and Encoding for Web Designers - UCS/UNICODE. http://www.uninetnews.com/other_standards/charset.php