URL 编码与解码完整指南 | DevTools.at

什么是 URL 编码?

URL 编码是将不安全或特殊字符转换为 URL 中可以安全使用的格式的过程。URL 最初设计为仅使用有限的 ASCII 字符集:字母 (A-Z、a-z)、数字 (0-9) 和少数特殊字符 (-、_、.、~)。超出此集合的任何内容——包括空格、非英文字符和保留字符——都必须进行编码。编码机制很简单:特殊字符被百分号 (%) 后跟其 UTF-8 编码的两个十六进制数字所替换。例如,空格字符变为 %20,问号变为 %3F,汉字"中"变为 %E4%B8%AD。这种编码确保 URL 在通过 Internet 传输时保持有效且明确。为什么需要编码?URL 中的某些字符具有特殊含义。问号 (?) 表示查询字符串的开始,与号 (&) 分隔参数,等号 (=) 分隔键和值,哈希 (#) 指示片段。如果您想在 URL 中按字面意思使用这些字符——比如在搜索查询中——您必须对它们进行编码,否则它们将被误解为 URL 结构的一部分。 URL 编码还处理国际化。虽然英语 URL 可以直接使用 ASCII 字符,但包含中文、阿拉伯文、西里尔文或任何其他非 ASCII 字符的 URL 必须进行编码。例如,搜索"北京"将编码为 %E5%8C%97%E4%BA%AC。这允许全球用户使用他们自己的语言,同时保持与仅支持 ASCII 的系统的兼容性。 URL 编码不同于 HTML 编码或 Base64 编码。HTML 编码 (< 代替 <) 用于 HTML 文档中的特殊字符。Base64 编码将二进制数据转换为文本。URL 编码专门用于确保 URL 有效且明确。虽然所有三者都涉及字符转换,但它们服务于不同的目的并使用不同的机制。常见的误解是所有非字母数字字符都需要编码。实际上,某些字符在 URL 中是明确允许的:破折号 (-)、下划线 (_)、句点 (.)、波浪号 (~) 可以在不编码的情况下使用。然而,保留字符(: / ? # [ ] @ ! $ & ' ( ) * + , ; =)根据它们在 URL 中的位置具有特殊含义,并且通常在用于数据而不是结构时需要编码。

何时使用 URL 编码

理解何时应用 URL 编码对于防止破坏的 URL 和安全漏洞至关重要。以下是需要 URL 编码的最常见场景。查询字符串参数是 URL 编码的最常见用例。当您向 URL 添加搜索词、过滤器或其他参数时,这些值经常包含空格、标点符号或特殊字符。例如,搜索"coffee & tea"变为 ?search=coffee%20%26%20tea。如果没有编码,与号 (&) 将被误解为参数分隔符,从而中断查询。表单提交自动应用 URL 编码。当用户提交带有 GET 方法的 HTML 表单时,浏览器会对表单数据进行 URL 编码并将其附加到 URL。这就是为什么在提交带有空格的搜索表单后,您会在 URL 栏中看到 %20。然而,当您以编程方式构建 URL 时,您必须手动应用编码。 API 请求经常需要 URL 编码。当您向 REST API 发送参数时——特别是在 URL 路径或查询字符串中——任何用户生成的内容都必须进行编码。例如,如果用户的用户名是"[email protected]",对 /api/users/[email protected] 的 API 调用必须编码 @ 符号:/api/users/user%40example.com。重定向 URL 需要特别小心。当您将 URL 作为参数传递给重定向端点时(如 /login?redirect=/dashboard?tab=settings),整个重定向 URL 必须进行编码:/login?redirect=%2Fdashboard%3Ftab%3Dsettings。这防止嵌入的 URL 的特殊字符与外部 URL 的结构冲突。文件名和路径组件有时需要编码,特别是如果它们包含空格或特殊字符。文件"my document.pdf"应该在 URL 中引用为 my%20document.pdf。然而,路径分隔符 (/) 应该保持未编码,除非它们是文件名数据的一部分,而不是路径结构。国际化内容始终需要编码。任何非 ASCII 字符——中文、日文、阿拉伯文、重音字符等——都必须进行 URL 编码。博客文章标题"Café 的评论"变为 Caf%C3%A9%20%E7%9A%84%E8%AF%84%E8%AE%BA。 OAuth 和身份验证流通常需要对回调 URL、状态参数和其他参数进行 URL 编码。安全令牌和签名也可能包含需要编码的字符。正确的编码对于这些安全关键流程是必不可少的。需要注意的是:不要对已经编码的 URL 进行双重编码。将 %20 再次编码变为 %2520,这是不正确的。许多框架在幕后自动处理 URL 编码,因此在手动应用编码之前,请检查您的工具是否已经处理了它。测试边缘情况,特别是涉及用户输入时,以确保正确编码。

常见陷阱和最佳实践

URL 编码似乎很简单,但有几个常见的陷阱会导致错误、破坏的链接和安全漏洞。了解这些有助于您避免这些陷阱。空格编码的混淆:空格可以编码为 %20 或 +。两者在某些上下文中都有效,但它们并不总是可互换的。在查询字符串中,+ 通常用于空格(这是 application/x-www-form-urlencoded 格式),而 %20 在 URL 路径中更可靠。现代最佳实践倾向于在任何地方都使用 %20 以保持一致性。许多 URL 编码库对此进行了抽象,但了解这种差异有助于调试。双重编码错误是常见的错误。如果您对已经编码的 URL 进行编码,则会破坏它。例如,"hello world"正确编码为"hello%20world"。双重编码将其变为"hello%2520world"(其中 % 本身被编码为 %25)。这在链接多个系统时发生,每个系统都应用自己的编码。始终检查数据是否已经编码,然后再应用编码。编码不足会导致破坏的 URL 和安全问题。忘记对用户输入进行编码可能会导致 URL 注入漏洞,攻击者可以操纵 URL 结构。例如,未编码的重定向 URL 可能被操纵以重定向到恶意站点。始终对来自不受信任源的任何数据进行编码,然后将其包含在 URL 中。字符集问题可能很微妙。URL 编码假定 UTF-8 编码,这是现代标准。然而,旧系统可能使用不同的编码(如 ISO-8859-1 或 Windows-1252)。在处理遗留系统时,请确认预期的字符编码,并相应地应用编码。大多数现代框架默认为 UTF-8,但值得验证。不同 URL 组件的不同规则:URL 的不同部分有不同的编码要求。在查询字符串中,& 和 = 有特殊含义,必须在值中编码。在路径组件中,/ 是分隔符,必须在文件名中编码。片段标识符(# 后)有自己的规则。了解您正在处理的 URL 的哪个部分很重要。框架特定的行为:不同的编程语言和框架以不同的方式处理 URL 编码。JavaScript 有 encodeURIComponent()(编码所有内容)和 encodeURI()(保留 URL 结构字符)。了解何时使用每个。在 Python 中,urllib.parse.quote() 提供可自定义的编码。阅读框架的文档,了解它如何处理编码以及您需要显式执行什么操作。性能考虑:虽然 URL 编码速度很快,但不必要地重复编码大量数据可能会影响性能。如果可能,缓存编码的 URL。对于高流量应用程序,评估编码策略并优化瓶颈。调试编码的 URL:在调试时,使用 URL 解码器(如我们的工具)使编码的 URL 可读。浏览器开发工具通常在原始形式和解码形式中显示 URL。日志记录库可能会自动解码 URL 以提高可读性,或提供两种格式。安全最佳实践:始终验证和清理用户输入,然后再对其进行编码和包含在 URL 中。URL 编码不是清理——它只是格式化。恶意输入在编码后仍然是恶意的。将 URL 编码与适当的输入验证、输出编码和内容安全策略结合使用以实现全面的安全性。测试边缘情况:使用包含空格、特殊字符、非 ASCII 字符和 URL 保留字符的输入测试您的 URL 处理。测试非常长的 URL(服务器通常有长度限制)。测试空值和空字符串。全面的测试可以在生产中破坏之前捕获编码问题。

URL 编码:完整指南

什么是 URL 编码?

何时使用 URL 编码

常见陷阱和最佳实践

试用工具

了解更多

什么是 URL 编码?

URL 编码 vs HTML 编码

查询字符串

常见问题