为什么要进行 URL 编码

HTTP 协议中参数组件的传输是 “key=value” 键值对的形式，如果要传输多个参数就需要用 “&” 符号对键值对进行分隔。例如?name1=value1&name2=$value2, 这样在服务器收到这种字符串的时候，会用 “&” 分隔出每一个参数，然后再用 “=” 来分隔出参数值。

针对 “name1=value1&name2=value2” 我们来说一下客户端到服务器端的概念上解析过程：
上述字符串在计算机中用 ASCII 码（16 进制）表示为：
6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532

服务器端在接收到该数据后就可以遍历该字节流，首先一个字节一个字节的读取，当读到 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.

原文地址 blog.csdn.net