URL编码，表单编码

[size=large][b]URL编码:[/b][/size]

[size=medium]可以理解为对一个字符串进行编码，在表单编码中也用到这个算法。

用途:
一个URL可以包含任何字符，URL编码可以把这个URL编码成只用ASCII码就可以表示的形式。编码后的URL在任何机器上都可以正常显示。

例如：你在浏览器地址栏输入一个URL，浏览器会首先对这个URL进行URL编码，然后再发送给web服务器。比如输入了“中”字，浏览器会编码成%E4%B8%AD发送给服务器。

浏览器编码的字符集是由用户进行配置的，在 IE选项 - 高级 - 国际 栏中，有个“发送UTF-8 URL”的checkbox，如果选中，URL将以UTF-8的编码发送给客户端，否则，会使用本机的缺省编码（在我的机器上是GBK）对URL进行编码。

[b]编码算法：[/b]
输入一个字符串和编码字符集，输出编码后的字符串。
主要处理过程：
1 String变成流
- 普通字符直接保留给输出 （大小写字母，数字，[-_.*]）
- 如果是空格，转换成+
- 其它字符保留到下一步处理

2 未处理的字符把流按输入的编码字符集获取流
按字节首先加%， 再转换成16进制的形式，16进制中的字母需用大写字母。

算法非常简单，说明如下：
1 你可以把字符分成保留和不保留两部分，例如A是保留字符，直接放到输出字符串中。非保留字符处理成%XX的形式，即先转换成字节码，每个字节再转换成XX的形式，前面加上%。
2 空格转换成+号，+号会转换成%2B (此处比较诡异，后面还会提到)

很多地方可以找到URL编码的源码:[/size]

// URL编码源码位置
jdk: 工具类java.net.URLEncoder类encode方法

apache: org.apache.commons.codec.net.URLCodec类encodeUrl方法

[size=large][b]表单编码:[/b][/size]
[size=medium]表单编码的目的是把form中的数据编码后发给服务器。
表单有两种类型: application/x-www-form-urlencoded, multipart/form-data，前一种是form的默认类型；后一种主要用来传输二进制数据，比如我们使用form上传文件，就要使用multipart/form-data类型。

application/x-www-form-urlencoded表单编码：
这种情况form中含有很多键值对，编码规则是对键，值分别使用URL编码，然后用=号和&连接起来。
例如: name1, value1, name2, value2编码后就成了 name1=value1&name2=value2
如果这是form的方法是get，编码后的表单就通过查询字符串发送给服务器，如果form的方法是post，表单通过http请求的正文发送。

源码:
[/size]

// 表单编码源码位置
org.apache.commons.httpclient.util.EncodingUtil类doFormUrlEncode方法。

[size=large][b]没有解决的问题:[/b]
1 通过tomcat测试，在web.xml文件中可以配置中文URL，在我的机器上，URL被tomcat用UTF-8进行编码，这个可以进行配置吗? 如果可以配置，能配置支持两种编码吗? 举个例子，我有一个含有中文的URL，我想让使用UTF-8编码和GBK编码发送URL的用户都能通过中文链接访问这个网址，如果不能直接配置，实现这个功能就会很麻烦。

2 服务器如何知道客户端发送的URL的编码? 开始的猜测服务器可以根据用户请求头里的Accept-Charset进行判断，但是客户端可能从其他地方获取了一个不在自己Accept-Charset内的编码，服务器如何处理？

3 浏览器和服务器对"空格"和"+"号的处理很让人疑惑。
浏览器端：经过试验，浏览器对空格处理成%20，对+号不做处理。
服务器端：如果在web.xml配置了一个含有"+"号的路径，那么服务器端对提交的+号和%2B都能找到这个路径。

这是一个让人迷惑的结果，但想想也有一定道理，从浏览器的角度，按照URL编码规则，把空格编码成+号，把+号编码成%2B很容易，但从服务器来看，就不太好处理，如果收到一个含有+号的URL，到底把这个URL看成编码前的还是编码后的呢? 个人感觉在这点上URL编码是有缺陷的，所以几款浏览器把URL中的空格编码成了%20，但是为什么不一鼓作气把+也编码成%2B? 这样服务器不就彻底解脱了。脑子里还是有点乱，先留个脚印，找时间再研究。[/size]