提到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.****.net/zmx729618/article/details/51381655