URL 编码与解码

三条规则，选错那条就是 bug

百分号编码把一个字符替换成 % 后面跟上它的字节值的十六进制。够简单了。真正惹麻烦的是，关于哪些字符需要被替换，存在三种不同的意见，而它们的分歧恰恰落在那些要紧的字符上。

本工具一次把三种都显示出来，原因正在于此。把它们并排读一遍，比抽象地去判断你到底想要哪一种要快。

它能避免的那个错误

假设一个搜索值是 coffee & cake。按 component 规则编码后它变成 coffee%20%26%20cake，URL 是这样：

/search?q=coffee%20%26%20cake

一个参数，值完好无损。而用 encodeURI 编码，那个 & 号会原样活下来：

/search?q=coffee%20&%20cake

现在服务器看到的是两个参数——q 的值是「coffee 」，另外还有一个名叫「 cake」的空参数。没有任何报错。搜索只是悄悄返回了错误的结果，而这正是那种能通过评审的 bug，因为 URL 看起来完全正常。

那个不是加号的 +

另一个可靠的混淆来源。在表单编码的数据里，+ 表示一个空格，而真正的加号必须写成 %2B。所以用表单规则解码 C%2B%2B 会得到 C++，但解码 C++ 会得到 C——外加两个空格，语言名字没了。

这一条在电话号码上咬得最狠。+44 20 7946 0958 通过表单提交、又用错误的规则解码，就变成了 44 20 7946 0958，丢掉了国家代码前缀，而且任何地方都不会报错。

别手工编码，该怎么做

在 JavaScript 里，用 URLSearchParams 来构造查询字符串，而不是拼接。它会为每个值套用正确的规则，也能处理重复的键：

const url = new URL('https://example.com/search');
url.searchParams.set('q', 'coffee & cake');
url.searchParams.set('page', '2');
// https://example.com/search?q=coffee+%26+cake&page=2

其他每种语言都有对应的东西，而它们每一个都比逐字符去判断更可靠。本页是给这些时候用的：你在读别人发给你的一条 URL，或者在调试一条已经出了问题的 URL。

读懂一条编码过的 URL

有几个序列值得一眼认出来，因为它们在日志里不断出现：

尤其 %2520 值得记住：它是被编码了第二次的 %20。它通常意味着一个值穿过了两层，而每一层都编码了它一次；它是某条跳转链或某个代理干了错事的签名。

相关

如果要编码字节而不是转义文本，Base64才是那件不同的活儿。如果解码出来的值原来是 JSON，格式化器会替你读它；如果它是一个令牌，那就交给 JWT 解码器。