URL 编码 / 解码 — 百分号编码与 URL 解析
以组件、完整 URL 或表单模式对 URL 文本进行百分号编码或解码，并可在表格中编辑 URL 的查询参数。
encodeURIComponent：用于单个查询值或路径段。转义除 A–Z a–z 0–9 - _ . ! ~ * ' ( ) 以外的所有字符。
name%3DZo%C3%AB%20%26%20Tom%20%2F%20caf%C3%A9%3Fid%3D42%23top
URL 解析器和查询字符串编辑器
| 协议 | https: |
|---|---|
| 主机 | shop.example.com |
| 端口 | 8443 |
| 路径 | /search/trail%20shoes |
| 查询 | ?q=trail+running&size=10&color=blue%20%26%20green&utm_source=newsletter |
| 片段 | #reviews |
| 源 | https://shop.example.com:8443 |
https://shop.example.com:8443/search/trail%20shoes#reviews
完全在浏览器中运行。你输入的任何内容都不会发送给我们或被存储。 浏览全部免费工具.
发现问题，或者觉得哪里可以更好？每条消息我们都会阅读，并尽快修复。
这款 URL 编码解码工具可在文本与百分号编码之间相互转换——这种 %20 式的转义能让空格、& 符号、重音字母和表情符号安全地出现在 URL 中。它提供了开发者最容易搞混的三种编码：组件模式，用于单个查询值或路径片段（encodeURIComponent）；完整 URL 模式，保留 URL 自身的标点符号（encodeURI）；以及表单模式，即 HTML 表单和 URLSearchParams 发送的格式，空格编码为 +。
解码特意采用严格模式。浏览器的 decodeURIComponent 只会抛出“URI malformed”，而这里会告诉你哪个 % 序列出了问题、在什么位置，以及字节是否不是有效的 UTF-8（这通常说明上游某处使用了 Latin-1）。编码器下方的 URL 解析器会把任意 URL 拆分成各个部分，并把查询参数列在一个可编辑的表格中，你修改时会实时重建 URL。
使用方法
- 选择“编码”或“解码”，再选择模式：要放进 URL 的值选“组件”，整个网址选“完整 URL”，application/x-www-form-urlencoded 数据选“表单”。
- 输入或粘贴文本。结果会随输入实时更新；处理列表时请勾选“每行单独处理”。
- 如果解码失败，请阅读提示信息：它会指出出错的位置和有问题的序列。
- 要查看或编辑 URL，把它粘贴到解析器中，修改、添加或删除查询参数，然后复制重建后的 URL。
常见问题
encodeURI 和 encodeURIComponent 有什么区别？
encodeURIComponent 会转义除字母、数字和 - _ . ! ~ * ' ( ) 以外的所有字符，所以适用于 URL 的单个部分，比如可能包含 & 或 = 的查询值。encodeURI 假定你给它的是整个 URL，会保留构成 URL 结构的字符（: / ? # @ & = + $ , ;）不变。对单个值使用 encodeURI 是一个经典 bug：值中的 & 会把它拆成两个参数。
空格应该编码成 %20 还是 +？
两者在不同场合都是正确的。在表单提交的查询字符串（application/x-www-form-urlencoded）中，空格是 +，字面意义的加号必须写成 %2B。在其他所有地方，包括路径和大多数手动拼接的查询字符串中，空格是 %20，+ 表示字面意义的加号。如果服务器在该显示空格的地方显示加号（或者反过来），说明两端对适用哪条规则的理解不一致。
为什么会出现“URI malformed”错误？
要么是 % 后面没有跟两个十六进制数字（例如“100%”或“%zz”），要么是字节构成了无效的 UTF-8，比如单独的 %E9——它在 Latin-1 中是 é，在 UTF-8 中却不是。字面意义的百分号必须写成 %25。本工具会报告确切位置，让你看清是哪种情况。
哪些字符需要进行 URL 编码？
RFC 3986 只允许字母、数字和 - . _ ~ 在任何位置不经编码出现。保留字符（: / ? # [ ] @ ! $ & ' ( ) * + , ; =）作为值的一部分而非结构出现时必须编码。其他所有字符，包括空格、引号、< >、非 ASCII 字母和表情符号，都必须按字符的 UTF-8 字节进行编码。
URL 编码是一种加密吗？
不是。百分号编码是一种没有密钥、可逆的转义方案，任何人都能立即解码。永远不要指望用它在 URL 中隐藏令牌或个人数据。还要记住，URL 会出现在浏览器历史记录、服务器日志和 Referer 头中，所以密钥根本就不应该放在查询字符串里。
编码参考：各模式保留哪些字符
• 组件（encodeURIComponent）：保留 A–Z a–z 0–9 - _ . ! ~ * ' ( )。用于查询值、路径片段，以及任何通过拼接构建的内容。
• 完整 URL（encodeURI）：额外保留 ; , / ? : @ & = + $ #。仅用于清理包含空格或非 ASCII 字符的完整 URL。
• 表单（application/x-www-form-urlencoded）：保留 A–Z a–z 0–9 * - . _，并把空格转为 +。这就是 URLSearchParams.toString() 和 HTML 表单生成的格式。
• RFC 3986 非保留字符集：A–Z a–z 0–9 - . _ ~。最严格的解释；额外编码 ! ' ( ) * 也始终是安全的。
非 ASCII 字符始终按其 UTF-8 字节编码：é 是 %C3%A9，表情符号 🌲 是四个字节 %F0%9F%8C%B2。
双重编码及其他常见 bug
双重编码发生在对已经编码过的字符串再次编码时：%20 会变成 %2520，因为 % 本身被转义成了 %25。如果你在 URL 中看到 %25 后面跟着两个十六进制数字，说明某处编码了两次。解码一次，再检查结果中是否仍有 % 序列。
相反的错误是通过字符串拼接构建 URL 却完全不编码。这样搜索“fish & chips”时，发送的是 q=fish 加上一个名为“ chips”的多余参数。用 URLSearchParams 构建查询字符串，或用 encodeURIComponent 编码每个值，就能避免这两种问题。
最后，对用户输入解码后直接插入 HTML，正是反射型跨站脚本攻击的开端。要先做 HTML 转义，再解码用于显示；HTML 实体编码工具可以处理这一步。
相关免费工具
- UTM 链接生成器 — 生成规范、统一的 UTM 跟踪链接，准确了解哪些广告系列为你带来了客户。
- Base64 编码 / 解码工具 — 把文本或文件编码为 Base64，把图片转成带 CSS 和 <img> 代码片段的 data URI，还能把 Base64 解码回可预览的文件。数据不会离开你的浏览器。
- HTML 实体编码 — 用命名或数字实体对文本进行 HTML 转义，把 & 这类引用解码回字符，并可搜索实体参考表。
- JWT 解码器 — 解码 JWT 的头部和载荷，用通俗语言显示过期时间，验证 HS、RS、PS 和 ES 签名，或签发新令牌。任何数据都不会离开浏览器。