首先了解以下中文字符在使用urlencode的時候運用的基本原理：
urlencode()函數原理就是首先把中文字符轉換為十六進制，然后在每個字符前面加一個標識符%。
此字符串中除了 -_. 之外的所有非字母數字字符都將被替換成百分號（%）后跟兩位十六進制數，空格則編碼為加號（+）。
在做通過關鍵詞查詢條目的需求時，發現前端IOS傳過來的“中文關鍵字”是通過url編碼的字串，直接使用，我們是是用不了的，拿php為例，我們需要對該值使用urldecode()函數進行解碼，解碼后就會是對應的中文了。當時覺得很納悶，為什么前端要對參數編碼后傳給后台，心里的答案時為了安全起見，防止別人截取url后對其中的參數進行解析。但是，總感覺好模棱兩可，既然我后台可以解碼出正確值，為什么截取了你url的人不可以呢，如此哪來的安全可言。
於是，我就問了問之前工作的ios的同事，結果，他斬釘截鐵的告訴我，就是為了安全，我差點就以為就真的是這樣了，不過還好我內心的強烈不同意與好奇心，在網上查了又查，於是，下面就是我得出的結論：
以iOS編程為例，每當我們從服務器獲得到一個鏈接需要分析鏈接的組成，或者在捕捉本地網路請求作出響應判斷的時候，我們經常需要對URL進行解碼和編碼。那么為什么要進行解碼和編碼呢。
比如有一個需求，你需要截取webveiw請求來實現一些操作。那么此時我們就需要從請求到的url中獲取一些參數。
url：www.baidu.com?canshu1=zhi1&canshu2=zhi2
我們從url中獲取參數值的方法是從=后獲取值，針對這個鏈接，我們從鏈接中獲取參數。有兩種情況
1.參數有兩個canshi1，canshu2，值分別是zhi1和zhi2
2.參數只有一個canshu1， 值為zhi1&canshu2=zhi2
顯然造成了歧義。
為了避免歧義，我們需要就必須要講值中的“=”或者“&”等特殊符號用其他符號代替，防止對=后面取值的方式造成影響，這個代替過程就是編碼。
以情況2為例子，此處有一個參數canshu1,其值是“zhi1&canshu2=zhi2”，進行URL的utf8編碼后得到zhi1%26canshu2%3Dzhi2，將編碼后的值放入鏈接
www.baidu.com?canshu1=zhi1%26canshu2%3Dzhi2
於是拿到編碼后鏈接的人解析，就直接取=后面的值作為canshu1的值，得到值為zhi1%26canshu2%3Dzhi2，然后對“zhi1%26canshu2%3Dzhi2”進行解碼（需要用和編碼同樣的方式，一般有UTF8和gb2312）得到值“zhi1&canshu2=zhi2”，完全正確。
注意:如果值中有%26則也會被轉化成%2626也不會造成歧義。
1、為什么要編碼
網絡標准RFC 1738規定url中只能包含英文字母和阿拉伯數字，以及一些特殊字符：
"...Only alphanumerics [0-9a-zA-Z], the special characters "$-_.+!*'()," [not including the quotes - ed], and reserved characters used for their reserved purposes may be used unencoded within a URL."“只有字母和數字[0-9a-zA-Z]、和特殊符號”$-_.+!*’(),”[不包括雙引號]、及某些保留字，才可以不經過編碼直接用於URL。”
此時如果url中包含如漢字或者其他特殊字符則需要對它進行編碼，編碼的意義在於，假如url的參數中的中文或特殊字符在發送到服務端時，服務端無法解析它的真正意義，會導致服務端不能理解客戶端的請求。
如：
url中的保留字?表示后面連接的是一些請求參數，而參數中如果也包含?，服務端就不知道從哪個?之后是參數；
url中的保留字&用來連接並列的參數項，參數中包含&時，服務端依然無法判斷。
2、轉碼范圍
-
ASCII 的控制字符
這些字符都是不可打印的，自然需要進行轉化。
-
一些非ASCII字符
這些字符自然是非法的字符范圍。轉化也是理所當然的了。
-
一些保留字符
很明顯最常見的就是“&”了，這個如果出現在url中了，那你認為是url中的一個字符呢，還是特殊的參數分割用的呢？
-
就是一些不安全的字符了。
例如：空格。為了防止引起歧義，需要被轉化為“+”。
轉自：http://blog.csdn.net/andanlan/article/details/53368727