[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]