http://bigdragon.iteye.com/blog/1626847
URI encode的过程就是把部分的url做为字符，按照某种编码方式（如：utf-8,gbk等，各浏览器不同）编码成二进制的字节码，然后每个字节用一个 包含3个字符的字符串 “%xy” 表示，其中xy为该字节的两位十六进制表示形式。另外也会将空格替换成”+”。
各浏览器的编码不同”且用户可以自己设置默认编码，这导致了很多不同可能。这也就是为什么IE可以firefox乱码，这个机器可以另一台机器乱码的根源。你无法确定不同的浏览器是使用了什么编码对URI中的非ASCII字符进行编码(ascII可读字符不编码)的，所以你无法在服务器是确定自己使用什么解码。更要命的是不同的服务器也有自己默认的解码。例如Tomcat的解码格式为ISO-8859-1（可以修改server.xml修改）
首先浏览器只会对非ASCII字符进行编码，所以在经过两次或一次encodeURI编码之后，浏览器的编码不会起作用。那为什么要进行两次编码呢？
因为不确定服务器端是使用何种编码进行URI的解码。当然如果你很确信你使用的平台是固定的那就不需要了。如果想要代码跨平台则需要考虑。光这么将不够直接，看下的过程(假设服务器为Tomcat)：
“中文” ==encodeURI==> ”%E4%B8%AD%E6%96%87″ ==encodeURI（%被编码）==> ”%25E4%25B8%25AD%25E6%2596%2587″ ==Tomcat解码（ISO-8859-1）==> ”%E4%B8%AD%E6%96%87″ ==Java decode(UTF-8)==> ”中文”
可以看到进行了两次utf-8编码，一次ISO-8859-1解码，一次utf-8解码。因为ISO-8859-1与utf-8都包含了ASCII字符集（%属于其中之一），所以不会出现乱码。
http://blog.chinaunix.net/uid-24148050-id-344309.html
当用户通过表单（FORM）提交信息时，浏览器会首先会按照一定规则对这些信息进行编码。
这些编码规则主要包含以下几点：
使用“=”分割表单中元素的名称及其值；
使用“+”代替表单信息中的空格；
使用“ &”分割表单中的不同元素