一、问题描述
场景描述：用户需要搜索一些活动号，这些活动号名称是用户自由定义的，用户为了提高识别度，会加一些特殊字符，但是我们的接口默认不支持特殊字符搜索，例如[]{}诸如此类，以及以下情况：
参数以字母问号 ? 、与运算符号 & 、井号 # 开头的 Get 请求，对应变量被解析为”参数为空“或者”参数不存在“；
参数中出现若干个空格 ，访问链接解析异常，无法访问；
参数中出现百分号 % ，某些场景下会出现参数值解析截断；
参数中出现中括号[、] 任意的字符，直接报错 405 – Bad Request；
上述问题在前端进行 Base64 编码后传输，拼接新的 url Get 请求访问第三方接口时，同样出现上述错误。
其实在上面的描述中已经透露出了问题发生的原因和可能的解决方案，就是由于没有对参数进行编码，直接进行拼接导致的报错，经过编码后基本都可以规避上述问题。下面将会对每一个问题以及其具体的原因进行分析。
二、问题分析
1. 参数为空/不存在
这种情况在后端（比如 Java）的表现就是，获取的参数 keyword = null 或者 keyword = “”（keyword 定义为 String 时），也就是前端的 url 并没有准确将参数的值完整地传输到后端。
在 url 中，诸如字母问号 ? 、与运算符号 & 、井号 # 这样的字符属于保留字符，即它们在 url 中具有特定意义：
?：分隔 url 和查询参数
&：分隔参数
#：指定书签和锚点
因此，当 url 中的参数以这些字符开头时，参数的解析会在这些字符的位置被中断，从而将对应变量传入的参数值解析为空。
2. 空格导致访问链接解析异常
很明显，如果 url 没有经过编码，空格会被参数携带并拼接到 url 链接后，这样对应服务器来说，这个空格的含义就很模糊了，到底是参数的一部分，还是将前半部分当作 url，后半部分当作下一组字串。
因此，在一些场景下空格会被编码成加号 + 或者其 url 编码 %20，这样才能安全准确地传输到后端接口中。
3. 参数值解析截断
百分号 % 是 url 编码（也称百分号编码）的重要标识，通常使用百分号加上两位十六进制的字符表示特定字符。如果参数值中出现百分号加上两位十六进制数的形式正好与某个特殊字符的编码值对应，那么这部分值就会被解析成对应的字符，并按照其功能继续解析 url，从而造成对原来的 url 解析异常。
要避免这类问题，同样的需要对百分号 % 字符做编码。
4. 中括号[、] 导致报错 400 – Bad Request
通常情况下，HTTP 400 报错是由于请求参数和服务器接收参数的格式不同而导致的。这类问题通常与客户端或者浏览器没有太大的关系，主要原因通常出现在服务器端。当前生产环境常用的 tomcat 版本基本都包含一个新的特性：
严格按照 RFC 3986规范进行访问解析，而 RFC 3986 规范定义了 Url 中只允许包含英文字母（a-zA-Z）、数字（0-9）、-_.~4个特殊字符以及所有保留字符。
因此，只要 Get 请求的参数包含中括号的任一字符，都会报错 400。
5. 进行 Base64 编码后传输，在服务内部仍出现上述问题
虽然参数经过编码后顺利完整地传输到后端服务当中，但是如果后端服务的处理中没有对参数进行参数，而是仍然通过简单拼接后发起 Http Get 请求，那么上面的问题依然会出现。
三、解决方案
经过上面的分析和描述，解决方案基本已经很明显了。整理一下，大概可以分为以下几种方案：
1. 传参前先转义或者编码
很多编程语言或者开发工具都自带 url 编码或者 uri 转义的接口，完成转移后再进行请求，就能避免上述问题。想要简单处理的话，也可以手动对特殊字符进行转换，只要满足 url 编码规则，传输后的转义字符也是能够被正确识别出来的。
url 的编码格式采用的是ASCII码，因此不能在 url 中出现其他编码的字符（如 unicode 编码的中文）。具体的编码规则见下面协议支持的编码表格。
javascript的编码方法是：
encodeURIComponent(str); // 编码
decodeURIComponent(str); // 解码完成上面的编码后，就可以直接通过传入 URI 对象而不是简单的 url 字符串发起 Http Get 请求，这样就能规避上述的问题了。
2. 避免简单拼接构造请求 url
相比于 Get 请求通过简单拼接构造完整的请求 url，Post 请求参数的传输方式就已经在形式上保证了参数字符的完整性。不管是采用 x-www-form-urlencoded 的表单形式，还是 application/json，都对传入的参数进行了编码，且保证了访问地址 url 的独立性，防止用户自由输入的参数值影响了 url 地址的解析。
四、协议支持
RFC 3986文档规定，url 中只允许包含以下四种：
英文字母（a-zA-Z）
数字（0-9）
-_.~ 4个特殊字符
所有保留字符。
RFC 3986 中指定了以下字符为保留字符（英文字符）： ! * ' ( ) ; : @ & = + $ , / ? # [ ]
包括这些保留字符在内的一些特殊字符的编码值如下表所示：
五、总结
总的来说，Get 请求在一些简单获取数据的场景应用得还是比 Post 请求要多，当请求参数或者访问链接无法由开发者完全进行限定时，就必须要考虑到编码问题，以确保用户自由输入的内容不会对服务的正常进行产生影响。对于开发者来说，目前成熟的框架和最佳实现有很多，尽可能采用前人留下的稳定的方案，避免以自己的方式实现原生的逻辑，因为你不知道在这个过程中到底会踩多少坑。
