记得以前在看文章的时候说，有的时候 改变一下URL编码就可以绕过一些防住入的代码，
关于 转换URL编码的注入的一点总结脚本安全
。实现注入。今天抽时间 把url编码从新学习了一下,做个简单的笔记吧。
首先百度一下：URL编码的介绍：
http://baike.baidu.com/view/204662.htm
介绍中使这样定义url编码的：
url编码是一种浏览器用来打包表单输入的格式。浏览器从表单中获取所有的name和其中的值 ，将它们以name/value参数编码（移去那些不能传送的字符, 将数据排行等等）作为URL的一部分或者分离地发给服务器。
从定义中，实现URL编码的过程是发生在浏览器端的，也就是在客户端实现的.浏览器把特殊的字符和不能用简单的七位ASCII实现编码的字符，通过URL编码传递给了 服务器。
例如：
在FireFox中输入：
http://172.16.100.59/admin/module/sys/test.php?id=" （%22 = "）
查看 提交的请求头信息：
GET /admin/module/sys/test.php?id=%22 HTTP/1.1
浏览器把这些字符经过了URL编码处理，之后送给了服务器。
既然这个URL编码是在客服端实现的，那么我们把正常的字符也采用url编码的形式提交的话，结果是什么呢？
and 1=1 url(%61%6E%64%201%3D1)
url中输入：
http://172.16.100.59/admin/module/sys/test.php?id=%61%6E%64%201%3D1
test.php的内容如下：
echo $_GET['id'];
结果如下：
and 1=1
这说明了，可以在本地提交正常字符URL编码的形式，提交给了服务端是可行的。
在客户端的 url编码就是这样处理的，遇到不能识别的 或者是浏览器内部制定的 字符的时候，浏览器就把这些字符进行URL编码的处理，如果是正常的能识别的字符的话就不经过url编码的处理。当我们把一个浏览器能识别的字符通过url编码处理之后在传递给浏览器的话，那么浏览器直接把这些内容传递给了 服务器。
url编码在客户端的传递总结就是这样了，
那么下面我们说一下，在服务端是怎么处理的呢？
看例子：
test.php的代码如下：
$id = $_GET['id'];
if($id == "\""){
echo "me too";
访问 http://172.16.100.59/admin/module/sys/test.php?id="
结果 ：
me too
从这里可以看出来 在服务端自动把 URL进行了解码处理，
电脑资料
《关于 转换URL编码的注入的一点总结脚本安全》(https://www.unjs.com)。再来看一下我们常用的 url编码的诸如把：
1 and 1=1 url(1%20%61%6E%64%201%3D1)
修改test.php的代码：
$id = $_GET['id'];
if($id == "1 and 1=1"){
echo "buxuan";
访问：
http://172.16.100.59/admin/module/sys/test.php?id=1%20%61%6E%64%201%3D1
结果是：
buxuan
按照这样结果的话,那么通过URL编码来实现注入的话是根本行不通的啊，那网上好多大牛为什么说可以通过在中方法能实现注入呢 ？
资料上说 是一些asp的防注入脚本中，用来获取客户端的数据的时候调用的是Request.ServerVariables("QUERY_STRING") 来获取url中的内容，依靠这个内置的函数获取过来的URl中的内容都是没有结果解码处理的内容.
其实利用url编码注入的漏洞，知识针对那些在防注入程序中是利用Request.ServerVariables("QUERY_STRING")取来的URL。
现在对PHP比较熟悉：
就拿php来说吧，
test.php
echo $_SERVER['QUERY_STRING'];
访问：
http://172.16.100.59/admin/module/sys/test.php?id=1%20%61%6E%64%201%3D1
输出的结果是：
id=1%20%61%6E%64%201%3D1
简单的整理一下url编码在服务端处理：
通过$_GET $_POST $_COOKIE 获取过来的参数都是结果url解码之后的数据。
通过$_SERVER 得到的 内容都是没有经过url解码处理的数据。
应该是和php的处理机制的问题吧
$_SERVER直接 获取url中的内容 ，而 $_GET $_POST 等 是接受了处理之后的内容。