什么是 URL 编码与解码？
URL 编码并不是简单地“把特殊字符换一下”，而是把需要进入 URI 的字节内容转换成更安全的文本表示。只要一个值要进入路径、查询参数、跳转地址、回调链接或其他带语法含义的 URL 位置，就会遇到这个问题。URL 解码则是把这些 `%HH` 形式的字节表示还原回可读内容，方便你确认原始值到底是什么。
百分号编码到底怎样工作
现代 Web 场景里，字符串通常会先按 UTF-8 变成字节，再由编码器决定哪些字节可以直接保留，哪些字节必须写成 `%HH` 十六进制序列。真正影响结果正确性的，不只是“要不要编码”，而是当前这个值要进入整个 URL、路径片段、查询参数，还是表单提交语境。
- 字母、数字、连字符、下划线、句点和波浪号通常属于非保留字符，可以直接保留。
- 空格、`&`、`?`、`=`、`/` 以及非 ASCII 文本，往往需要编码，否则容易和 URL 语法冲突或在不同系统里被误解。
- 表单式编码有时会把空格写成 `+`，而通用 URI 编码更常见的是 `%20`，所以不是所有“编码过的 URL 字符串”都能无脑互换。
如何使用这个工具
- 先确认当前处理的是完整 URL、路径片段，还是单个查询参数值。
- 执行编码或解码后，重点检查空格、保留字符和 UTF-8 内容是否正确。
- 只有确认转换方向和目标 URL 上下文都正确后，才继续复用结果。
URL 编码/解码 示例
这个 URL 编码/解码 示例使用有代表性的查询参数、路径片段、回调地址、复制来的链接和百分号编码文本，展示生成后的适合 URL 传输的文本或解码后的可读字符，便于你先确认保留字符、空格、UTF-8 字节、双重编码，以及当前处理的是完整 URL 还是单个组件，再把同样设置用于真实输入。
示例输入
https://codertools.site/search?q=json formatter&lang=en
预期输出
https%3A%2F%2Fcodertools.site%2Fsearch%3Fq%3Djson%20formatter%26lang%3Den经典编码示例
原始值：
https://example.com/search?q=json formatter&lang=zh-CN
编码后：
https%3A%2F%2Fexample.com%2Fsearch%3Fq%3Djson%20formatter%26lang%3Dzh-CN常见使用场景
URL 编码/解码 最适合用在查询参数、路径片段、回调地址、复制来的链接和百分号编码文本需要快速变成适合 URL 传输的文本或解码后的可读字符的场景，尤其是OAuth 回调核对、搜索参数调试、链接清理、统计 URL 和复制来的 API 示例。
- 用于编码 URL 组件或解码百分号字符串，服务于OAuth 回调核对、搜索参数调试、链接清理、统计 URL 和复制来的 API 示例。
- 处理重要输入前，可先用示例流程确认保留字符、空格、UTF-8 字节、双重编码，以及当前处理的是完整 URL 还是单个组件。
- 当结果符合目标流程后，再复制或下载适合 URL 传输的文本或解码后的可读字符。
URL 编码在真实流程里最容易错在哪里
URL 编码的真实问题，往往不是“不会 encodeURIComponent”，而是把正确的动作用在了错误的位置：本来只该编码参数值，却把整条 URL 全部编码；值本身已经是正常文本，又被多解一次；前端、后端和表单系统对同一段数据采用了不同约定。只要上下游约定不统一，这种问题就会反复出现。
- 第一步永远是先分清楚：你当前编码的是完整 URL、路径片段，还是单个参数值。
- 排查回调地址、跳转链路或第三方参数时，最好把原始值和编码值并排保留。
- 浏览器输出应被看作“面向某个具体上下文的文本”，而不是所有下游系统都会以同样方式解释的通用表示。
什么时候编码整个 URL，什么时候只编码参数值
很多线上问题并不是“不会编码”，而是编码层级搞错了。你在手动拼接查询字符串时，通常应该编码参数值，而不是把一个已经包含 `?`、`&`、`=` 语法的完整 URL 外壳再整体编码一次。
- 当一个完整 URL 要作为“另一个 URL 的参数值”出现时，才需要对这个完整 URL 进行编码。
- 当你只是填写查询参数、搜索关键词、回调 token 或用户输入值时，更常见的是只编码参数值。
- 重复解码也很危险，因为一个已经恢复好的值，再多解一次，可能把本来需要保留的百分号序列继续破坏掉。
URL 编码和相邻格式的区别
| 格式 | 核心作用 | 常见用途 |
|---|---|---|
| URL 编码 | 在 URI 语境里转义字节 | 查询参数、跳转地址、路径片段 |
| Base64 | 把二进制字节转成可打印文本 | 令牌片段、Data URI 载荷、文本化传输 |
| HTML 实体 | 转义 HTML 敏感字符 | 模板输出、富文本、标记嵌入 |
使用注意
- 复用适合 URL 传输的文本或解码后的可读字符前，先检查保留字符、空格、UTF-8 字节、双重编码，以及当前处理的是完整 URL 还是单个组件。
- 不要对来源不明的 URL 反复解码，双重解码可能改变保留字符并破坏链接。
- 当结果会影响生产工作或客户可见内容时，应保留原始查询参数、路径片段、回调地址、复制来的链接和百分号编码文本以便回退和核对。
URL 编码/解码 参考说明
URL 编码/解码 需要说明百分号编码的底层规则：字符串先转成字节，再把 URL 保留集之外的内容写成 `%HH` 形式。
- URL 编码通常会先把文本转换成 UTF-8 字节，再把保留或不安全的字节写成 `%HH` 十六进制序列。
- 字母、数字、连字符、下划线、点号和波浪号这类非保留字符通常会原样保留。
- 解码时会先把 `%HH` 还原成字节，再按约定字符集解释，默认通常是 UTF-8。
参考资料
常见问题
以下问题围绕 URL 编码/解码 的实际用途整理，重点说明输入要求、输出结果和常见限制。安全编码 URL 片段，或解码转义后的 URL 字符串。
在 URL 编码/解码 里，应该编码完整 URL，还是只编码其中一个组件？
大多数情况下更适合只编码需要转义的那个组件，例如查询参数或回调值。盲目对完整 URL 再编码，会让结果更难阅读和复用。
为什么 URL 编码/解码 里空格会变成 %20，而不是 +？
百分号编码和表单编码相关但并不完全相同。`%20` 是更通用、更安全的 URL 表示，而 `+` 常见于特定的表单式查询编码场景。
为什么在 URL 编码/解码 里反复解码会把链接弄坏？
双重解码会把保留字符重新还原成真正的分隔符，从而改变查询边界或路径片段。只有在明确知道当前字符串仍是编码态时，才应该继续解码。
URL 编码/解码 最适合处理什么样的查询参数、路径片段、回调地址、复制来的链接和百分号编码文本？
URL 编码/解码 的核心用途是编码 URL 组件或解码百分号字符串。当查询参数、路径片段、回调地址、复制来的链接和百分号编码文本需要快速变成适合 URL 传输的文本或解码后的可读字符，并继续用于OAuth 回调核对、搜索参数调试、链接清理、统计 URL 和复制来的 API 示例时，它最有价值。
复用 URL 编码/解码 生成的适合 URL 传输的文本或解码后的可读字符前，最该检查什么？
应优先检查保留字符、空格、UTF-8 字节、双重编码，以及当前处理的是完整 URL 还是单个组件。这些细节最能直接判断结果是否已经适合继续交给下游流程。
URL 编码/解码 生成的适合 URL 传输的文本或解码后的可读字符通常会被带到哪里继续使用？
最常见的下一步就是用于OAuth 回调核对、搜索参数调试、链接清理、统计 URL 和复制来的 API 示例。这类输出是按真实交接场景来组织的，不是泛化占位结果。
什么时候不应该直接相信 URL 编码/解码 的结果，而要人工复核？
不要对来源不明的 URL 反复解码，双重解码可能改变保留字符并破坏链接。