URL编码：何时逃跑，何时破坏东西

必须编码什么

一小组字符始终是安全的 - 字母、数字、`-`、`_`、`.` 和 `~`。其他一切要么被保留，要么应该被转义。保留字符是有趣的字符，因为它们在 URL 中是合法的，但仅在特定位置：`?` 开始查询，`&` 分隔参数，`=` 分配值，`#` 启动片段，`/` 分隔路径段。将其中一个放入未编码的值中，您就默默地重写了 URL 的结构。

加或%20

太空就是一个典型的例子。路径中，空格必须为`%20`； a `+` 有一个字面上的加号。在表单解析器读取的`application/x-www-form-urlencoded`主体和查询字符串中，`+`被理解为空格。这种差异就是为什么一个值可以编码为在一种上下文中工作而在另一种上下文中中断的东西，以及为什么解码器提供这两种解释。

对组件而不是整个 URL 进行编码。通过组件编码器运行完整的 URL 会转义它自己的 `://` 和 `?`，从而生成一个无法解析的链接。

JavaScript 的区别吸引了所有人

                encodeURI('https://x.com/a b?q=1')        // keeps :// ? = — for a whole URL
encodeURIComponent('a b?q=1')               // escapes ? and = — for one value
              

`encodeURI` 保留URL 结构，用于完整地址； `encodeURIComponent` 转义了所有重要的内容，并且适用于单个参数值。使用错误的值会产生损坏的 URL 或未转义的值，并且症状相反：出现 404 错误的链接，或丢失一半参数的查询字符串。

双重编码和签名 URL

对已编码的值进行编码会将 `%20` 转换为 `%2520`，然后服务器将其解码一次，并将文本 `%20` 传递给您的应用程序，其中原本应该有一个空格。这出现在分层系统中——代理重新编码目标，客户端转义它收到的已经转义的 URL。对于签名 URL 最重要的是：签名是根据精确的编码字符串计算的，因此更改一个字符的转义会使链接无效，即使它仍然解析为相同的资源。

解码调试

当链接出现故障时，对其进行解码是查看服务器实际请求内容的最快方法，而答案通常是泄漏到结构中的值。在浏览器中工作意味着您可以粘贴包含令牌、签名参数或客户标识符的 URL，而无需将其发送到任何地方，这正是您不应粘贴到记录请求的服务中的 URL 类型。