编码详解

来源：互联网发布：vb 截图部分图像编辑：程序博客网时间：2024/06/04 18:29

第一部分：编码的种类
编码规范用于规定可见字符和控制字符的二进制表示形式，它分为多种类型：下面详细说说编码的方式：

1.1 ANSI编码

这种编码方式规定了英文占用了一个字节，中文占用两个字节（这个是我们通常所说的编码方式）。因为汉字分为多个类型：有简体中文，有繁体中文，还有日语中的汉字。所以ANSI编码又分为：GB2312（简体中文），BIG5（繁体中文），JIS（日文）等各自的编码标准。

1.2 ASCII编码

这是美国上世纪60年代制定的。ASCII码一共规定了128个字符的编码，这128个符号（包括32个不能打印出来的控制符号），只占用了一个字节的后面7位，最前面的1位统一规定为0，编码范围为0×00-0x7F。

1.3 ISO-8859-1编码

英语用128个符号编码就够了，但是用来表示其他语言，128个符号是不够的。比如，在法语中字母上方有注音符号，它就无法用ASCII码表示。于是，一些欧洲国家就决定，利用字节中闲置的最高位编入新的符号。在这种情况下ISO-8859-1编码诞生了。ISO-8859-1编码是单字节编码，向下兼容ASCII，其编码范围是0×00-0xFF，0×00-0x7F之间完全和ASCII一致，0×80-0x9F之间是控制字符，0xA0-0xFF之间是文字符号。ISO-8859-1收录的字符除ASCII收录的字符外，还包括西欧语言、希腊语、泰语、阿拉伯语、希伯来语对应的文字符号。因为ISO-8859-1编码范围使用了单字节内的所有空间，在支持ISO-8859-1的系统中传输和存储其他任何编码的字节流都不会被抛弃。换言之，把其他任何编码的字节流当作ISO-8859-1编码看待都没有问题。最常见的场景为：在java 服务器端接受get方法的请求中，如果参数中含有中文，则可以将参数转换为字节数组，然后将字节数组解码成字符串。
String rawName = request.getParameter(“name”);
byte[] rawBytes = rawName.getBytes(“ISO-8859-1″);//分解为字节数组
String name = new String(rawBytes,”gb2312″);

1.4 Unicode编码

Unicode是一个很大的集合，现在的规模可以容纳100多万个符号。它将世界上所有的符号都纳入其中。每一个符号都给予一个独一无二的编码。需要注意的是，Unicode只是一个符号集，它只规定了符号的二进制代码，却没有规定这个二进制代码应该如何存储。这样就造成了一种混乱的现象，存在多种Unicode的存储方式，例如UTF-8，UTF-16和UTF-32。话又说回来，如果Unicode统一规定，每个符号用两个或三个字节表示，那么会出现什么情况呢？例如，汉字”严”的Unicode是十六进制数4E25，转换成二进制数足足有15位（100111000100101），也就是说这个符号的表示至少需要2个字节。而英文字母只用一个字节表示就够了，如果Unicode统一规定，每个符号用三个或四个字节表示，那么每个英文字母前都必然有二到三个字节是0，这对于存储来说是极大的浪费，文本文件的大小会因此大出二三倍，这是无法接受的。

1.5 UTF-8编码

互联网的普及，强烈要求出现一种统一的编码方式。UTF-8就是在互联网上使用最广的一种Unicode的实现方式。UTF-8最大的一个特点，就是它是一种变长的编码方式。它可以使用1~4个字节表示一个符号，根据不同的符号而变化字节长度。
UTF-8的编码规则很简单，只有二条：
1）对于单字节的符号，字节的第一位设为0，后面7位为这个符号的Unicode码。因此对于英语字母，UTF-8编码和ASCII码是相同的。
2）对于n字节的符号（n>1），第一个字节的前n位都设为1，第n+1位设为0，后面字节的前两位一律设为10。剩下的没有提及的二进制位，全部为这个符号的Unicode码。
下表总结了编码规则，字母x表示可用编码的位。

Unicode符号范围(十六进制)UTF-8编码方式（二进制）0000 0000–0000 007F 0xxxxxxx0000 0080–0000 07FF110xxxxx 10xxxxxx0000 0800–0000 FFFF1110xxxx 10xxxxxx 10xxxxxx0001 0000–0010 FFFF11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

跟据上表，解读UTF-8编码非常简单。如果一个字节的第一位是0，则这个字节单独就是一个字符；如果第一位是1，则连续有多少个1，就表示当前字符占用多少个字节。
下面，还是以汉字”严”为例，演示如何实现UTF-8编码。
已知”严”的Unicode是4E25（100111000100101），根据上表，可以发现4E25处在第三行的范围内（0000 0800-0000 FFFF），因此”严”的UTF-8编码需要三个字节，即格式是”1110xxxx 10xxxxxx 10xxxxxx”。然后，从”严”的最后一个二进制位开始，依次从后向前填入格式中的x，多出的位补0。这样就得到了，”严”的UTF-8编码是”11100100 10111000 10100101″，转换成十六进制就是E4B8A5。

1.6 关于记事本的编码

在Windows平台下内置的记事本小程序Notepad.exe有四种编码类型。打开任意一个文件后，点击”文件”菜单中的”另存为”命令，会跳出一个对话框，在最底部有一个”编码”的下拉条。
txt
里面有四个选项：ANSI，Unicode，Unicode big endian 和 UTF-8。
1）ANSI是默认的编码方式。对于英文文件是ASCII编码，对于简体中文文件是GB2312编码（只针对Windows简体中文版，如果是繁体中文版会采用Big5码）。
2）Unicode编码指的是UCS-2编码方式，即直接用两个字节存入字符的Unicode码。这个选项用的little endian格式。
3）Unicode big endian编码与上一个选项相对应。
4）UTF-8编码，也就是上一节谈到的编码方法。
注意：Unicode码可以采用UCS-2格式直接存储。以汉字”严”为例，Unicode码是4E25，需要用两个字节存储，一个字节是4E，另一个字节是25。存储的时候，4E在前，25在后，就是Big endian方式；25在前，4E在后，就是Little endian方式。这两个古怪的名称来自英国作家斯威夫特的《格列佛游记》。在该书中，小人国里爆发了内战，战争起因是人们争论，吃鸡蛋时究竟是从大头(Big- Endian)敲开还是从小头(Little-Endian)敲开。为了这件事情，前后爆发了六次战争，一个皇帝送了命，另一个皇帝丢了王位。因此，第一个字节在前，就是”大头方式”（Big endian），第二个字节在前就是”小头方式”（Little endian）。那么很自然的，就会出现一个问题：计算机怎么知道某一个文件到底采用哪一种方式编码？Unicode规范中定义，每一个文件的最前面分别加入一个表示编码顺序的字符，这个字符的名字叫做”零宽度非换行空格”（ZERO WIDTH NO-BREAK SPACE），用FEFF表示。这正好是两个字节，而且FF比FE大1。如果一个文本文件的头两个字节是FE FF，就表示该文件采用大头方式；如果头两个字节是FF FE，就表示该文件采用小头方式。

1.7 不同编辑环境下文件的编码不同

不同的编辑环境下，文件的编码方式是不一样的。例如：
（1）在eclipse环境中新建一个jsp文件，只要文件的开头标示文件的编码形式：<%@ page language=”java” pageEncoding=”"%>，则eclipse会自动保存文件为对应的格式。
（2）在windows下使用记事本新建一个jsp文件，无论文件的开头标示什么编码格式，但是文件的保存都是ANSI格式的。
（3）从eclipse中utf-8格式的jsp文件中拷贝一段内容，复制到windows环境下的记事本中，此时文件的格式会从utf-8转变为ANSI格式。

第二部分：JSP相关编码设置

2.1 JSP页面本身的编码形式

<%@ page language=”java” import=”java.util.*” pageEncoding=”utf-8″%>
pageEncoding 指的是jsp文件本身在本地保存时的编码方式。注意：在eclipse环境下会根据pageEncoding保存的。

2.2 服务器端发送字节流的编码

<%@ page contentType=”text/html;charset=UTF-8″ %>
是服务器端java程序运行时的输出字节流的编码方式，即服务器端向客户端输出HTML代码时采用的编码。

2.3 服务器端JSP编译过程中的编码

encode

第一阶段是将jsp编译成.java，它会根据pageEncoding的设定读取jsp，然后编译成utf-8格式的java源码（.java文件）。如果pageEncoding设定错了或没有设定，编译出的java源文件就会出现不正确的字符。
第二阶段是由javac用utf-8的编码方式读取java源码，然后编译成二进制码（.class文件）这个二进制文件也是uft-8格式的。
第三阶段是Tomcat（或其的服务器容器）载入和执行第二阶段编译的二进制文件，输出的字节流是根据<%@ page contentType=”text/html;charset=UTF-8″ %> 编码方式制定的。

2.4 浏览器端解析字节流的编码

2.5 GET方式的编码（浏览器端编码）

get方式提交参数的编码比较复杂，有以下几种情况：
(1) 对于中文IE，如果在高级选项中选中总以utf-8发送(默认方式)，则PathInfo是按照utf-8编码，QueryString是按照GBK编码。

http://localhost:8080/example/中国?name=中国

实际上提交是：
GET /example/%E4%B8%AD%E5%9B%BD?name=%D6%D0%B9%FA
(2) 对于中文IE，如果在高级选项中取消总以utf-8发送，则PathInfo和QueryString是按照GBK编码。
实际上提交是：GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
(3) 对于中文firefox，则pathInfo和queryString都是按照GBK编码。
实际上提交是：GET /example/%D6%D0%B9%FA?name=%D6%D0%B9%FA
很显然，不同的浏览器以及同一浏览器的不同设置，会影响最终URL中PathInfo的编码。对于中文的IE和firefox都是采用GBK编码QueryString。

2.6 GET方式的编码（服务器端的解码）

http://localhost:8080/example/record.html?name=张三

在服务器端获取参数的形式为：request.getParameter(“name”); name的值是经过Servlet服务器URL Decode（解码）过的。需要注意的是解码的方式是在应用服务器的配置文件中的。
而在Resin容器的内部，所有的字符都是按照iso-8859-1来处理的。
URL中的PathInfo和QueryString字符串的编码和解码是由浏览器和应用服务器的配置决定的，我们的程序不能设置，不要期望用request.setCharacterEncoding()方法能设置URL中参数值解码时的字符集。这一点是与post方式是有区别的。

2.7 POST方式的编码

对于post方式，表单中的参数值对是通过请求体发送给服务器，此时浏览器会根据网页的content=”text/html; charset=utf-8″中指定的编码进行对表单中的数据进行编码，然后发给服务器。在服务器端的程序中我们可以通过Request.setCharacterEncoding()设置编码，然后通过request.getParameter获得正确的数据。

2.8 URL编码（百分号编码）

对于URL来说，之所以要进行编码，是因为URL中有些字符会引起歧义。例如URL参数字符串使用key=value键值对这样的形式来传参，键值对之间以&符号分隔，如/s?q=abc& ie=utf-8。如果你的value字符串中包含了=或者&，那么势必会造成接收URL的服务器解析错误，因此必须将引起歧义的&和=符号进行转义，也就是对其进行编码。
又如，URL的编码格式采用的是ASCII码，而不是Unicode，这也就是说你不能在URL中包含任何非ASCII字符，例如中文，否则如果客户端浏览器和服务端浏览器支持的字符集不同的情况下，中文可能会造成问题。URL编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符。
不需要编码的字符包括：
URL中只允许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及所有保留字符。
需要编码的情况：
（1）普通数据中包括保留数据：
URL可以划分成若干个组件，协议、主机、路径等。有一些字符（:/?#[]@）是用作分隔不同组件的。例如:冒号用于分隔协议和主机，/用于分隔主机和路径，?用于分隔路径和查询参数等。还有一些字符（!$&’()*+,;=）用于在每个组件中起到分隔作用的，如=用于表示查询参数中的键值对，&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时，需要对其进行编码。RFC3986中指定了以下字符为保留字符：

!*‘();:@&=+$,/?#[]

（2）不安全字符
还有一些字符，当他们直接放在URL中的时候，可能会引起解析程序的歧义。这些字符被视为不安全字符，原因有很多。

空格URL在传输的过程，或者用户在排版的过程，或者文本处理程序在处理URL的过程，都有可能引入无关紧要的空格，或者将那些有意义的空格给去掉引号以及<>引号和尖括号通常用于在普通文本中起到分隔URL的作用#通常用于表示书签或者锚点%百分号本身用作对不安全字符进行编码时使用的特殊字符，因此本身需要编码{}|\^[]`~某一些网关或者传输代理会篡改这些字符

需要注意的是，对于URL中的合法字符，编码和不编码是等价的，但是对于上面提到的这些字符，如果不经过编码，那么它们有可能会造成URL语义的不同。因此对于URL而言，只有普通英文字符和数字，特殊字符$-_.+!*’()还有保留符，才能出现在未经编码的URL之中。其他字符均需要经过编码之后才能出现在URL中。
如何对URL中的非法字符进行编码

URL编码通常也被称为百分号编码（URL Encoding，also known as percent-encoding），是因为它的编码方式非常简单，使用%百分号加上两位的字符【0123456789ABCDEF】代表一个字节的十六进制形式。URL编码默认使用的字符集是US-ASCII。例如a在US-ASCII码中对应的字节是0×61，那么URL编码之后得到的就是%61，我们在地址栏上输入http://g.cn/search?q=%61%62%63，实际上就等同于在google上搜索abc了。又如@符号在ASCII字符集中对应的字节为0×40，经过URL编码之后得到的是%40。

常见字符的URL编码列表：

保留字符的URL编码

!*“‘();:@&%21%2A%22%27%28%29%3B%3A%40%26=+$,/?%#[]%3D%2B%24%2C%2F%3F%25%23%5B%5D

对于非ASCII字符，需要使用ASCII字符集的超集进行编码得到相应的字节，然后对每个字节执行百分号编码。对于Unicode字符，RFC文档建议使用utf-8对其进行编码得到相应的字节，然后对每个字节执行百分号编码。如“中文”使用UTF-8字符集得到的字节为0xE4 0xB8 0xAD 0xE6 0×96 0×87，经过URL编码之后得到“%E4%B8%AD%E6%96%87”。

如果某个字节对应着ASCII字符集中的某个非保留字符，则此字节无需使用百分号表示。例如“URL编码”，使用UTF-8编码得到的字节是0×55 0×72 0x6C 0xE7 0xBC 0×96 0xE7 0xA0 0×81，由于前三个字节对应着ASCII中的非保留字符“URL”，因此这三个字节可以用非保留字符“URL”表示。最终的URL编码可以简化成 “URL%E7%BC%96%E7%A0%81” ，当然，如果你用”%55%72%6C%E7%BC%96%E7%A0%81”也是可以的。

转载链接：http://www.strutshome.com/index.php/archives/106

http://www.strutshome.com/index.php/archives/169

0 0