什么是 URL 编码？

为什么 URL 需要编码

RFC 3986 把 URL 限制在一小组 ASCII 字符内，其中一些还身兼要职：? 开始查询串，& 分隔参数，= 分开参数名和值，# 开始片段，/ 分隔路径段。如果某个值里包含这些字符，URL 就会产生歧义。

以搜索「salt & pepper」为例。直接写成 ?q=salt & pepper，服务器看到的是参数 q 的值为 salt ，以及另一个名为 pepper 的空参数。编码成 ?q=salt%20%26%20pepper 后，它才会作为一个完整的值到达服务器。

哪些字符需要编码

编码针对的是字节而不是字符。非 ASCII 文本先转成 UTF-8，每个字节各自变成一个 %XX 三元组：

十六进制数字不区分大小写，%c3%a9 和 %C3%A9 含义相同，但 RFC 3986 建议统一使用大写。

%20 还是 +：空格的两套规则

RFC 3986 定义的百分号编码总是把空格写成 %20。HTML 表单提交使用的是一种相关格式 application/x-www-form-urlencoded，其中空格变成 +，而真正的加号变成 %2B。

• 在 /files/my report.pdf 这样的路径中，用 %20。路径中的 + 就是字面意义上的加号。
• 在查询串中，按表单编码解析的服务器会把 + 读成空格。%20 两种约定都认，拿不准时用它更稳妥。
• 如果值里可能出现真正的 +，比如 +84 这样的电话号码，必须以 %2B 发送，否则到达时会变成空格。

JavaScript 中 encodeURIComponent 与 encodeURI 的区别

encodeURIComponent("a b&c") 返回 a%20b%26c，而 encodeURI("a b&c") 返回 a%20b&c，因为它默认 & 是分隔符。常见的 bug 就是对参数值调用 encodeURI，导致 &、= 和 # 原样通过，把值拆散了。

new URLSearchParams({ q: "a b&c" }).toString() 得到 q=a+b%26c。在标准服务器上，两种形式解码后的值相同。

常见错误

1. 重复编码：对已经编码过的文本再次编码，会把 %20 变成 %2520，因为 % 本身被编码成了 %25。每个值只在放入 URL 的那一刻编码一次。
2. 用组件函数编码整个 URL：https:// 会变成 https%3A%2F%2F，链接就失效了。
3. 路由前先解码：服务器如果在匹配路由前就把 %2F 解码成 /，就可能被诱导去读取另一个路径。
4. 沿用旧字符集：一些老系统把「é」编码成 %E9（Latin-1）。现代浏览器和 WHATWG URL 标准都使用 UTF-8。