對于URL轉(zhuǎn)碼問題的理解：
URL轉(zhuǎn)碼分為編碼和解碼兩個(gè)過程卿堂。
URL編碼的理解：
首先：我們需要想想U(xiǎn)RL作為一個(gè)請求盹愚，需要描述那幾個(gè)部分：
服務(wù)器的地址
資源地址
-
請求的參數(shù)
這個(gè)和到某地找東西是非常類似的收壕。舉例：
假設(shè)在遠(yuǎn)端的服務(wù)器的ip地址為123.231.45.3.端口號為8080.然后在文件/red+/blue/下有N個(gè)文件扔水， 你想查詢符合某個(gè)條件q的
那么URL 就應(yīng)該像下面這樣：
http://123.231.45.3:8080/red+/blue/?q=query
格式為：協(xié)議+ip地址+端口號+文件+ 查詢條件
至于為什么是這種格式蛉加，這個(gè)是由之前的專家協(xié)商的惜颇， 這樣大家在開發(fā)程序就有了一個(gè)統(tǒng)一的約定抬闷。
(具體的例子可以看看參考文獻(xiàn)中的一個(gè)表格)
其次妇蛀，我們看看URL中用于分割各個(gè)部分的分割符。
Scheme://host address:port/file;path parameters?queur paprameter
其中/后面是path
笤成；后面是路徑參數(shù)
评架？ 后面是查詢條件
有了上面的約定 ，在服務(wù)器端收到URL之后炕泳，根據(jù)相應(yīng)的特殊字符進(jìn)行分割就可以得到Path路徑古程，Path參數(shù)， 和查詢條件喊崖，正確解析之后就可以進(jìn)行取數(shù)據(jù)返回用戶了挣磨。
下面我們來考慮這樣一個(gè)情況：假設(shè)一個(gè)圖片的名字to_be_or_not_to_be?.jpg時(shí)，對其進(jìn)行請求荤懂，會(huì)出現(xiàn)什么情況茁裙。
上面在路徑部分出現(xiàn)了？所以服務(wù)器就會(huì)解析錯(cuò)誤节仿，因?yàn)榍懊嫖覀冋f過服務(wù)器是按照“晤锥？”對URL劃分出查詢部分的。
第三：如何解決上面的問題呢？這就需要對在Path中（也就是to_be_or_not_to_be?.jpg）的矾瘾？符號進(jìn)行編碼轉(zhuǎn)化女轿，將路徑部分的？編碼為其他的字符壕翩。
（編碼）轉(zhuǎn)化規(guī)則如下：（可以當(dāng)做一個(gè)黑盒子）
（注：一般使用utf-8編碼方式）
將特殊字符利用某編碼方式進(jìn)行編碼蛉迹，之后在前面加上%。
轉(zhuǎn)化之后如下：to_be_or_not_to_be%3F.jpg
這樣當(dāng)轉(zhuǎn)碼之后的URL發(fā)送到服務(wù)器段時(shí)放妈，就不會(huì)出現(xiàn)解析上的歧義了北救。
URL解碼
URL解碼就是URL編碼相反的過程，將編碼后的URL解碼顯示在瀏覽器的地址欄內(nèi)芜抒，給用戶看珍策。
上面是最簡單的例子解釋URL轉(zhuǎn)碼存在的理由，至于其他的更深一步的理解可以參考下面的參考文獻(xiàn)宅倒。不過一般不做開發(fā)攘宙，可以忽略，拐迁。
參考文獻(xiàn)：
英文版：https://www.talisman.org/~erlkonig/misc/lunatech%5Ewhat-every-webdev-must-know-about-url-encoding/
