网址编码

这件事有两个答案，这一页两个都给你

这是最值得避开的错误，也是为什么这里不替你做决定。

encodeURIComponent 会把分隔符号 : / ? & = # 一起转掉，因为它假设这段文字是要放 进网址里的——当成查询参数，或路径的一段。如果那些字元原样保留，它们就会改变外层网址的 结构。

encodeURI 则保留它们不动，因为它假设你给的是一整个网址，只是需要整理一下——里面有 空白，或有中文字。

搞反了就是那个经典的错误：用 encodeURI 把一个网址塞进查询参数，它的 ? 和 & 会并进 外层网址里，于是 ?next=https://x.com/a?b=1 悄悄地变成两个参数而不是一个。

状态列会在两者结果不同时告诉你，而那正是这个选择有意义的时候。

表单编码是第三种东西

HTML 表单送出空白时用的不是 %20，而是 +，而且从以前就是这样—— application/x-www-form-urlencoded 比现代的网址规则更早出现，之后也没有跟上。

这就是为什么解码那边有一个把 + 视为空白的选项。少了它，表单值解码出来会留下一堆真的 加号；而把它套用在一般网址上，又会把合法的 + 变成空白。光看字符串本身无法判断是哪一种， 所以它是一个开关，而不是一个猜测。

对已经编码过的东西再编码

%20 会变成 %2520，这是正确的而不是 bug：% 本身就是保留字元，把它编码是表示「一个真 正的百分号」的唯一办法。一个会自动跳过既有编码序列的工具，根本没办法编码 100%。

如果你在网址里看到 %2520，就表示有东西被编码了两次。那就解码两次。

Emoji 与中文

两者都会编成 UTF-8 字节，所以一个中文字会变成三个百分号序列，大多数 emoji 会变成四个。 这是正常的。

不正常的、而且有些工具真的会做错的，是把一个字元从中间切开。任何 U+FFFF 以上的字元——大多数 emoji，以及像 𝕏 这样的字元——在内部是以代理对储存的，如果依索引而不是依字元来编码，就会产生 两个坏掉的半边，解码出来什么都不是。这里是依字元编码的。

没有任何上传

编码在这个页面里完成。这一点在这里特别重要：正在被除错的网址，常常带着权杖、工作阶段识别码 和 API 密钥。