URL 解码
将 URL 编码字符串还原为原始文本（decodeURIComponent）。
点击示例卡片自动填入输入框
什么是 URL 解码？
URL 解码是 URL 编码的逆过程，将 %XX 百分号序列还原为原始字符。在调试 API、分析日志、处理爬虫数据时非常实用。
本工具使用浏览器原生的 decodeURIComponent 函数，正确处理 UTF-8 多字节序列，支持中文等非 ASCII 字符的还原。
使用步骤
- 将需要解码的 URL 编码字符串粘贴到左侧输入框
- 点击「解码」按钮，右侧显示还原后的原始文本
- 点击「复制结果」将解码后的内容复制到剪贴板
典型生产场景
Nginx / Apache / Traefik 等反向代理的 access log 中，请求 URI 通常以编码状态记录。解码后能直观看到用户实际访问的路径和参数，快速定位异常流量或 404 的来源。
认证服务器（Auth0 / Keycloak / 企业微信）返回的 redirect_uri 常包含多层编码的 state 和 code 参数。逐层解码后验证参数完整性，排查 token 换取失败或 CSRF 校验不通过的问题。
从 HTML 页面、JS 脚本或 API 响应中抓取到的外链常处于编码状态。解码后还原真实 URL，方便去重、分类和后续入库。注意区分页面中本身就编码的 URL 和爬虫框架自动编码的。
签名计算涉及对参数先编码再哈希。将请求中的 encoded string 解码后，逐段对比 Hash 原串，快速定位参数值与签名预期不符的位置。常见于排序参数时 compare 逻辑与签名文档不一致。
历史数据中混有编码和未编码的 URL，统一展示时风格不一致。批量解码后统一格式，但需注意保留有意编码的 URL（如邮件中预填的 mailto 链接），不可一刀切解码。
常见错误模式
- 对非 UTF-8 编码的 URL 调用 decodeURIComponent — GBK 编码的中文使用不同的字节序列（如 %D6%D0 而非 %E4%B8%AD），decodeURIComponent 按 UTF-8 解释会出现乱码。正确做法：识别编码来源的 charset，对非 UTF-8 数据用 TextDecoder 或后端工具转换。
- 对整个 URL 使用 decodeURIComponent — 会连 :// ? & = 等结构字符一并解码，导致 URL 失去结构。如果需要可读性，应分段解码：path 段用 decodeURI，参数值用 decodeURIComponent。
- 忽略截断的 % 序列导致的解码异常 — 输入末尾的 %E5 或缺少两个十六进制字符的 %X 会直接抛出 URIError。生产代码中应先用正则 %[0-9A-Fa-f] 匹配并校验，或在 try-catch 中返回友好错误。
- 未区分 + 和 %20 — 表单编码（URLSearchParams）将 + 解码为空格，但 decodeURIComponent 不会。如果你从 form POST 或旧系统获取的 URL 编码字符串中包含 +，解码前先做 .replace(/+/g, '%20')。
深度专题：URL 编解码的工程细节
encodeURI / encodeURIComponent / 旧 escape 三者不可互换：encodeURI 把整段 URL 视为字符串编码，保留 :/?#&= 等结构字符；encodeURIComponent 把输入视为一个组件值，连 :/?#&= 也一并编码。错把 encodeURI 用在 query value 上，& = 会留下导致下游参数被拆错；错把 encodeURIComponent 用在完整 URL 上，整个 URL 失去结构。一般规则：永远只对单个组件（一个 param value 或 path segment）用 encodeURIComponent；完整 URL 交给 encodeURI 或 URL / URLSearchParams API。
浏览器 encodeURIComponent 实现与 RFC 3986 有偏差：encodeURIComponent 不会编码 ! ' ( ) * 这五个字符，而 RFC 3986 的严格百分号编码（如 OAuth 1.0a 签名基串）要求把它们编码为 %21 %27 %28 %29 %2A。严格签名场景需要后处理：encodeURIComponent(s).replace(/[!'()*]/g, c => "%" + c.charCodeAt(0).toString(16).toUpperCase())。decodeURIComponent 对这些百分号化字符可正常解码，所以解码侧不必特殊处理。
双重编码识别：如果 decodeURIComponent 一次后字符串里仍含 %XX 序列，多半是双重编码（CDN 转发、邮件追踪链接、网关代理的常见情形）。生产代码的处理范式是：循环 decodeURIComponent 直到结果与上一轮相同（设置 ≤ 3 层硬上限防恶意构造）。但要警惕「合法 % 字符」——如果原始数据本身就含 %（如「100%」「3%5」），无限循环解码会破坏数据。务实做法：明确知道传输管道有几层编码就解几次，不要无限循环。
URL 不同组件编码策略不同：path segment 内允许 / 不编码（如 /api/v1/users/123），但 query value 内必须把 & = 编码（否则下一个解析器会拆错参数）；fragment（# 之后）的字符集更宽，浏览器不做进一步编码。生产代码推荐用 URL 对象拆分后再分别处理：new URL(rawUrl).searchParams.get(key) 自动完成解码，避免手工分段切错。