HTTP协议中参数组件的传输是“key=value”键值对的形式，如果要传输多个参数就需要用“&”符号对键值对进行分隔。例如?name1=value1&name2=$value2,这样在服务器收到这种字符串的时候，会用“&”分隔出每一个参数，然后再用“=”来分隔出参数值。
针对“name1=value1&name2=value2”我们来说一下客户端到服务器端的概念上解析过程：
上述字符串在计算机中用ASCII码（16进制）表示为： 6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
| ASCII码 | 含义 |
|---|---|
| 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编码只是简单的在特殊字符的各个字节（16进制）前加上”%”即可。例如，我们对上述会产生歧义的字符进行编码后的结果：name1=va%26lu%3D，这样服务器会把紧跟在”%”后的字节当成普通的字节，不会把它当成各个参数或键值对的分隔符。
另外一个问题是，为什么要用ASCII码传输，可不可以用别的编码？
当然可以用别的编码，你可以自己开发一套编码然后自己进行解析。就像大部分国家都有自己的语言一样。但是国家之间要怎么进行交流呢，用英语吧，英语的使用范围最广。
通常如果一样的东西需要编码，就说明这样的东西并不适合传输。至于原因有多种多样，size过大，包含隐私数据等等。对于URL来说，之所有要进行编码，是因为URL中有些字符会引起歧义。
例如，URL参数字符串中如果包含”&”或者”%”势必会造成服务器解析错误，所以需要对其进行编码。
又如，URL的编码格式采用的是ASCII码而不是Unicode，这也就是说你不能在URL中包含任何非ASCII字符，比如中文。否则如果客户端浏览器和服务器端浏览器支持的字符集不同的情况下，中文可能会造成问题。
URL编码的原则就是使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符
哪些字符需要编码
RFC3986文档规定，URL中只允许包含英文字母（a-zA-Z）、数字（0-9）、- _ . ~4个特殊字符以及所有的保留字符。RFC3986文档对URL的编码解码问题做出了详细的建议，指出了哪些字符需要被编码才不会引起URL语义的转变，以及对为什么这些字符需要编码做出了相应的解释。
US-ASCII字符集中没有对应的可打印字符：URL中只允许使用可打印的字符。US-ASCII码中的10-7F字节全都表示控制字符，这些字符不能直接出现在URL中。同时对于80-FF字节，由于已经超出了ASCII码定义字符的范围，因此也不能放在URL中。
保留字符：RUL可以划分为干了组件，协议、主机、路径等。有一些字符（： / ? # [ ] @）是用作分隔不同组件的。例如：冒号用于分隔协议和主机组件，斜杠用于分隔主机和路径，问号用于分隔路径和查询参数，等等。还有一些字符（! $ & * + , ; =）用于在每个组件中起到分隔作用，如等号用于表示查询参数中的键值对，&符号用于分隔查询多个键值对。当组件中的普通数据包含这些特殊字符时，需要对其进行编码。
RFC3986中指定了以下字符为保留字符： ！ * ’ ( ) ; : @ & = + $ , / ? # [ ]
不安全字符：还有一些字符，当他们直接放在URL中的时候，可能会引起解析程序的歧义。这些字符被视为不安全的字符，原因有很多。
- 空格：URL在传输的过程，或者用户在排版的过程中，或者文本处理程序在处理URL的过程，都有可能引入无关紧要的空格，或者将那些有意义的空格给去掉。
- 引号 以及 <>：引号和尖括号通常用于在普通文本中起到分隔URL的作用。
- #：通常用于表示书签或者锚点。
- %：百分号本身用作对不安全的字符进行编码是使用的特殊字符，因此本身需要编码。
- { } | ^ [ ] ’ ~：某一些网关或者传输代理会篡改这些字符
需要注意的是，对于URL中的合法字符，编码和不编码是等价的，但是对于上边提到的这些字符，如果不经过编码，那么它们可能会造成URL语义的不同。因此对于URL而言，只有普通英文字符和数字，特殊字符$ - _ . + ! * ’ ( )还有保留字符，才能出现在未经编码的Url中，其他字符均需要编码之后才能出现在URL中。
但是由于历史原因，目前尚存在一些不标准的编码实现，例如对于”~”符号，虽然RFC3986文档规定，对于波浪号~不需要进行URL编码，但是还是有很多老的网关或者传输代理会进行编码。
如何对URL中的非法字符进行编码
URL编码通常也被称为百分号编码，是因为它的编码方式非常简单，使用%加上两位字符———[0-9A-F]———代表一个字节的十六进制的形式。URL编码默认使用的字符集是US-ASCII码，例如a在US-ASCII码中对应的字节值是0x61,那么URL编码之后得到的就是%61,我们在地址栏中输入http://g.cn/search?q=%61%62%63，实际上就等于在google中搜索abc。又如@符号在ASCII字符集中对应的字节为0x40，经过URL编码之后得到的就是%40.
对于非ASCII字符，需要使用ASCII字符集的超集进行编码得到相应的字节，然后对每个字节执行百分号编码。对于Unicode字符，RFC文档建议使用utf-8对其进行编码得到相应的字节，然后对每个字节执行百分号编码。如”中文”使用UTF-8编码得到的字节是0xE4 0xB8 0xAD 0xE6 0x96 0x87,经过URL编码之后得到%E4%B8%AD%E6%96%87
如果某个字符对应的ASCII字符集中的某个非保留字符，则此字节无需使用百分号表示。例如”Url编码”,使用UTF-8编码得到的字节是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81,由于前三个字节对应着ASCII中的非保留字符”Url”,因此这三个字节可以用非保留字符”Url”表示。最终”Url编码”经过编码之后得到的是Url%E7%BC%96%E7%A0%81,当然，如果你用%55%72%6C%E7%BC%96%E7%A0%81也是可以的。
由于历史原因，有一些Url编码实现并不完全遵循这样的原则
JS中提供3个函数对URL进行编码和解码 escape/unescape,encodeURI
/decodeURI,encodeURIComponent/decodeURIComponent.