對(duì)于URL轉(zhuǎn)碼問(wèn)題的理解：
URL轉(zhuǎn)碼分為編碼和解碼兩個(gè)過(guò)程。
URL編碼的理解：
首先：我們需要想想U(xiǎn)RL作為一個(gè)請(qǐng)求，需要描述那幾個(gè)部分：
服務(wù)器的地址
資源地址
-
請(qǐng)求的參數(shù)
這個(gè)和到某地找東西是非常類(lèi)似的。舉例：
假設(shè)在遠(yuǎn)端的服務(wù)器的ip地址為123.231.45.3.端口號(hào)為8080.然后在文件/red+/blue/下有N個(gè)文件， 你想查詢(xún)符合某個(gè)條件q的
那么URL 就應(yīng)該像下面這樣：
http://123.231.45.3:8080/red+/blue/?q=query
格式為：協(xié)議+ip地址+端口號(hào)+文件+ 查詢(xún)條件
至于為什么是這種格式，這個(gè)是由之前的專(zhuān)家協(xié)商的， 這樣大家在開(kāi)發(fā)程序就有了一個(gè)統(tǒng)一的約定。
(具體的例子可以看看參考文獻(xiàn)中的一個(gè)表格)
其次，我們看看URL中用于分割各個(gè)部分的分割符。
Scheme://host address:port/file;path parameters?queur paprameter
其中/后面是path
；后面是路徑參數(shù)
？ 后面是查詢(xún)條件
有了上面的約定 ，在服務(wù)器端收到URL之后，根據(jù)相應(yīng)的特殊字符進(jìn)行分割就可以得到Path路徑，Path參數(shù)， 和查詢(xún)條件，正確解析之后就可以進(jìn)行取數(shù)據(jù)返回用戶(hù)了。
下面我們來(lái)考慮這樣一個(gè)情況：假設(shè)一個(gè)圖片的名字to_be_or_not_to_be?.jpg時(shí)，對(duì)其進(jìn)行請(qǐng)求，會(huì)出現(xiàn)什么情況。
上面在路徑部分出現(xiàn)了？所以服務(wù)器就會(huì)解析錯(cuò)誤，因?yàn)榍懊嫖覀冋f(shuō)過(guò)服務(wù)器是按照“？”對(duì)URL劃分出查詢(xún)部分的。
第三：如何解決上面的問(wèn)題呢？這就需要對(duì)在Path中（也就是to_be_or_not_to_be?.jpg）的？符號(hào)進(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編碼相反的過(guò)程，將編碼后的URL解碼顯示在瀏覽器的地址欄內(nèi)，給用戶(hù)看。
上面是最簡(jiǎn)單的例子解釋URL轉(zhuǎn)碼存在的理由，至于其他的更深一步的理解可以參考下面的參考文獻(xiàn)。不過(guò)一般不做開(kāi)發(fā)，可以忽略，。
參考文獻(xiàn)：
英文版：https://www.talisman.org/~erlkonig/misc/lunatech%5Ewhat-every-webdev-must-know-about-url-encoding/
