URL 编码解码工具

URL 的结构依赖一些特定字符——`/` 用来分隔路径段,`?` 用来引出查询字符串,`&` 用来分隔参数,`#` 用于片段标识符——无论出现在哪里,都携带着固定的结构含义。如果要放进 URL 里的一个值,比如一个搜索词或一个用户的名字,恰好字面上包含了这些字符之一,就必须有某种方式区分"这个 & 是值本身的一部分"和"这个 & 是用来分隔两个查询参数的"。百分号编码正是这种机制:任何带有结构含义的字符,当它需要作为字面数据出现而不是作为结构时,会被替换成一个 `%` 加上它的十六进制字节值,所以 `&` 会变成 `%26`,毫无歧义地读作数据,而不是参数分隔符。

最常见的 URL 编码错误,是用错误的函数编码一整个组装好的 URL——对一个完整地址使用会转义包括 `/`、`:`、`&` 和 `?` 在内所有保留字符的 `encodeURIComponent`,而不是只对单个值使用它。协议后面的 `://` 会变成 `%3A%2F%2F`,分隔查询参数的每一个 `&` 都会变成 `%26`,这个 URL 就彻底不再是一个 URL 了——它变成了一长串编码过的字符串,没有任何服务器能解析的结构。正确的做法顺序正好相反:先单独编码每一个具体的值——搜索词、跳转目标,或者不管实际数据是什么——然后再把这些已经编码好的值插入周围的 URL 结构里,事后绝不再对组装好的整体重新编码。

这正是这个工具提供两种明确模式、而不是一个通用"编码"按钮的原因:组件模式用于编码即将成为 URL 一部分的单个值,完整 URL 模式用于编码一整个地址、同时刻意保留其结构字符这种较少见的场合。

今天仍然有两种不同的空格编码惯例在同时使用,而且它们并不能互相替换。百分号编码是通用标准,把空格表示成 `%20`,在 URL 的任何地方——路径、查询字符串,哪里都行——都有效。用 `+` 表示空格的惯例,来自一个更老、范围更窄、专门针对 `application/x-www-form-urlencoded` 内容类型的 HTML 表单提交的标准,只在查询字符串内部有效;一个出现在 URL 路径里的字面 `+` 根本不会被解释成空格,它就只是加号这个字符。这个工具始终产出 `%20`,它在任何场合都有效,同时在读取一个已编码的 URL 时能正确解码这两种形式。

百分号编码的规则适用于任何 URL,无论是什么东西构造或消费它——一个后端服务构建的 webhook 负载、一个移动应用打开的深度链接、一个脚本组装的 API 请求。任何一个可能包含空格、和号或非 ASCII 字符的值被插入一个 URL 字符串的地方,都适用同样的"先编码值再插入"规则,这也是为什么这既是后端和脚本编写要关心的问题,也同样是浏览器要关心的问题。