关于 URL 编码/解码
URL 编码与解码工具对查询参数、路径片段做百分号编码，把空格、中文与保留字符转成安全的传输格式，也支持反向解码还原可读文本。粘贴含特殊符号的 URL 即时得到编码结果，避免手工转义出错导致接口 400。所有处理在浏览器本地完成，数据不上传，适合处理含中文或符号的链接。无论是拼接接口请求、写前端路由，还是排查编码导致的乱码，都能快速核对与还原。结合本站的 URL 解析器，还能进一步把编码后的地址拆成结构与参数逐段检查。确认每一段都被正确编码且没有被重复转义，能少踩很多联调中的坑；处理在本地完成数据不上传，适合处理含中文或符号的链接，无论是拼接接口请求、写前端路由还是排查编码导致的乱码都能快速核对与还原，配合本站 URL 解析器还能逐段检查结构与参数。
使用方法
- 打开「URL 编码/解码」
- 选择源格式与目标格式
- 根据需要调整输出选项
- 点击「转换」按钮，结果实时显示
- 复制或导出结果
使用场景
- 查询参数构造 — 把用户输入（中文、特殊字符）拼接到 URL 时必须先编码，否则后端解析出错。
- 调试 GET 请求 — 从浏览器 Network 面板复制的 URL 编码后看不出原文，本工具可还原。
- 处理特殊文件名 — 上传带空格、中文的文件名时，HTTP 路径里需要编码后才能正确路由。
- OAuth 回调 URL — redirect_uri 参数本身是 URL，作为查询参数时需要二次编码。
- 邮件链接 — 在 mailto: 链接里塞预填的主题或正文，特殊字符必须 URL 编码。
常见问题
URL 编码和 HTML 实体编码有什么区别？
完全不同。URL 编码用 %XX 表示字节（如 空格 → %20），HTML 实体编码用 & 加名字（如 < → <）。前者用于 URL，后者用于 HTML 正文。
为什么空格有时编码成 +，有时是 %20？
application/x-www-form-urlencoded（表单提交）用 + 表示空格，URL 路径和大多数现代场景用 %20。本工具默认 %20。
需要编码哪些字符？
RFC 3986 定义的"非保留字符"（A-Z、a-z、0-9、- _ . ~）不用编码，其他都建议编码。但 ?#&= 在不同位置含义不同——查询参数里要编码，作为分隔符不要。
编码两次会怎样？
会出现 %25XX 这种"编码的百分号"，解码一次只解一层。这是后端最常见的 bug——确认前端编码一次即可，别叠加。
URL 里能直接放中文吗？
现代浏览器地址栏显示中文，但底层会自动编码为 UTF-8 字节再 %XX。在代码里手动构造 URL 时仍需主动编码。
encodeURI 和 encodeURIComponent 有什么区别？
encodeURI 会保留 : / ? # & = 等 URI 分隔字符不转义，适合编码整个 URL 本身；encodeURIComponent 会连这些分隔符一起转义，适合编码查询参数的值。最常见的排错点就是弄反：用 encodeURI 编参数值，会让其中的 & 或 = 变成参数分隔符，导致后端拆出的字段错乱返回 400；反之用 encodeURIComponent 编整个 URL，则会破坏协议头。构造参数时对每个键值分别用 encodeURIComponent，再用 & 拼接，是最稳的做法。
为什么后端收到的参数是乱码或返回 400？
通常有两种原因：一是编码/解码字符集不一致，前端按 UTF-8 编码，后端却按 GBK 或 ISO-8859-1 解码，中文就变成乱码；二是参数嵌套 URL 时只编码了一层或漏编码，导致 redirect_uri 这类值中的 & 和 = 被当成新参数。排错步骤：先把前端发出去的真实 URL 从浏览器 Network 面板复制，用本工具解码还原原文核对；再确认前后端都统一用 UTF-8；嵌套 URL 的参数要做二次编码。逐段还原对比后，通常能立刻定位是哪一层出了问题。