关于 URL 编码/解码
把一个字符串安全地放进 URL，是拼接接口地址、构造带参数的分享链接、把中文搜索词送进查询串时绕不开的一步。URL 只允许一组有限的 ASCII 字符直接出现，空格、中文、斜杠、问号、井号都有特殊含义，直接拼接会让服务端解析出完全不同的路径或参数。 编码原理是把不允许直接出现的字符替换成百分号加两位十六进制（即 UTF-8 字节的十六进制表示）。关键往往不在「要不要编码」，而在「编哪一段」：整条地址里的结构字符（协议冒号、斜杠、问号、井号、与号、等号）必须保持原样，否则地址本身就被破坏；而单个参数的值里，这些字符反而必须被编码。因此工具通常提供两种模式，一种是用于整条 URL 的精简编码，一种是用于单个参数值的完整编码，用错模式是最常见的错误来源。 使用要点：如果参数值本身就是一个 URL（例如跳转地址、回调地址），它必须被完整编码后再作为参数值拼接，常见做法是编码后仍能被服务端正确解码回原始地址，这一层嵌套最容易出错，建议编码后立刻解码验证一次往返是否一致。空格的处理要特别留意：在查询串里它既可以是加号也可以是百分号二十，两种表示在部分框架下行为不同，跨语言对接时建议统一使用百分号二十。中文应当按 UTF-8 编码，不要沿用 GBK，同一个字在两种编码下产生的字节完全不同。 边界与限制：编码不可逆地丢失了「原文里到底写了什么」的部分信息——一个本来就写成百分号二十的字符串，解码后会变成空格，再编码也不一定回到原来的样子，因此编码结果需要解码验证时要注意这种歧义。另外某些字符在路径与查询串里的合法性不同（例如加号在路径里是字面加号，在查询串里表示空格），跨段拼接时应逐段处理而不是整体编码。还有一点容易被忽视：编码只解决「能不能放进去」，不解决「服务端是否可信」，把用户输入直接拼进地址之前仍应做白名单校验。 数据与隐私：编码的内容可能是带签名的回调地址、含用户标识的分享链接或内网服务地址。本工具在浏览器内完成编码与解码，不发出请求，也不会把内容记录到任何地方；处理带签名的链接时，建议在离线状态或网络面板可见的情况下操作。
把编码本身当成一次「翻译」而不是「加密」来看待，能避免不少误用：编码结果完全可逆，任何人拿到都能还原，因此它既不能保护隐私，也不能替代签名。在多层嵌套的参数里（例如把一个带参数的地址作为参数传给另一个地址），常见做法是对内层整体编码一次、外层再编码一次，此时务必记录编码层数，因为少编码一层会导致内层参数被外层解析吞掉，这类故障表现为「部分参数神秘消失」。
实现原理
编码把不允许直接出现的字符替换成百分号加该字符 UTF-8 字节的十六进制。要点不在「要不要编码」而在「编哪一段」：整条地址里的结构字符（冒号、斜杠、问号、与号）必须保持原样，否则地址本身被破坏；而单个参数值里这些字符反而必须编码。空格在查询串里也可以是加号，跨系统时应统一用百分号二十。
a&b=c d整条编码：a&b=c%20d｜参数值编码：a%26b%3Dc%20d使用方法
- 打开「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 的参数要做二次编码。逐段还原对比后，通常能立刻定位是哪一层出了问题。
encodeURI 和 encodeURIComponent 该用哪个？
整段 URL 用 encodeURI（保留 ://?& 等结构字符），参数值用 encodeURIComponent（把 & = ? 也编码，防止破坏 URL 结构）。最常见的 bug 是整段 URL 误用 encodeURIComponent，把协议和分隔符全转义掉。