为什么http请求get请求参数中的%并没有给转换成%25，而是直接传了%
当 HTTP GET 请求中的参数包含 %，但未被 URL 编码转换成 %25 的情况，通常有以下几种原因。下面逐一分析：
1. 客户端未正确进行 URL 编码
可能是客户端构造 URL 请求时，没有对特殊字符进行正确的 URL 编码。如果查询参数中的 % 没有通过 URL 编码转化为 %25，那么它可能是直接作为原始字符进行传递。
示例：
GET /?query=value% HTTP/1.1
这种情况下，服务器通常会尝试解析 % 后的字符，检查是否符合 %xx 的 URL 编码规范。若没有合法的后续字符，可能会导致解析失败，或在某些情况下直接将 % 作为普通字符进行处理。
2. 部分工具或开发者混淆
在构造 URL 时使用了不规范或手动拼接方式。例如开发者或工具直接将字符串拼接为 URL：
url := "http://example.com/?query=value%"
没有使用像 url.QueryEscape() 或类似工具进行 URL 编码来确保安全性或标准化，导致 % 未被转换为 %25。
3. 部分服务器允许保留未编码的 %
有些服务器（或框架）可能配置为允许原始 % 而不执行严格的 URL 解析。这种情况可能出现在宽松解析规则的服务器实现中，但这通常不是推荐的行为。
如果 % 后面的字符不是合法的十六进制序列（如 %23 或 %20），一些服务器可能直接视其为不需要进一步解析的普通字符。
4. URL 规范未严格遵守
根据 RFC 3986 的规定，URL 中的特殊字符（如 %) 必须经过 URL 编码。未编码的 % 被视为不符合规范的请求。
- 如果客户端未编码
%，理论上服务器会报告解析错误。非规范的客户端行为会导致服务器无法正确解析参数数据。 - 如果服务器不用严格的 URL 解析器，它可能直接接受
%并当做普通字符进行处理。
5. 其他部分已转义的原因
如果 GET 请求的其他参数部分（如空格、& 或 =）已经被转义（编码成 %20、%26、%3D），而只有 % 没有被处理，那么很可能是客户端在生成 URL 时，将一些字符进行了编码，而某些字符未进行编码，这通常是由于编码过程存在缺陷。
示例：
url := fmt.Sprintf("http://example.com/?query=%s&other=%s", "value%", "a+b")
没有对 value% 使用 url.QueryEscape，导致 % 未被转义，而 a+b 被正确编码。
6. 传递 % 的特殊目的
某些情况下，客户端可能故意传递未编码的 %，希望服务器将它识别为特殊标识，或者仅作为普通字符使用，而不是编码后的 %25。这一行为通常属于非标准用法，需要服务器明确支持该情况。
建议解决方式
- **客户端：**确保在构造 HTTP GET 请求时，正确对参数进行 URL 编码。例如在 Golang 中使用
url.QueryEscape()：
query := "value%"
encodedQuery := url.QueryEscape(query) // 转换为 value%25
url := fmt.Sprintf("http://example.com/?query=%s", encodedQuery)
- **服务器：**使用规范的 URL 解码工具处理收到的参数，拒绝未编码的特殊字符，确保遵守 HTTP 和 URL 标准。
- 在严格模式下，未编码的
%应被直接视为解析失败。 - 解析失败时，可以返回
400 Bad Request。
总结
如果 GET 请求参数中的 % 未转换成 %25，通常是因为客户端未对参数进行正确的 URL 编码。这是客户端构造请求的问题，符合 RFC 3986 的行为应该始终对 % 进行编码为 %25，以确保兼容性和解析的可靠性。
建议检查客户端代码中是否存在编码未完成或错误生成 URL 的情况，并使用成熟工具库完成 URL 处理。
关注公众号：程序新视界，一个让你软实力、硬技术同步提升的平台
除非注明，否则均为程序新视界原创文章，转载必须以链接形式标明本文链接
