提到SQL注入的繞過，編碼是其中最普通的一種方法，最常用的URL編碼。之前一直有個疑問，編碼與未編碼到底有哪些地方存在區別？
以下是本人自己對URL編碼的一些見解，可能有錯誤的地方歡迎大佬們指正。
什么是URL編碼。
“URL編碼是一種瀏覽器用來打包表單輸入的格式，瀏覽器從表單中獲取所有的name和其對應的value，將他們以name/value編碼方式作為URL的一部分或者分離的發送到服務器上。”
如何進行URL編碼。
“每對name/value由&分開，每對來自表單的name/value用=分開。如果用戶沒有輸入值的那個name依舊會出現不過就是沒有值。
URL編碼是在字符ASCII碼的十六進制數的前面加上%。例如\（十六進制數表示為5c）的URL編碼就是%5c。”
為什么要用URL編碼。
RFC3986文檔規定，Url中只允許包含英文字母（a-zA-Z）、數字（0-9）、-_.~4個特殊字符以及所有保留字符。
US-ASCII碼中的10-7F字節全都表示控制字符，這些字符都不能直接出現在Url中。同時，對於80-FF字節（ISO-8859-1），由於已經超出了US-ACII定義的字節范圍，因此也不可以放在Url中。
Url可以划分成若干個組件，協議、主機、路徑等。有一些字符（:/?#[]@）是用作分隔不同組件的。例如：冒號用於分隔協議和主機，/用於分隔主機和路徑，?用於分隔路徑和查詢參數，等等。還有一些字符（!$&'()*+,;=）用於在每個組件中起到分隔作用的，如=用於表示查詢參數中的鍵值對，&符號用於分隔查詢多個鍵值對。當組件中的普通數據包含這些特殊字符時，需要對其進行編碼。
RFC3986中指定了以下字符為保留字符：! * ' ( ) ; : @ & = + $ , / ? # [ ]
不安全字符：還有一些字符，當他們直接放在Url中的時候，可能會引起解析程序的歧義。這些字符被視為不安全字符，原因有很多。
- 空格：Url在傳輸的過程，或者用戶在排版的過程，或者文本處理程序在處理Url的過程，都有可能引入無關緊要的空格，或者將那些有意義的空格給去掉。
- 引號以及<>：引號和尖括號通常用於在普通文本中起到分隔Url的作用
- #：通常用於表示書簽或者錨點
- %：百分號本身用作對不安全字符進行編碼時使用的特殊字符，因此本身需要編碼
- {}|\^[]`~：某一些網關或者傳輸代理會篡改這些字符
因此URL編碼就是使用安全的字符（沒有特殊用途或者特殊意義的可打印字符）去表示那些不安全的字符。
編碼與非編碼的區別。
對於URL中的合法字符，編碼與非編碼是沒有區別的。但是對於上面提到的這些字符，如果不經過編碼，那么它們有可能會造成Url語義的不同。編碼上的區別就不說了，百分號加十六進制。
表單提交
當Html的表單被提交時，每個表單域都會被Url編碼之后才在被發送。由於歷史的原因，表單使用的Url編碼實現並不符合最新的標准。例如對於空格使用的編碼並不是%20，而是+號，如果表單使用的是Post方法提交的，我們可以在HTTP頭中看到有一個Content-Type的header，值為application/x-www-form-urlencoded。大部分應用程序均能處理這種非標准實現的Url編碼。
#####################################
服務器的解碼
服務器有其自己默認的解碼方式，例如tomcat遵從iso-8859-1進行解碼，我們在服務器端獲取到的GET請求中的數據已經是解碼后的，而解碼過程中程序里是無法指定。當客戶端與服務端編碼方式不同時就會出現亂碼的情況。
所以說，URL編碼只涉及瀏覽器與服務端數據傳輸時體現作用，使用各種編碼進行注入的fuzzing，判斷后端解碼的方式，將我們想要注入的語句正確的“傳送”到服務端，編碼的目的就達到了，后續繞過WAF之類的就不是他需要考慮的了，需要考慮WAF機制中對請求數據的處理方式（服務端->數據庫）。
參考：https://my.oschina.net/weiweiblog/blog/476670
http://blog.csdn.net/zmx729618/article/details/51381655