为什么要 urlencode()

转自：http://www.cnblogs.com/oxspirt/p/6165821.html

1.是因为当字符串数据以url的形式传递给web服务器时,字符串中是不允许出现空格和特殊字符的

2.
因为 url 对字符有限制，比如把一个邮箱放入 url，就需要使用 urlencode 函数，因为 url 中不能包含 @ 字符。
 
 
 
 
 

3.url转义其实也只是为了符合url的规范而已。因为在标准的url规范中中文和很多的字符是不允许出现在url中的。
 
 
 
 

（主要就是消除服务器解析url时的奇异）

   
   

    
    
我们都知道Http协议中参数的传输是"key=value"这种简直对形式的，如果要传多个参数就需要用“&”符号对键值对进行分割。如"?name1=value1&name2=value2"，这样在服务端在收到这种字符串的时候，会用“&”分割出每一个参数，然后再用“=”来分割出参数值。 
    
    
   
   
   
   

    
    
针对“name1=value1&name2=value2”我们来说一下客户端到服务端的概念上解析过程: 
  上述字符串在计算机中用ASCII吗表示为： 
  
    
    6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532。 
   6E616D6531：name1 
   3D：= 
   76616C756531：value1 
   26：& 
   6E616D6532：name2 
   3D：= 
   76616C756532：value2 
   服务端在接收到该数据后就可以遍历该字节流，首先一个字节一个字节的吃，当吃到3D这字节后，服务端就知道前面吃得字节表示一个key，再想后吃，如果遇到26，说明从刚才吃的3D到26子节之间的是上一个key的value，以此类推就可以解析出客户端传过来的参数。 

   现在有这样一个问题，如果我的参数值中就包含=或&这种特殊字符的时候该怎么办。 
比如说“name1=value1”,其中value1的值是“va&lu=e1”字符串，那么实际在传输过程中就会变成这样“name1=va&lu=e1”。我们的本意是就只有一个键值对，但是服务端会解析成两个键值对，这样就产生了奇异。 


    
    如何解决上述问题带来的歧义呢？解决的办法就是对参数进行URL编码 
   URL编码只是简单的在特殊字符的各个字节前加上%，例如，我们对上述会产生奇异的字符进行URL编码后结果：“name1=va%26lu%3D”，这样服务端会把紧跟在“%”后的字节当成普通的字节，就是不会把它当成各个参数或键值对的分隔符。 
   
   

看一下php的urlencode的说明:
urlencode — 编码 URL 字符串
string urlencode ( string $str )
返回字符串，此字符串中除了 -_. 之外的所有非字母数字字符都将被替换成百分号（%）后跟两位十六进制数，空格则编码为加号（+）。此编码与 WWW 表单 POST 数据的编码方式是一样的，同时与 application/x-www-form-urlencoded 的媒体类型编码方式一样。由于历史原因，此编码在将空格编码为加号（+）方面与 RFC1738 编码（参见 rawurlencode()）不同。此函数便于将字符串编码并将其用于 URL 的请求部分，同时它还便于将变量传递给下一页。
哪些字符是需要转化的呢？
1. ASCII 的控制字符
这些字符都是不可打印的，自然需要进行转化。
2. 一些非ASCII字符
这些字符自然是非法的字符范围。转化也是理所当然的了。
3. 一些保留字符
很明显最常见的就是“&”了，这个如果出现在url中了，那你认为是url中的一个字符呢，还是特殊的参数分割用的呢？
4. 就是一些不安全的字符了。
例如：空格。为了防止引起歧义，需要被转化为“+”。
明白了这些，也就知道了为什么需要转化了，而转化的规则也是很简单的。

按照每个字符对应的字符编码，不是符合我们范围的，统统的转化为%的形式也就是了。自然也是16进制的形式。

和字符编码无关
通过urlencode的转化规则和目的，我们也很容易的看出，urleocode是基于字符编码的。同样的一个汉字，不同的编码类型，肯定对应不同的urleocode的串。gbk编码的有gbk的encode结果。
apache等服务器，接受到字符串后，可以进行decode，但是还是无法解决编码的问题。编码问题，还是需要靠约定或者字符编码的判断解决。
因此，urleocode只是为了url中一些非ascii字符，可以正确无误的被传输，至于使用哪种编码，就不是encode所关心和解决的问题了。
编码问题，不是urlencode所要解决的。