URL编码/解码
编码和解码URL字符串
使用工具
介绍
URL编码/解码工具将URL中的特殊字符转换为其百分比编码等价物，反之亦然。对于处理包含特殊字符、空格和非ASCII字符的URL以确保正确的URL编码和解码至关重要。
使用方法
- 选择转换方向：编码或解码
- 在输入框中粘贴您的URL或编码字符串
- 点击"转换"按钮进行编码或解码
- 从输出框复制结果
- 使用"交换"快速切换编码/解码模式
使用场景
- 对包含特殊字符的URL参数进行编码
- 解码来自Web浏览器的编码URL
- 对URL中的空格和非ASCII字符进行编码
- 处理包含特殊字符的URL查询字符串
提示
- 空格编码为%20或+
- 特殊字符如&、=、?被百分比编码
- 非ASCII字符被编码为UTF-8字节
- URL编码确保URL的安全传输
- 常见编码：%3D表示=，%26表示&，%3F表示?
URL编码/解码 是什么？
URL 编码（又称百分号编码）会把 URL 中不允许出现的字符——空格、非 ASCII 字母、`?`、`&`、`=`、`#` 等保留符号——转换成百分号加两位十六进制数的形式（`%20`、`%E2%9C%93`、`%3F`）。正是这种机制让 `café & restaurant` 这样的搜索查询能够以 `caf%C3%A9%20%26%20restaurant` 的形式作为单个 URL 参数安全传输，而不会破坏解析器。互相竞争的标准——RFC 3986（URL）、`application/x-www-form-urlencoded`（HTML 表单）以及 JavaScript 中的 `encodeURIComponent`——对保留字符集的编码范围略有差异，因此转换器必须让用户自行选择变体。编码错误是深度链接失效、分析标签误路由以及 OAuth 回调静默失败的前十大原因之一，因此能够并排展示编码与解码结果的转换器，是 Web 开发者、QA 工程师和 API 集成者每天都要用到的工具。
常见用例
调试 OAuth 与 SAML 回调
OAuth 提供商会通过形如 `?code=abc&state=xyz` 的重定向 URL 返回令牌。如果 state 参数含有 `+` 或 `=`（在使用 base64 编码的 nonce 时很常见），错误解码的回调会在错误的字符处拆分值并导致认证失败。借助转换器双向测试：先对期望的回调 URL 进行编码，再对提供商实际返回的内容进行解码，即可定位不一致发生在哪里。
为 API 构建查询字符串
在构造带有多个过滤条件的 REST API 调用（`?q=laptop&category=electronics&price_max=999`）时，包含空格或特殊字符的值必须逐段编码。转换器会显示每个参数的安全形式，因此对 `café mug (blue)` 的搜索会变成 `caf%C3%A9%20mug%20%28blue%29`，API 收到的正是你想要的内容，而不是 400 错误。
邮件与短信链接追踪
营销平台（Mailchimp、Braze、Twilio）会把目标 URL 包裹在追踪重定向里，这就需要进行双重编码：内层 URL 必须先编码一次，再作为 `?u=` 参数放置。如果忘记第二次编码，内层 URL 中的 `&` 就会被当作外层查询字符串的分隔符来解析，从而破坏重定向。
代码示例
encodeURIComponent 与 encodeURI 的区别
`encodeURIComponent` 用于单个参数值——它会转义 `&`、`=`、`?`、`#`，使它们不会被误认为 URL 的结构部分。`encodeURI` 用于整条 URL——它会保留这些结构性字符，因为它们本身就是 URL 的一部分。把两者混用是 JavaScript 应用中查询字符串畸形的首要原因。
// encodeURIComponent: 对以下字符以外的所有字符进行编码
// A-Z, a-z, 0-9, - _ . ! ~ * ' ( )
// 用于查询参数的"值"
const q = encodeURIComponent('café & restaurant?');
// -> "caf%C3%A9%20%26%20restaurant%3F"
// encodeURI: 保留 URL 的结构性保留字符
// 用于整条 URL
const url = encodeURI('https://example.com/search?q=café');
// -> "https://example.com/search?q=caf%C3%A9"
// (保留 ?q=，只对 café 编码)
// 错误写法：对参数值使用 encodeURI
// & 和 = 不会被转义，从而破坏查询字符串追踪重定向的双重编码
当 URL 本身作为另一个 URL 的参数值时，内层 URL 中所有结构性字符（`:`、`/`、`?`、`&`、`=`）都必须进行百分号编码，以免外层解析器把它们当作结构。忘记这点的后果是隐蔽的：链接仍能打开，但它指向错误的目的地，因为内层 URL 的一部分被吸进了外层查询字符串。
目标 URL:
https://shop.com/products?cat=electronics&sort=price
包裹在追踪重定向中（必须先编码一次）:
?u=https%3A%2F%2Fshop.com%2Fproducts%3Fcat%3Delectronics%26sort%3Dprice
如果忘记编码内层 URL:
?u=https://shop.com/products?cat=electronics&sort=price
// 解析器会看到两个参数（u 和 sort），而不是一个
// => 重定向会指向 https://shop.com/products?cat=electronics
// （sort=price 丢失，被当作外层查询参数处理）最佳实践
- ✓对单个查询参数值使用 `encodeURIComponent`，仅在整条 URL 上使用 `encodeURI`--切勿混用。
- ✓当 URL 本身作为参数值时，在放入外层 URL 之前先编码一次；忘记这点会让内层 URL 在第一个 `&` 处被静默截断。
- ✓测试往返安全性：先对一个值编码，再对结果解码，确认能得到原值--任何不一致都意味着字符集问题（UTF-8 与 Latin-1）。
- ✓注意 `+` 在 `application/x-www-form-urlencoded`（表单体）中表示空格，但在路径段中表示字面量 `+`--URL 中的空格请使用 `%20`。
- ✓对非 ASCII 字符，务必先以 UTF-8 编码再对字节进行百分号编码--绝不要使用 Latin-1，否则会损坏 emoji 和 CJK 字符。
常见错误
- ✗对参数值使用 `encodeURI`，导致 `&`、`=`、`?` 未被转义，破坏查询字符串。
- ✗当 URL 本身作为查询参数时忘记双重编码，导致内层 URL 在第一个 `&` 处被截断。
- ✗在 URL 路径中把 `+` 当作空格（`+` 只在表单体中才是空格），导致本应是空格的位置出现字面加号。
- ✗用 Latin-1 而非 UTF-8 编码，导致 emoji 和 CJK 字符损坏成 `?` 或 `é` 之类的乱码。
- ✗对值进行两次解码（框架解码一次、手动解码一次），`%2520` 会先变成 `%20`，再变成字面空格--这会破坏任何原本合法包含 `%20` 的 URL。
相关搜索
推荐工具
常见问题
When should I URL-encode a string?
Encode query parameter values that contain spaces, non-ASCII characters, or reserved symbols such as &, =, or #.
Is encoding the same as escaping HTML?
No. URL encoding is for URLs and query strings. HTML escaping is for markup safety and uses a different set of replacements.