【转】深入浅出URL编码

版权声明：如有转载请求，请注明出处：http://blog.csdn.net/yzhz  杨争  
一、问题：
        编码问题是JAVA初学者在web开发过程中经常会遇到问题，网上也有大量相关的文章介绍，但其中很多文章并没有对URL中使用了中文等非ASCII的字 符造成服务器后台程序解析出现乱码的问题作出准确的解释和说明。本文将详细介绍由于在URL中使用了中文等非ASCII的字符造成乱码的问题。

1、在URL中中文字符通常出现在以下两个地方：
(1)、Query String中的参数值，比如http://search.china.alibaba.com/search/offer_search.htm?keywords=中国
(2)、servlet path，比如：http://search.china.alibaba.com/selloffer/中国.html


2、出现乱码问题的原因主要是以下几方面：
(1)、浏览器：我们的客户端（浏览器）本身并没有遵循URI编码的规范（http://www.w3.org/International/O-URL-code.html）。
(2)、Servlet服务器：Servlet服务器的没有正确配置。
(3)、开发人员并不了解Servlet的规范和API的含义。

二、基础知识：
1、一个http请求经过的几个环节：
浏览器(ie firefox)【get/post】------------>Servlet服务器------------------------------->浏览器显示
                               编码                 解码成unicode，然后将显示的内容编码        解码
(1) 浏览器把URL(以及post提交的内容)经过编码后发送给服务器。
(2) 这里的Servlet服务器实际上指的是由Servlet服务器提供的servlet实现ServletRequestWrapper，不同应用服务器的 servlet实现不同，这些servlet的实现把这些内容解码转换为unicode，处理完毕后，然后再把结果(即网页)编码返回给浏览器。
(3) 浏览器按照指定的编码显示该网页。

        当对字符串进行编码和解码的时候都涉及到字符集，通常使用的字符集为ISO8859-1、GBK、UTF-8、UNICODE。


2、URL的组成:
域名:端口/contextPath/servletPath/pathInfo?queryString
说明：

1、ContextPath是在Servlet服务器的配置文件中指定的。
对于weblogic：
contextPath是在应用的weblogic.xml中配置。
<context-root>/</context-root>

对于tomcat：
contextPath是在server.xml中配置。
<Context path="/" docBase="D:/server/blog.war" debug="5" reloadable="true" crossContext="true"/>

对于jboos：
contextPath是在应用的jboss-web.xml中配置。
<jboss-web>
    <context-root>/</context-root>
</jboss-web>

2、ServletPath是在应用的web.xml中配置。
<servlet-mapping>
    <servlet-name>Example</servlet-name>
    <url-pattern>/example/*</url-pattern>
</servlet-mapping>

2、Servlet API
我们使用以下servlet API获得URL的值及参数。
request.getParameter("name");         // 获得queryString的参数值(来自于get和post)，其值经过Servlet服务器URL Decode过的
request.getPathInfo();                // 注意：pathinfo返回的字符串是经过Servlet服务器URL Decode过的。
requestURI = request.getRequestURI(); // 内容为：contextPath/servletPath/pathinfo 浏览器提交过来的原始数据，未被Servlet服务器URL Decode过。


3、开发人员必须清楚的servlet规范：
(1) HttpServletRequest.setCharacterEncoding()方法 仅仅只适用于设置post提交的request body的编码而不是设置get方法提交的queryString的编码。该方法告诉应用服务器应该采用什么编码解析post传过来的内容。很多文章并没 有说明这一点。
(2) HttpServletRequest.getPathInfo()返回的结果是由Servlet服务器解码(decode)过的。
(3) HttpServletRequest.getRequestURI()返回的字符串没有被Servlet服务器decoded过。
(4) POST提交的数据是作为request body的一部分。
(5) 网页的Http头中ContentType("text/html; charset=GBK")的作用：
   (a) 告诉浏览器网页中数据是什么编码；
   (b) 表单提交时，通常浏览器会根据ContentType指定的charset对表单中的数据编码，然后发送给服务器的。
   这里需要注意的是：这里所说的ContentType是指http头的ContentType，而不是在网页中meta中的ContentType。


三、下面我们分别从浏览器和应用服务器来举例说明：
URL：http://localhost:8080/example/中国?name=中国
汉字   编码      二进制表示
中国   UTF-8     0xe4 0xb8 0xad 0xe5 0x9b 0xbd[-28, -72, -83, -27, -101, -67]
中国   GBK       0xd6 0xd0 0xb9 0xfa[-42, -48, -71, -6]
中国   ISO8859-1 0x3f,0x3f[63, 63]信息失去


(一)、浏览器
1、GET方式提交，浏览器会对URL进行URL encode，然后发送给服务器。
(1) 对于中文IE,如果在高级选项中选中总以UTF-8发送(默认方式)，则PathInfo是URL Encode是按照UTF-8编码,QueryString是按照GBK编码。
http://localhost:8080/example/中国?name=中国
实际上提交是：
GET /example/%E4%B8%AD%E5%9B%BD?name=%D6%D0%B9%FA

(1) 对于中文IE,如果在高级选项中取消总以UTF-8发送，则PathInfo和QueryString是URL encode按照GBK编码。
实际上提交是：
GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA

(3) 对于中文firefox，则pathInfo和queryString都是URL encode按照GBK编码。
实际上提交是：
GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA

很显然，不同的浏览器以及同一浏览器的不同设置，会影响最终URL中PathInfo的编码。对于中文的IE和FIREFOX都是采用GBK编码QueryString。

小结：解决方案：
1、URL中如果含有中文等非ASCII字符，则浏览器会对它们进行URLEncode。为了避免浏览器采用了我们不希望的编码，所以最好不要在URL中直接使用非ASCII字符，而采用URL Encode编码过的字符串%.
比如：
URL：http://localhost:8080/example/中国?name=中国
建议：
URL：http://localhost:8080/example/%D6%D0%B9%FA?name=%D6%D0%B9%FA

2、我们建议URL中PathInfo和QueryString采用相同的编码，这样对服务器端处理的时候会更加简单。

2、还有一个问题，我发现很多程序员并不明白URL Encode是需要指定字符集的。不明白的人可以看看这篇文档：http://gceclub.sun.com.cn/Java_Docs/html/zh_CN/api/java/net/URLEncoder.html

2、 POST提交
        对于POST方式，表单中的参数值对是通过request body发送给服务器，此时浏览器会根据网页的ContentType("text/html; charset=GBK")中指定的编码进行对表单中的数据进行编码，然后发给服务器。
在服务器端的程序中我们可以通过Request.setCharacterEncoding() 设置编码，然后通过request.getParameter获得正确的数据。

解决方案：
1、从最简单，所需代价最小来看，我们对URL以及网页中的编码使用统一的编码对我们来说是比较合适的。
如果不使用统一编码的话，我们就需要在程序中做一些编码转换的事情。这也是我们为什么看到有网络上大量的资料介绍如何对乱码进行处理，其中很多解决方案都只是一时的权宜之计，没有从根本上解决问题。


(二)、Servlet服务器
        Servlet服务器实现的Servlet遇到URL和POST提交的数据中含有%的字符串，它会按照指定的字符集解码。下面两个Servlet方法返回的结果都是经过解码的：
request.getParameter("name");
request.getPathInfo();

这里所说的"指定的字符集"是在应用服务器的配置文件中配置。

(1) tomcat服务器
对于tomcat服务器，该文件是server.xml
<Connector port="8080" protocol="HTTP/1.1"
               maxThreads="150" connectionTimeout="20000"
               redirectPort="8443" URIEncoding="GBK"/>
URIEncoding告诉服务器servlet解码URL时采用的编码。

<Connector port="8080" ... useBodyEncodingForURI="true" />
useBodyEncodingForURI告诉服务器解码URL时候需要采用request body指定的编码。

(2) weblogic服务器
对于weblogic服务器，该文件是weblogic.xml
<input-charset>
  <java-charset-name>GBK</java-charset-name>
</input-charset>

(三)浏览器显示
        浏览器根据http头中的ContentType("text/html; charset=GBK")，指定的字符集来解码服务器发送过来的字节流。我们可以调用 HttpServletResponse.setContentType()设置http头的ContentType。

总结：
1、URL中的PathInfo和QueryString字符串的编码和解码是由浏览器和应用服务器的配置决定的，我们的程序不能设置，不要期望用request.setCharacterEncoding()方法能设置URL中参数值解码时的字符集。
所以我们建议URL中不要使用中文等非ASCII字符，如果含有非ASCII字符的话要使用URLEncode编码一下，比如：
http://localhost:8080/example1/example/中国
正确的写法：
http://localhost:8080/example1/example/%E4%B8%AD%E5%9B%BD
并且我们建议URL中不要在PathInfo和QueryString同时使用非ASCII字符，比如
http://localhost:8080/example1/example/中国?name=中国
原因很简单：不同浏览器对URL中PathInfo和QueryString编码时采用的字符集不同，但应用服务器对URL通常会采用相同的字符集来解码。
2、我们建议URL中的URL Encode编码的字符集和网页的contentType的字符集采用相同的字符集，这样程序的实现就很简单，不用做复杂的编码转换。


        伟大的创想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服务器告诉浏览器自己响应的对象的语言。

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

字符(Character)是文字与符号的总称，包括文字、图形符号、数学符号等。
一组抽象字符的集合就是字符集(Charset)。
字符集常常和一种具体的语言文字对应起来，该文字中的所有字符或者大部分常用字符就构成了该文字的字符集，比如英文字符集。
一组有共同特征的字符也可以组成字符集，比如繁体汉字字符集、日文汉字字符集。
字符集的子集也是字符集。

计算机要处理各种字符，就需要将字符和二进制内码对应起来，这种对应关系就是字符编码(Encoding)。
制定编码首先要确定字符集，并将字符集内的字符排序，然后和二进制数字对应起来。根据字符集内字符的多少，会确定用几个字节来编码。
每种编码都限定了一个明确的字符集合，叫做被编码过的字符集(Coded Character Set)，这是字符集的另外一个含义。通常所说的字符集大多是这个含义。

二、有哪些字符集?

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 8859，全称ISO/IEC 8859，是国际标准化组织(ISO)及国际电工委员会(IEC)联合制定的一系列8位字符集的标准，现时定义了15个字符集。
ASCII收录了空格及94个“可印刷字符”，足以给英语使用。
但是，其他使用拉丁字母的语言(主要是欧洲国家的语言)，都有一定数量的变音字母，故可以使用ASCII及控制字符以外的区域来储存及表示。
除了使用拉丁字母的语言外，使用西里尔字母的东欧语言、希腊语、泰语、现代阿拉伯语、希伯来语等，都可以使用这个形式来储存及表示。
    * ISO 8859-1 (Latin-1) - 西欧语言
    * ISO 8859-2 (Latin-2) - 中欧语言
    * ISO 8859-3 (Latin-3) - 南欧语言。世界语也可用此字符集显示。
    * ISO 8859-4 (Latin-4) - 北欧语言
    * ISO 8859-5 (Cyrillic) - 斯拉夫语言
    * ISO 8859-6 (Arabic) - 阿拉伯语
    * ISO 8859-7 (Greek) - 希腊语
    * ISO 8859-8 (Hebrew) - 希伯来语(视觉顺序)
    * ISO 8859-8-I - 希伯来语(逻辑顺序)
    * ISO 8859-9 (Latin-5 或 Turkish) - 它把Latin-1的冰岛语字母换走，加入土耳其语字母。
    * ISO 8859-10 (Latin-6 或 Nordic) - 北日耳曼语支，用来代替Latin-4。
    * ISO 8859-11 (Thai) - 泰语，从泰国的 TIS620 标准字集演化而来。
    * ISO 8859-13 (Latin-7 或 Baltic Rim) - 波罗的语族
    * ISO 8859-14 (Latin-8 或 Celtic) - 凯尔特语族
    * ISO 8859-15 (Latin-9) - 西欧语言，加入Latin-1欠缺的法语及芬兰语重音字母，以及欧元符号。
    * ISO 8859-16 (Latin-10) - 东南欧语言。主要供罗马尼亚语使用，并加入欧元符号。
很明显，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(统一码、万国码、单一码)是一种在计算机上使用的字符编码。
它是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来标记文本文件的编码方式的。

三、编程语言与编码

C、C++、Python2内部字符串都是使用当前系统默认编码
Python3、Java内部字符串用Unicode保存
Ruby有一个内部变量$KCODE用来表示可识别的多字节字符串的编码，变量值为EUC SJIS UTF8 NONE之一。
$KCODE的值为EUC时，将假定字符串或正则表达式的编码为EUC-JP。
同样地，若为SJIS时则认定为Shift JIS。若为UTF8时则认定为UTF-8。
若为NONE时，将不会识别多字节字符串。
在向该变量赋值时，只有第1个字节起作用，且不区分大小写字母。
e E 代表 EUC，s S 代表 SJIS，u U 代表 UTF8，而n N 则代表 NONE。
默认值为NONE。
即默认情况下Ruby把字符串当成单字节序列来处理。

四、为什么会乱码?

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

五、有没有万金油?

在如此多种编码和字符集弄的我们眼花缭乱的情况下，我们只需选择一种兼容性最好的编码方式和字符集，让它成为我们程序子系统之间
交互的编码契约，那么从此恼人的乱码问题即将远离我们而去 -- 这种兼容性最好的编码就是UTF-8!
毕竟GBK/GB2312是国内的标准，当我们大量使用国外的开源软件时，UTF-8才是编码界最通用的语言。