URL 编码解码工具
快速进行 URL 编码和解码，支持多种编码模式
选择转换方式
什么是 URL 编码？
URL 编码（也称为百分号编码）是一种将字符转换为可在 URL 中安全传输的格式的机制。因为 URL 只能包含 ASCII 字符集中的特定字符，所以其他字符（如中文、空格、特殊符号等）需要被编码为 %XX 格式，其中 XX 是字符的十六进制值。 例如：空格会被编码为 %20，中文字符「你」会被编码为 %E4%BD%A0。 实际开发中还需要区分整段 URL、查询参数和路径片段的编码方式；例如空格、斜杠、问号、等号在不同位置含义不同，错误编码可能导致参数丢失或路由解析异常。
如何使用
如何使用
- 在输入框输入或粘贴要编码/解码的文本
- 选择编码方法：encodeURIComponent 或 encodeURI
- 结果自动生成，一键复制或交换输入输出
- 解码时，请选择对应的解码方法
URL 上下文
- 对查询值和路径段使用组件编码；使用错误的函数编码整个 URL 可能会破坏分隔符（如 /、? 和 &）。
- 解码时，请检查双重编码，例如 %2520，这表示百分号本身被再次编码。
使用场景
技术原理
URL 编码（百分号编码）由 RFC 3986 §2.1 定义，将字符转换为 %XX 格式，其中 XX 是 UTF-8 字节值的两位大写十六进制表示。RFC 定义了两类字符：非保留字符（A-Z a-z 0-9 - _ . ~）永不编码，保留字符（gen-delims : / ? # [ ] @ 和 sub-delims ! $ & ' ( ) * + , ; =）的编码取决于上下文——它们在某些 URL 组件中具有结构含义，但在其他位置是字面数据。 JavaScript 提供两个作用范围不同的内置函数。encodeURIComponent() 编码除 A-Z a-z 0-9 - _ . ! ~ * ' ( ) 之外的所有字符——这是编码单个查询参数值、路径段和 fragment 标识符的正确选择。encodeURI() 额外保留结构字符 : / ? # [ ] @ ! $ & ' ( ) * + , ; =，设计用于编码整个 URI 同时保持其语法结构完整。关键区别在于 encodeURIComponent() 编码 / 和 &，如果应用于整个字符串会破坏 URL，而 encodeURI() 保留它们。 空格处理是最常见的互操作性陷阱。RFC 3986 规定 %20 作为空格字符（U+0020）的规范百分号编码。然而 application/x-www-form-urlencoded MIME 类型（自 HTML 4.01 起用于 HTML 表单提交）将空格编码为 +。两者不可互换：期望 %20 的服务器会将 + 视为字面量，期望 + 的服务器会将 %20 视为字面百分号后跟 20。本工具使用 encodeURIComponent() 生成 %20，符合 RFC 3986。解码 x-www-form-urlencoded 载荷（来自 POST 请求体或旧版中间件解析的查询字符串）的用户应注意这一差异。 多字节字符处理是自动的，但值得了解：输入字符串首先编码为 UTF-8 字节，然后每个字节单独进行百分号编码。CJK 字符如「你」（U+4F60）占用 3 个 UTF-8 字节（E4 BD A0），生成 %E4%BD%A0。如果服务器使用 GBK 等不同字符集解析，同一字符编码为 %C4%E3（2 字节），除非双方约定 UTF-8 否则解码结果会乱码。双重编码是另一个常见 bug：%2520 表示字面百分号（%25）后跟 20，说明输入已经过百分号编码又被编码了一次。解码模式会捕获畸形序列（不完整的 %XX）并暴露错误，而非静默产生乱码。
- encodeURIComponent 与 encodeURI 的区别：encodeURIComponent 编码 / ? & #，适用于查询值、路径段和 fragment；encodeURI 保留这些结构字符，适用于完整 URL——用错函数是最常见的 URL 编码 bug。
- RFC 3986 保留字符集：gen-delims（: / ? # [ ] @）承载 URL 语法；sub-delims（! $ & ' ( ) * + , ; =）根据 URL 组件不同可能是分隔符或数据——上下文决定保留字符是否需要百分号编码。
- 空格编码：RFC 3986 规范形式为 %20（由 encodeURIComponent 生成）；application/x-www-form-urlencoded 使用 +（HTML 表单默认）——两者语义不兼容，混用会破坏服务端解析器。
- UTF-8 多字节编码：「你」（U+4F60）→ UTF-8 字节 E4 BD A0 → %E4%BD%A0（3 个百分号编码八位组）；同一字符在 GBK 下 → %C4%E3（2 个八位组）——客户端和服务器之间的字符集一致性对非 ASCII 文本是必需的。
- 双重编码检测：%2520 先解码为 %20 再解码为空格——解码模式的输出会揭示这种模式；畸形序列如 %ZZ 或 %2（不完整）会被捕获并报告为错误。
- IRI（RFC 3987）：国际化资源标识符允许 URL 中直接使用 Unicode 字符；浏览器在地址栏显示解码形式，但在传输时发送百分号编码的 UTF-8 形式——工具的编码模式显示实际通过 HTTP 传输的内容。
- decodeURIComponent 错误处理：传入包含不完整百分号序列（% 后跟少于 2 个十六进制数字）的字符串会抛出 URIError——工具用 try/catch 包裹调用并显示错误消息，而非静默返回空字符串。
示例
中文字符编码（UTF-8 百分号编码）
输入： 你好世界（4 个 CJK 字符，12 个 UTF-8 字节）
输出： %E4%BD%A0%E5%A5%BD%E4%B8%96%E7%95%8C
每个 UTF-8 字节（E4、BD、A0……）会变成 %XX
RFC: RFC 3986 第 2.1 节定义了 URI 的百分号编码
用途： 查询参数、路径片段、表单提交查询字符串分隔符的编码
输入： name=张三&age=20
输出： name%3D%E5%BC%A0%E4%B8%89%26age%3D20
%3D 编码 '='（键值之间的分隔符）
%26 编码 '&'（参数之间的分隔符）
RFC: RFC 3986 第 3.4 节定义了 query 部分的保留字符编码完整 URL（部分编码）
输入： https://example.com/search?q=你好&type=web
输出： https://example.com/search?q=%E4%BD%A0%E5%A5%BD&type=web
注意： scheme、host 以及已有的分隔符不会被编码
只有非 ASCII 的查询值会做百分号编码
RFC: RFC 3986 第 3 节定义了分层 URI 各组成部分空格字符的两种编码约定
路径片段： %20（符合 RFC 3986）
查询字符串：+（HTML 表单的历史约定）
示例：/search for me -> /search%20for%20me
示例：q=hello world -> q=hello+world
两者解码结果相同；encodeURI 用 %20，encodeURIComponent 在某些实现里路径用 %20、查询用 +常见问题
URL 编码到底做了什么？
把 URL 中的不安全字符替换为 % 转义序列：空格 → %20，& → %26，# → %23 等等。RFC 3986 规定了哪些字符是安全的（字母数字加 -、_、.、~），哪些必须编码。浏览器、服务器和 HTTP 库都会在适当的边界上应用或期望 URL 编码。
encodeURI 和 encodeURIComponent 有什么区别？
encodeURI 会保留 URL 语法字符（: / ? # & =），它面向的是整个 URL；encodeURIComponent 会把这些字符也编码，它面向的是单个参数值。页面同时提供两种模式：查询参数用组件编码，整个 URL 用 URI 编码。
为什么空格有时变成 %20，有时变成 +？
%20 是 URI 标准。+ 是 application/x-www-form-urlencoded MIME 类型（HTML 表单提交所用）的遗留约定。多数服务器会把两者视为等价，但严格来说并不相同——现代 URL 中请使用 %20。
Unicode 字符需要编码吗？
RFC 3986 只允许 ASCII；非 ASCII 字符必须先按 UTF-8 编码再做百分号转义（中 → %E4%B8%AD）。现代浏览器在地址栏会显示 Unicode 形式，但实际发送的是编码后的形式。页面会自动完成 UTF-8 编码这一步。
哪些字符永远不该被编码？
RFC 3986 中的非保留字符：A-Z、a-z、0-9、-、_、.、~。对它们做编码在技术上是允许的，但会得到不同的 URL 字符串；服务器在标准化规则不同的情况下，可能把「a」和「%61」视为等价，也可能视为不同。
为什么我解码后的 URL 里有奇怪的字符？
很可能是被双重编码了：%2520 解一次得到 %20，再解一次才是空格——意味着有人对 URL 编码了两次。这种情况下要解码两次。某些服务器会自动双重编码，请检查你客户端的编码行为。
编码是在本地完成的吗？
是的。encodeURIComponent 和 decodeURIComponent 都在你的浏览器中运行，URL 不会被上传。