URL 编码和解码

使用我们超级方便的在线 URL 编码工具来编码或解码您的数据。它是免费的!

在线编码为 URL 编码格式



关于 URL 解码和编码

欢迎使用 URL 解码和编码,您终极的在线工具,可轻松编码和解码 URL。我们的平台旨在简化 URL 编码和解码的过程,让您能够将数据转换为 URL 安全格式,或仅需点击一下即可将其还原为人类可读状态。

什么是 URL 编码?

URL 编码,通常称为百分号编码,是在形成统一资源标识符(URI)时使用的重要机制。虽然通常被称为 URL 编码,但此技术在 URI 框架内广泛适用,包括统一资源定位符(URL)和统一资源名称(URN)。它将字符转换为可以通过互联网传输的格式,对于 Web 应用程序和 HTTP 请求中的数据提交至关重要。

功能和高级选项

我们的工具支持多种字符集,包括 UTF-8、ASCII 和各种 ISO 格式,确保满足您的需求。您可以自定义:

  • 字符集: 我们的网站默认使用 UTF-8 字符集来传输您的输入数据。如果您需要在编码之前将数据转换为其他字符集,可以调整此选项。请记住,对于文本数据,编码方案不包括字符集。
  • 换行符分隔: Unix 和 Windows 系统使用不同的字符作为换行符。在编码之前,您的数据将根据所选选项进行调整,以替换这些字符。根据您的数据选择 Unix(LF)或 Windows(CRLF)换行符。
  • 逐行唯一编码: 换行符也将转换为其百分号编码等价物。如果您想编码多个通过换行符分隔的独立数据条目,可以使用此选项。
  • 将行拆分为 76 个字符的块: 编码后的数据将变为没有任何空格的连续字符串。如果您希望将其拆分为多行,请确保选择此选项。字符限制由 MIME(RFC 2045)规范设定,要求每个编码行不超过 76 个字符。

安全与保障

我们重视您的隐私。所有通信都经过 SSL 加密,我们不存储或检查您上传的数据。数据不会存储在我们的服务器上。您的数据在处理后会立即删除,确保您的信息保持机密。

完全免费且用户友好

我们的 URL 编码和解码工具完全免费使用。告别复杂的软件安装——直接在浏览器中执行您的编码任务。

URL 编码的详细信息

URI 字符的类型
在 URI 中,字符分为两类:保留字符和非保留字符,以及用于编码的百分号字符。保留字符可以具有特殊含义;例如,正斜杠用于分隔 URL 的不同部分(或更广义的 URI)。另一方面,非保留字符没有任何特殊意义。在使用百分号编码时,保留字符通过特定的序列表示。保留字符和非保留字符的定义,以及某些保留字符在特定上下文中重要性的情况,随着每次修订 URI 和 URI 方案的规范而发展。

RFC 3986 第 2.2 节 保留字符(2005 年 1 月)
! * ' ( ) ; : @ & = + $ , / ? # [ ]
RFC 3986 第 2.3 节 非保留字符(2005 年 1 月)
A B C D E F G F I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 - _ . ~

百分号编码的保留字符

当保留字符在特定上下文中具有特定意义时,如果 URI 方案要求将其用于其他目的,则可能需要进行百分号编码。百分号编码涉及将字符转换为其对应的 ASCII 字节值,然后将该值表示为两个十六进制数字,前面加上百分号('%')。对于非 ASCII 字符,通常将字符转换为其 UTF-8 字节序列,每个字节以相同方式表示。

例如,保留字符 '/' 在 URI 的 'path' 组件中充当分隔符。如果 URI 方案指定在路径段中应包含 '/',则在该段中应将其替换为 '%2F'(或 '%2f'),而不是直接使用该字符。

百分号编码的保留字符
! # $ & ' ( ) * + , / : ; = ? @ [ ]
%21 %23 %24 %26 %27 %28 %29 %2A %2B %2C %2F %3A %3B %3D %3F %40 %5B %5D

在特定上下文中没有特定目的的保留字符也可以进行百分号编码,但在意义上与其他字符相同。

例如,在 URI 的 'query' 组件中(即 '?' 字符后面的部分),'/' 字符被归类为保留字符,但通常没有特殊功能,除非特定的 URI 方案指定。因此,当它缺乏保留目的时,不需要进行百分号编码。

仅仅基于保留字符是否进行百分号编码而不同的 URI 通常不被视为等价,这意味着它们不指向同一资源。然而,这仅适用于有关的保留字符没有指定目的的情况。关于保留字符的具体规则由各个 URI 方案定义。

百分号编码的非保留字符

非保留字符集中的字符不需要进行百分号编码。

仅仅基于非保留字符是否进行百分号编码而不同的 URI 在定义上被视为等价。然而,在实践中,URI 处理器可能并不总是以相同的方式处理它们。例如,'%41' 应视为与 'A' 相同(因为 '%41' 是 'A' 的百分号编码),'%7E' 应与 '~' 等价。尽管如此,一些系统可能会区分它们。为了确保最大的兼容性,建议 URI 生成者避免对非保留字符进行百分号编码。

百分号编码(%)字符

百分号('%') 字符用于指示百分号编码的八位字节,因此当您需要将其作为数据包含在 URI 中时,必须将其百分号编码为 '%25'。

百分号编码任意数据

许多 URI 方案要求将各种类型的任意数据表示为 URI 的一部分,例如 IP 地址或文件系统路径。虽然 URI 方案的规范理想情况下提供了 URI 字符与所有可能数据值之间的清晰映射,但实际情况往往不是这样。

二进制数据

在 1994 年发布 RFC 1738 之后,确立了允许在 URI 中表示二进制数据的方案必须将数据拆分为 8 位字节并相应地进行百分号编码。例如,字节值 0F(十六进制)必须表示为 '%0F',而字节值 41 可以显示为 'A' 或 '%41'。通常,建议对字母数字字符和其他非保留字符使用未编码字符,因为这会生成更短的 URL。

字符数据

对二进制数据进行百分号编码的方法常常不适当地扩展到基于字符的数据,而没有明确的指导。在万维网的早期,当处理 ASCII 集中的字符时,通常假设字符及其对应的字节值可以互换地用于百分号编码。这一假设在当时大多是无害的。然而,随着需要表示超出 ASCII 范围的字符的增长,URI 方案和协议通常缺乏标准化规则来准备字符数据以用于 URI。

因此,Web 应用程序开始使用各种多字节和非 ASCII 兼容编码进行百分号编码,这引入了模糊性,使得可靠地解释 URI 变得更加困难。

例如,许多基于 RFC 1738 和 2396 的 URI 方案和协议假定数据字符将在表示为 URI 的非保留字符或百分号编码字节之前使用某种未指定的编码转换为字节。如果某个方案未指定所使用的编码或与基于 ASCII 的保留和非保留字符的百分号编码冲突,则 URI 将变得难以正确解释。一些方案完全忽视了编码,反而建议数据字符应直接映射到 URI 字符。这使得用户必须确定如何对不属于保留或非保留类别的字符进行百分号编码。

百分号编码后的常见字符(基于 ASCII 或 UTF-8)
newline space " % - . < > \ ^ _ ` { | } ~
%0A or %0D or %0D%0A %20 %22 %25 %2D %2E %3C %3E %5C %5E %5F %60 %7B %7C %7D %7E

URL 编码的简要历史

URL 编码起源于互联网的早期阶段,并在 1994 年发布的 RFC 1738 中得到正式化。该规范为将任意数据编码为适合 URI 的格式奠定了基础,使特殊字符的表示成为可能,并确保数据的正确传输。随着多年来 Web 标准的发展,围绕百分号编码的做法也在不断演变,适应了更广泛的字符和编码方案,特别是随着非 ASCII 字符和多字节编码的兴起。这一演变使得 URL 编码成为 Web 开发人员的一项重要技能,确保数据在多样化的平台和协议中保持完整并得到正确解释。