【转】编码详解（下）
第二部分：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编译过程中的编码
第一阶段是将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 浏览器端解析字节流的编码
<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″>
是指客户端浏览器以什么样的编码来显示网页。网页本质是从服务器端输出的字节流。同时它还有一个重要的作用，规定了使用post方式提交表单的时候使用什么编码传入参数。虽然服务器端request获取post请求参数的代码和获取get请求参数的代码完全一样。
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”也是可以的。
转载自：Struts教程网（网易旗下） » 编码详解（下）
