URL 编码与解码

三种口径与空格

在查询值内部，`encodeURIComponent` 风格的编码会转义 `&`、`=`、`/` 以及其他任何可能被误读的字符，空格变成 `%20`。对整条 URL 而言，只转义非转义不可的部分：分隔 URL 的 `&`、`/` 和 `:` 必须原样保留，否则链接就断了。表单数据里，空格变成 `+`，其余字符沿用组件规则。选择哪一种，取决于这段字符串最终落在 URL 的哪个位置。

解码则反过来，按你声明的来源口径还原。最值得注意的是加号：按组件数据解码时，`+` 仍然是 `+`；按表单数据解码时，`+` 才变成空格。页面在表单口径下的默认行为就是把加号还原成空格，因为表单编码当初正是这么写进去的。范围选错时，输出看起来“几乎对”，却会在某个参数上悄悄错位，这类问题通常比直接报错更难查。

只编码一次，以及双重编码是怎么发生的

百分号本身也是编码器认识的字符，所以对一条已经转义过的 URL 再编码，会把其中的 `%` 号再转义一次，`%20` 就变成了 `%2520`。这不是页面的缺陷，而是查询字符串里 `%26` 反复出现这一现象的同一套机制。页面把这一点说明白：编码一次，然后按字符串当初被编码的次数解码相应的次数。

实践中最常见的场景是回调地址：框架已经对参数做过一次编码，拼接时又整体编码了一次，服务端只解开一层，于是看到的是 `%252F` 之类的字面量。遇到这种链接，先把输入和输出并排看，确认到底叠加了几层，再决定解码几次；盲目多点几次解码，反而可能把本来正确的 `%` 也吃掉。

编码不是加密

这里没有任何东西在隐藏信息。百分号编码的存在是为了让 URL 能携带字符，解码后的形式只有一步之遥。页面把这一点讲明，是因为不少人会把编码过的字符串粘进来，期待它带来隐私保护——而一个用 `%` 转义的字符串，私密程度和 Base64 差不多，也就是说完全没有。

拿到字符串的人不需要密钥，任何解码器都能还原，这个页面也一样。因此，把令牌、密码或个人数据放进编码后的 URL，并不会让它们变得安全；真正需要保护的内容应该走 HTTPS、放在请求体或服务端会话里，而不是指望一层可逆的文本转换。页面负责转义与还原，不负责保密。

非 ASCII 文本会先变成 UTF-8 字节

非 ASCII 字符没有自己单独的一个百分号序列：页面先把它编码成 UTF-8 字节，再让每个字节变成一个 `%XX` 转义。`café` 会变成 `caf%C3%A9`，一个中日韩字符通常变成三个转义。这正是浏览器访问包含这些字节的 URL 时所做的处理。

也正因如此，同一个汉字在不同编码下会得到不同结果；如果服务端按 Latin-1 或 GBK 解读，就会出现乱码。这个页面统一按 UTF-8 处理，与浏览器的地址栏一致；域名那套把非 ASCII 变成 `xn--` 的 Punycode 是另一套方案，不属于百分号编码，这个页面不涉及。

编码在下游修不好什么

百分号编码只在 URL 内部是安全的，出了这个语境就不是。放进 HTML 属性时，分隔查询参数的 & 仍然要在标记里写成 &；放进 JSON 正文时，% 号就是普通字符。编码回答的是「URL 解析器会不会把它当成结构」，不是「它在任何地方都安全」。

服务端也会解码，有些还解两次。拿到时 %20 已经变回空格，说明它在被你看到之前已经被解过一次；拿到的是 %2520，说明出去的路径上又被编码了一次。两者都是「口径与层」的问题，本页的范围设置存在的意义就是把这个问题露出来。

URL 的实际长度上限是页面无法强制的另一件事。浏览器能处理很长的 URL，但代理、邮件客户端与服务端配置常在 2,000 字符左右截断。编码后的内容接近这个量级时，链接里应该只带一个 id，数据放在链接背后。