https://blog.csdn.net/Lxd_0111/article/details/78028889
1. 为什么要URL编码？
一句话总结：是因为URL中有些字符会引起歧义。
比如某个url会是：https://localhost/search?name1=value1&name2=value2, name1=value1&name2=value2代表查询参数。这样在服务器收到这种字符串的时候，会用“&”分隔出每一个参数，然后再用“=”来分隔出参数值。
客户端到服务器端的概念上解析过程：
1. 在客户端，上述URL被URL编码(先转成ASCII码，再用16进制表示)。我们展示一下参数编码后的效果：
6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532
其中：=的ASCII码是61,61转成16进制是3D，&符号的ASCII码是38，38转成16进制就是26
2. 服务端收到URL后
服务器端在接收到该数据后就可以遍历该字节流，首先一个字节一个字节的读取，当读到3D这个字节的时候，服务器端就知道前面读到的字节串表示一个key，继续读取，如果遇到了26，表示从刚才读到的3D到26字节之间的字节串是上一个key的value，按照此方法就可以解析出客户端传过来的参数。
但是此时会有一个问题：如果我的参数值中就包含=或者&这样的特殊子字符的时候，该怎么办。
比如说“name1=value1”,其中value1的值是“va&lu=e1”，那么在传输过程中就会变成“name1=va&lu=e1”。用户传输的本意是只有一个键值对，但是服务器端会解析成两个键值对，这样就自然的产生了歧义。
所以由于要解决这个问题，我们就需要对URL进行编码
2. 如何进行URL编码
一句话总结：URL编码只是简单的在特殊字符的各个字节（16进制）前加上”%”即可。
例如，我们对会产生歧义的字符“name1=va&lu=e1”进行编码后的结果：name1=va%26lu%3De，这样服务器会把紧跟在”%”后的字节当成普通的字节，不会把它当成各个参数或键值对的分隔符。
（注意，这里为了方便name1=va这些并没有进行URL编码，实际上要编码的话所有的都会被编码）
3. 为什么URL编码的时候要用ASCII码传输，可不可以用别的编码？
当然可以用别的编码，你可以自己开发一套编码然后自己进行解析。就像大部分国家都有自己的语言一样。但是国家之间要怎么进行交流呢，用英语吧，英语的使用范围最广。
4. URL编码的原则就是：使用安全的字符（没有特殊用途或者特殊意义的可打印字符）去表示那些不安全的字符
不安全字符：有一些字符，当他们直接放在URL中的时候，可能会引起解析程序的歧义。这些字符被视为不安全的字符，原因有很多：
- 空格：URL在传输的过程，或者用户在排版的过程中，或者文本处理程序在处理URL的过程，都有可能引入无关紧要的空格，或者将那些有意义的空格给去掉。
- 引号 以及 <>：引号和尖括号通常用于在普通文本中起到分隔URL的作用。
- 符号# ：通常用于表示书签或者锚点。
- %：百分号本身用作对不安全的字符进行编码是使用的特殊字符，因此本身需要编码。
- { } | \ ^ [ ] ’ ~：某一些网关或者传输代理会篡改这些字符
5. 哪些字符需要编码
RFC3986文档规定，URL中只允许包含英文字母（a-zA-Z）、数字（0-9）、- _ . ~这4个特殊字符以及所有的保留字符。保留字符： ！ * ’ ( ) ; : @ & = + $ , / ? # [ ]
RFC3986文档对URL的编码解码问题做出了详细的建议，指出了哪些字符需要被编码才不会引起URL语义的转变，以及对为什么这些字符需要编码做出了相应的解释。
