又是被 URL 创的一天：我还在被 url 折磨……

1.
空格的 escape 规则是脑溢血， path 部分必须用 %20，path 中的 + 就表示加号本身；query 部分可以用 %20 或 + ，加号本身反而需要转义。（为什么呢？因为历史遗留问题，我甚至也没找到 + 的标准在哪儿定义的，RFC 3986 里真没写 + 可以用于转义空格）
https://stackoverflow.com/questions/1634271/url-encoding-the-space-character-or-20

(for backwards compatibility: do not try to search for it in the URI standard)

现代浏览器使用 %20。但是各种语言的库出于兼容性仍然使用 + 来 escape 空格。

但是但是，在非 web 的世界里，大家又遵守标准的 URI 规范了……如 mailto 中：

Note that for email links, you do need %20 and not + after the ?. For example, mailto:[email protected]?subject=I%20need%20help. If you tried that with +, the email will open with +es instead of spaces.

2.
由于 / 可被 escape 成 %2F ，而 url path resolve 标准化 (处理 path 中的 ../ 和 ./) 过程只对 / 字面量生效 （resolve 发生在 url unescape 之前）
而经过 unescape 后，%2F 和真正的 / 都被 unescape 成了 /，这时候 url 的 path 就不是它真正的 path 了。

所以需要保留原始的 path 用于正确处理 url join ，而不是用解码后的 path。

我感觉这里会有好玩的事情发生。
如果一些 http web 框架/反向代理/WAF/CDN 的机制不一致，比如一个是用 resolve+unescape 后的 path 来路由，一个使用 resolve 了但没有 unescape 的 path 来路由，一个使用原始的 path 来路由。
嘿嘿嘿/

3.
url path 中如果出现非有效 hex 的百分号编码（比如 %ZZ），基本上各种 http server 会无条件拒绝，返回 400 ，有些则是直接断连接。
但是，如果 query 中出现了非有效的 hex，大家的选择是丢掉坏掉的那一项 query kv pair。