什么时候该用参数值模式而不是完整 URL 模式？

当你要处理的是放在 ? 或 & 后面的单个值时，用参数值模式（encodeURIComponent），因为它还会转义 &、=、/ 这些否则会被读作分隔符的保留字符。只有在你编码的是一整条完整 URL、且必须保持其结构完整时，才用完整 URL 模式（encodeURI）。

为什么空格变成 %20 而不是加号？

本工具遵循 JavaScript 的编码规则，encodeURIComponent 和 encodeURI 都把空格表示为 %20。用加号代表空格的约定来自 HTML 表单提交（application/x-www-form-urlencoded），而不是这两个函数。

解码时加号会变成空格吗？

不会。decodeURIComponent 会原样保留字面加号，并把 %20 变成空格。如果你拿到的是用 + 表示空格的表单编码查询串，请在解码后手动把加号替换成空格。

为什么某些字符串会报「解码失败」？

一个孤立的百分号，或像 %E4 这样被截断的序列，都不是合法的百分号编码，因此原生解码器会抛出 URIError。请检查是否有游离的 % 字符，或文本只被部分编码。

为什么对已编码的值再次编码会多出 %25？

百分号本身会被编码成 %25，所以对 %20 再编码一次会得到 %2520。这就是二次编码 bug，通常在某个值于重定向链路或模板中被编码了两次时出现。

每种模式会保留哪些不转义的字符？

两种模式都保留未保留集 A-Z、a-z、0-9、-、_、. 和 ~。参数值模式还保留 !、'、(、) 和 *。完整 URL 模式额外保留赋予 URL 结构意义的保留字符，例如 :、/、?、#、&、= 和 +。

URL 编解码器 | HandyTools Hub

URL 编码器把文本转换成可以安全嵌入 URL 的形式，并把百分号编码的字符串解码回可读文本。粘贴一个带空格、& 或中文字符的查询值，就能得到合法、可直接复制粘贴的结果。对于构建链接、调用 API 或拼跟踪 URL 的人，以及想从日志或分析报表里读懂被百分号淹没的 URL 的人，它都是日常工具。

编码与解码

编码模式把可读文本变成百分号编码输出。
解码模式逆转这一过程，把百分号转义还原成字符。
在左侧框输入，结果随输入出现在右侧；复制按钮把它放进剪贴板。
解码方向对所选类型使用对应的原生函数，因此对同一字符串先编码再解码会返回原文。

encodeURIComponent 与 encodeURI

两种类型对保留字符的处理不同，这正是大多数 URL bug 的来源。

输入	参数值（encodeURIComponent）	完整 URL（encodeURI）
`a b&c=d`	`a%20b%26c%3Dd`	`a%20b&c=d`
`https://x.com/p?a=1`	`https%3A%2F%2Fx.com%2Fp%3Fa%3D1`	`https://x.com/p?a=1`
`中`	`%E4%B8%AD`	`%E4%B8%AD`
`a+b`	`a%2Bb`	`a+b`

参数值模式把输入当作数据，因此会转义 &、=、/、?、: 这些否则会改变 URL 含义的字符。完整 URL 模式把输入当作 URL，保留这些结构字符，只编码空格和非 ASCII 文本。选错模式，就是链接把一个参数悄悄拆成两个的常见原因。

URL 为什么需要百分号编码

URL 围绕一个很小的 ASCII 字符集设计，其中若干字符具有结构含义：? 开始查询，& 分隔参数，= 赋值，# 开始片段。任何不在安全集合内的字符——空格、引号、方括号，以及整个非 ASCII 世界——都必须表示成百分号后跟该字符的 UTF-8 字节的十六进制值。非 ASCII 文本先转成 UTF-8 再逐字节编码，这就是一个汉字会变成三段百分号三元组的原因。编码是可逆的纯机械过程，因此只要字符串格式良好，解码器总能还原原文。

实操示例

为查询参数编码值 coffee & tea。参数值模式给出 coffee%20%26%20tea，你可以安全地拼成 ?q=coffee%20%26%20tea。完整 URL 模式会保留 &，把你的值拆成两个参数。
编码完整链接 https://example.com/search?q=a b&lang=en。完整 URL 模式得到 https://example.com/search?q=a%20b&lang=en，在只转义空格的同时保留 scheme、路径和查询分隔符。
编码 中文。两种模式都产生 %E4%B8%AD%E6%96%87，每个 UTF-8 字节对应一段百分号三元组。解码该字符串会返回 中文。
编码 emoji 😀（U+1F600）。它的 UTF-8 字节是 F0 9F 98 80，因此输出为 %F0%9F%98%80。
在参数值模式下解码 %E4%B8%AD%E6%96%87 得到 中文，或解码一个部分编码的链接，查看某次重定向实际指向哪里。

空格与加号为何不同

两个函数对空格都产生 %20，也都把字面加号在完整 URL 模式下保留为 +、在参数值模式下编码为 %2B。真正令人困惑的是表单编码：HTML 表单的 GET 提交和 application/x-www-form-urlencoded 负载用 + 表示空格。如果某个值来自表单且含有 +，本工具不会把它变成空格——请先解码，再手动替换加号。分清这两种约定，是「我的搜索词怎么变成了 coffee+tea」这一困惑的唯一最常见来源。

保留字符与未保留字符

RFC 3986 把 URL 字符分为未保留集和保留集。未保留字符——字母、数字、连字符、下划线、点和波浪号——永远不需要编码。保留字符分两组：:、/、?、#、[、@ 这类 gen-delims 分隔 URL 的各个部分；!、$、&、'、(、)、*、+、,、;、= 这类 sub-delims 在部分内部具有含义。当保留字符被当作数据而非分隔符使用时，就必须百分号编码。这正是参数值模式的职责，而完整 URL 模式适用于保留字符仍在充当分隔符的字符串。

常见错误

用参数值模式编码整个 URL，破坏了它的 ://、? 和 & 分隔符。
用完整 URL 模式编码查询值，让 & 或 = 充当了分隔符。
二次编码，会加入 %25，产生像 %2520 这样明显错误、本应是空格的结果。
以为 !、'、(、)、* 总会被转义。参数值模式会原样保留它们，因此严格遵循 RFC 3986 的系统仍可能拒绝该结果。
解码一个部分编码的字符串，此时一个孤立的 % 会立即报错，而不是给出部分结果。
因为两者在简单 ASCII 上一致就以为可以互换。一旦文本含保留字符，它们就会分道扬镳。

URL 编解码器

用一个真实 URL 参数试试

编码参数值，而不是整个 URL

编码范围必须正确