编码

URL 编码解码

粘贴单个参数值、完整 URL，或类似 a=1&b=hello world 的查询字符串，工具会根据上下文选择合适的百分号编码方式。普通文本会被当作一个参数值处理；完整 URL 会保留协议、路径、查询参数和片段结构；Query 模式则会逐个处理参数。表单模式支持较老的加号表示空格约定；严格解码适合 API 校验；宽容解码适合查看已经损坏的日志。所有处理都在浏览器内完成，回调 URL、OAuth state、JWT 参数和私有数据不会被上传。

  • 分别处理参数值、完整 URL 和 Query 参数，避免误把结构字符当作普通内容编码
  • Query 模式可选择同时处理 key 和 value，或只处理 value，以匹配不同后端约定
  • 表单模式支持 application/x-www-form-urlencoded 中 + 表示空格的规则
  • 严格解码会立即报告错误的百分号编码；宽容解码会尽量恢复可读文本
  • 内置完整 URL、表单风格 Query、中文文本和 Emoji 示例，方便粘贴真实数据前先试模式
  • 完全本地处理，回调 URL、签名参数、Webhook 内容和私有字段都只留在浏览器中
工具/URL 编码与解码
等待输入
结果会显示在这里...
编码 · 文本或参数值

文本或参数值模式会把整个输入当作一个值处理，因此问号、& 和等号都会被作为内容编码。

URL 命令

功能简介

URL 编码问题通常不是字符本身造成的，而是把错误的规则用在了错误的上下文里。这个页面会先区分参数值、完整 URL 和 Query 字符串，再使用对应的处理方式。

  1. 01

    三种处理目标

    文本或参数值模式会把整个输入当作一个值来编码。完整 URL 模式会保留协议、主机、路径、查询和片段结构。Query 模式会逐个处理参数。选对目标，是结果稳定的关键。

  2. 02

    Query 模式可只处理 value

    在 Query 模式下，可以同时处理 key 和 value，也可以保持 key 不变、只处理 value。适合服务端要求 key 名保持原样，但 value 必须 URL 安全的情况。

  3. 03

    完整 URL 保留结构

    当你粘贴的是已经拼好的 URL 时，工具只会处理需要编码的部分。协议、主机、路径分隔符、Query 分隔符和 fragment 都会保持完整。

  4. 04

    表单空格模式

    可以在标准百分号编码和表单提交约定之间切换。标准编码会用百分号形式表示空格，而表单数据会用加号表示空格。这个开关会在完整 URL 模式下隐藏，避免破坏 URL 结构。

  5. 05

    严格解码与宽容解码

    严格解码遇到孤立的百分号或不完整字节会失败，适合协议校验。宽容解码会先修复常见损坏片段，再尽量返回可读文本，适合排查日志。

  6. 06

    往返校验

    编码后可以把结果放回输入区，再执行反向解码。这样能快速确认内容在当前模式下是否可以完整还原。

  7. 07

    内联校验状态

    转换成功时，输出区标题会显示成功状态；输入格式无效时会显示错误状态，帮助你区分是数据损坏还是工具行为。

  8. 08

    完全本地处理

    编码、解码、复制和往返校验都在当前浏览器标签页内完成。回调 URL、OAuth state、签名链接、JWT 参数、客户搜索词和私有字段都不会离开设备。

如何使用

五个短步骤。任何控制项变化都会立即重新计算输出。

  1. 01

    在转换模式中选择编码或解码。

  2. 02

    选择处理目标：单个文本值、已经拼好的完整 URL，或一组 Query 参数。

  3. 03

    如果处理 Query 参数，选择同时处理 key 和 value，还是只处理 value。解码时还可以选择严格模式或宽容模式。

  4. 04

    如果数据来自 HTML 表单提交，或来自 + 表示空格的旧系统，请打开表单模式。完整 URL 模式会自动隐藏这个选项。

  5. 05

    当输出状态显示已编码或已解码后，复制结果。需要验证时，可以将输出作为输入，再执行相反转换。

功能说明

同一个字符，在某些位置是普通内容，在另一些位置却是分隔符或结构标记。处理目标会告诉编码器应该如何理解它。

  • 单个参数值、搜索关键词、筛选条件或 slug，请使用文本或参数值。问号、& 和等号会作为内容被编码，避免意外拆分 URL。
  • 输入已经是拼好的完整 URL，只需要处理里面的空格或 Unicode 时，请使用完整 URL。协议、主机、路径分隔符、Query 分隔符和 fragment 标记都会保持有效。
  • 手里是原始 Query 片段时，请使用 Query 参数。每个参数会被单独处理，并且可以选择 key 是否保持不变。
  • 只有在 HTML 表单提交、旧回调系统，或明确约定+ 表示空格的系统中，才打开表单模式。普通 URL 参数通常不需要。
  • 查看被截断、复制损坏、部分编码的日志时，使用宽容解码。它会优先给出可读文本，方便你判断下一步怎么处理。
  • 做协议校验、API 契约测试，或任何无效内容必须立即失败的流程时，使用严格解码。

适合哪些场景

这些都是反复出现的工程任务。同样是选择模式、粘贴内容、复制结果，就能覆盖它们。

  1. OAuth 回调 URL 和 state

    把带有嵌套参数的完整回调 URL 编码后放进授权链接，或从回调里解码 state 值，查看客户端实际发送了什么。

  2. 搜索和筛选 Query 参数

    把用户输入的搜索词、多选筛选条件、分页 cursor、多语言标签编码后，再加入 query string。

  3. API 请求 URL 拼装

    分别编码路径片段（slug、ID、日期）和参数值，拼出 REST URL，避免内容在到达服务端前被破坏。

  4. Webhook 签名排查

    解码从日志里抓到的 signature、state 或 nonce 参数，还原合作方实际发送的内容。

  5. UTM 和追踪链接清理

    解码由广告跳转、短链接和落地页组成的多层追踪链接，逐层查看 UTM 字段，方便归因、归档或排障。

  6. 表单提交排查

    从浏览器开发者工具、API 网关日志或后端访问日志中复制表单内容，解码后查看用户实际提交了什么。

  7. 中文、日文、韩文和 Emoji 参数处理

    一致地编码中文、英文、日文、韩文和 Emoji 参数，减少浏览器、代理和框架之间的差异。

  8. 双重编码救援

    当日志里的文本看起来被编码了不止一次时，可以一层一层解码，直到原始值出现。

  9. 分享预填 URL

    构建预填邮件链接、Google Forms、Slack deep link 或营销分享链接时，先编码消息和参数，再拼入 URL。

  10. JWT 和 SAML 回调检查

    先解码 JWT 或 SAML 回调里的 URL 参数，再把结果交给对应的检查工具做更深入分析。

延伸阅读

当 URL 携带的值又被 Base64 包了一层，例如凭据、不透明 token 或内联图片时，可以先用 Base64 编码解码 做一次往返确认。值如果最终要显示在页面文本、HTML 属性或邮件源码里，再用 HTML 编码解码 检查实体边界。对于嵌在回调 URL 里的 Bearer token 和三段式 JWT，请打开 JWT 检查器 查看 header、claims 和 signature。当任务从一个参数扩展到包含 host、path、Query 和 fragment 的完整 URL 时，可以搭配 URL 工具 使用。

使用建议

大多数 URL 问题来自上下文判断错误，而不是编码规则本身。下面这些习惯可以让结果更可预测。

  • 修改前先判断输入是什么：一个值、完整 URL，还是原始 Query 字符串。这个判断决定使用哪套规则。
  • 单个值用文本或参数值模式；已经拼好的 URL 用完整 URL 模式。不要混用这两个上下文。
  • 如果输入已经包含百分号编码，先解码查看原始值，再重新编码。否则很容易产生双重编码。
  • 只有双方明确遵循表单提交规则时才使用表单模式。普通 URL 参数和大多数 API 通常用标准百分号编码表示空格。
  • 面对真实世界的脏日志，比如截断行、半个字节、复制粘贴破坏，先用宽容解码。值看起来可读后，再切到严格模式重新解码干净版本进行确认。
  • 团队需要明确记录空格、Unicode、数组参数、回调 URL 的约定。前端、移动端和后端在这些细节上漂移，是生产 URL 问题的常见来源。
  • URL 编码只是传输格式，不是安全机制。XSS 防护、token 保护和签名校验都需要各自的安全处理。
  • 上线前做一次往返检查：先编码，把输出作为输入，再解码，确认能回到原始值。

边界与注意事项

清楚边界可以避免误用，也能帮助你判断什么时候该换另一个工具。

  • 这是编码工具，不是加密工具。百分号编码不会隐藏内容，也不会对哈希值或其他数据提供安全保证。
  • 宽容解码是启发式恢复。它能修复常见的孤立百分号，但无法恢复所有损坏的 UTF-8 序列。
  • 工具不会自动判断文本是否被双重编码。应该解码一次还是多次，仍然取决于业务流程。
  • Query 模式假设使用标准的 & 和 = 分隔符。如果你的框架使用分号、嵌套参数或自定义分隔符，请先手动确认规则。
  • 表单模式只处理+ 与空格的差异。它不会完整模拟表单序列化、文件、数组或嵌套对象。
  • 这个页面处理字符串，不处理文件。如果要把文件内容转成百分号编码后上传，请使用专门工具。
  • 底层行为使用浏览器原生 URL 编码和解码能力。某些旧系统使用不同的保留字符集合，结果可能与这些系统存在差异。

常见问题

这里整理了关于处理模式、表单风格空格、双重编码、隐私，以及 URL 编码和其他转义机制差异的实用回答。

什么是百分号编码？

百分号编码会把不能直接出现在 URL 中的字节转换成百分号加两个十六进制数字。它是一种格式约定，让 URL 可以携带空格、Unicode 和保留字符，同时仍然能被解析。

参数值编码和完整 URL 编码有什么区别？

参数值编码会把问号、&、等号、斜杠、井号都当作内容处理。完整 URL 编码会保留这些结构字符，让结果仍然是可解析的 URL。这个工具通过处理目标把两种情况分开。

什么时候 + 表示空格？

只有在 HTML 表单提交，以及遵循这种旧约定的 Query 字符串中，+ 才表示空格。遇到这些情况请打开表单模式。在其他 URL 上下文里，+ 只是普通加号。

为什么 URL 看起来被双重编码了？

常见原因是本来已经编码过的字符串又被编码了一次。请按照业务流程一层一层解码，直到原始值可见。

什么时候用严格解码，什么时候用宽容解码？

协议校验和 API 契约测试中，无效输入应立即失败，请使用严格模式。日志检查和事故分析中，你通常先需要从部分损坏的内容里看到可读文本，请使用宽容模式。

URL 编码能防止 XSS 吗？

不能。URL 编码只是让字符串适合放进 URL。XSS 防护需要针对最终渲染位置做输出编码，例如 HTML、JavaScript 或属性上下文。

为什么完整 URL 模式下隐藏表单开关？

因为加号在 URL 路径、Query 和 fragment 中都是合法字符。把完整 URL 里的空格都改成加号，可能会破坏 Query 之外的部分。这个开关只在参数值和 Query 上下文中有意义。

Query 模式如何处理带问号的 URL？

如果输入可以识别为完整 URL，Query 模式只会处理其中的 query 部分，然后重建 URL。协议、主机、路径和 fragment 会保持不变。

我的数据会离开浏览器吗？

不会。编码、解码、校验、复制和往返检查都在当前浏览器标签页中运行。回调 URL、OAuth state、JWT URL 和其他私有内容不会被上传。

可以粘贴多长的 URL？

几千个字符通常很轻松；几万个字符也能处理，但会慢一些。对于多 MB 的 Data URL 或大段编码内容，更适合使用流式或文件感知工具。

页面支持 IDN 域名吗？

浏览器运行时支持时，原生 URL 解析器会处理 IDN 域名。如果需要专门做 Punycode 和 Unicode 主机名转换，请使用专用 IDN 工具。这个页面主要关注路径、Query 和参数值编码。

为什么 URL 在浏览器地址栏能用，但在 curl 或 Postman 里失败？

浏览器地址栏通常会容忍原始空格和 Unicode，然后自动帮你编码。curl 和 Postman 更接近按你给出的字节发送。从代码或 API 工具发 URL 前，请显式编码。

更多相关工具

可以继续在编码分类里处理相邻任务：用 Base64 检查认证头和 token，查看回调 URL 里的 JWT，或在二维码和条形码工具之间切换。