URL 编码器 / 解码器

使用方法

选择“编码”或“解码”，然后粘贴你的文本或 URL。默认情况下，它会对单个值进行编码（转义 & = ? / 等字符）。打开“完整 URI”可以保持 URL 结构完整，只转义不安全的字符。点击复制即可获取结果。 URL 编码，也称为百分号编码，是让文本可以安全地放入 URL 或查询字符串中的标准方法。任何不在一小部分保留和非保留 ASCII 字符范围内的字符，都会被替换为一个百分号加上代表该字符字节值的两位十六进制数字——空格变成 %20，&符号变成 %26，依此类推。 URL 只允许使用有限的一组 ASCII 字符：字母、数字，以及少数几个标点符号，如 - _ . ~。其他所有字符，包括空格、引号和非英文字母，在能够安全地存在于 URL 中之前都必须被转义。如果不进行编码，浏览器或服务器可能会误判 URL 一部分的结束位置和另一部分的开始位置——值中未转义的 & 看起来像是一个新查询参数的开始，未转义的 ? 看起来像是查询字符串本身的开始，而未转义的 # 会被当作片段标识符处理，从而悄无声息地截断其后的所有内容。 以短语“café & bar”作为示例查询值。空格字符会变成 %20，&符号会变成 %26，带重音符号的 é（在 UTF-8 中占两个字节）会变成 %C3%A9。经过百分号编码后，该短语变为 caf%C3%A9%20%26%20bar。解码则是相反的过程：每个 %XX 都会被读取为一个 UTF-8 字节，并重新组合成原始字符，因此解码该字符串会得到与最初完全相同的 café & bar。 编码整个 URL 和编码单个查询字符串值是两项不同的工作。完整 URI 编码会转义不安全的字符，但会刻意保留 URL 的结构字符——/ : ? & = #——不做改动，因为移除它们会破坏 URL 本身的语法。组件编码（此处的默认方式）则会同时转义这些字符，因为插入查询字符串的值绝不应该引入一个多余的 & 或 =，让服务器误认为是一个新的参数。 百分号编码在日常 Web 开发中随处可见：根据用户输入构建查询参数、分享包含搜索词或筛选条件的链接、拼接 API 请求 URL、通过 GET 提交表单数据，以及为营销链接构建 UTM 参数。它也是解决 decodeURIComponent 抛出的经典“格式错误的 URI”（malformed URI）错误的方法——该错误意味着待解码的字符串中包含一个 % 后面没有跟随两个有效的十六进制数字，通常是因为编码有误或被编码了两次。

常见问题

编码组件和编码完整 URI 有什么区别？

组件编码（默认方式）会转义 & = ? / 等保留字符，因此适合单个查询值。完整 URI 编码会保留这些字符，因此适合整个 URL。

它能处理非英文字符吗？

可以。文本会以 UTF-8 进行百分号编码，因此重音符号、表情符号和中日韩（CJK）字符都能正确编码和解码。

如果我粘贴了无效的编码文本会怎样？

如果百分号转义格式有误（比如单独出现的 %），解码会显示错误提示，而不是产生乱码。

为什么空格有时会变成 %20，有时又会变成 +？

两者都代表空格，但适用于不同场景。百分号编码（RFC 3986）始终使用 %20，这也是本工具生成的结果。+ 字符是来自较旧的 application/x-www-form-urlencoded 格式（用于 HTML 表单提交）的历史惯例，在该格式中 + 表示空格，而真正的加号本身必须编码为 %2B。