开发者工具 · URL 编码器和解码器
RFC 3986 保留和非保留字符：URI 标准的规定
· 背景
url 编码 rfc3986 百分比编码
RFC 3986 将字符分为保留字符、非保留字符和其他所有字符，这种划分解释了您遇到的每个百分比编码规则。这篇文章清楚地阅读了相关部分。
RFC 3986 保留和非保留字符 - 构建 URL 时最重要的是什么
RFC 3986 将字符分为三类：未保留的、保留的以及必须编码的所有其他内容。非保留字符永远不需要编码——它们是字母、数字、连字符、句点、下划线和波形符。 RFC 在 2.3 节中明确列出了这些内容，声明它们在任何 URI 上下文中都可以安全地保持未编码状态。使用这些字符在 URL 编码器和解码器中进行测试表明它们没有变化。保留字符细分为 gen-delims (: / ? # [ ] @) 和 sub-delims (! $ & ' ( ) * + , ; =)，每个在不同的 URL 组件中具有结构含义。
字符什么时候需要编码？仅当保留字符产生歧义时，才必须对它们进行百分比编码。斜杠标记路径段；在查询值中，它必须是 %2F。 & 分隔参数； & 值中需要 %26。未保留的字符永远不需要编码——连字符仍然是连字符。 URL 标准确保正确解析。使用 URL 编码器和解码器进行测试：使用encodeURIComponent 输入“hello/world"”会生成“hello%2Fworld”；使用encodeURI 会保留斜杠。
Unreserved：字母、数字、连字符、句点、下划线和波形符 - 不需要编码且永远不应该编码的字符
百分比编码使用 %HH，其中 HH 是十六进制表示法。 ASCII 字母 A（代码 65）变为 %41。非 ASCII é 需要 UTF-8 编码：é (U+00E9) 变为 %C3%A9。现代标准跨浏览器统一指定 UTF-8。
完整的 URL 需要完整的结构语法；查询值需要内部保留字符，无害。如果手动，查询参数 ?q=R&D 应将 & 编码为 %26，否则 & 符号将成为分隔符。带有正斜杠的值在组件模式下变为 %2F。组件编码 (encodeURIComponent) 通过对除未保留的字母、数字和 - _ 之外的所有内容进行编码来处理此问题。 ！ 〜*'（）。测试清楚地显示了方法之间的差异。
保留：gen-delims 和 sub-delims — 两个组、其成员及其结构角色
查询字符串演示了保留字符为何重要。 & 分隔键=值对：?utm_source=email&utm_campaign=sale 表示两个参数。在值内，未转义的 & 符号结束该对。等于将键与值分开。解析发生在多个层；每个都适用相同的规则。
查询值中需要编码的字符包括与号、等于、散列、问号、空格和非 ASCII 字母。哈希是最狡猾的：#anything 成为片段标识符，永远不会发送到服务器。在请求离开浏览器之前，以哈希结尾的活动名称会丢失其后的所有内容。空格必须变为 %20。使用 URL 编码器和解码器进行测试显示组件和表单模式。了解位置决定编码需求。
当必须对保留字符进行编码时 - 仅在它们会被误认为分隔符的地方逐个组件
百分比编码保留在 RFC 3986 中。未保留的套件保持较小，确保便携性。百分比编码的非保留字符可以在不改变含义的情况下进行解码。将 %41 解码为 A 是正确的，因为 A 是未保留的。当斜杠是数据而不是分隔符时，将 %2F 解码为 / 会改变含义。 RFC 3986 规范化部分 6 涵盖语法方法。
不同位置的保留字符有不同的作用。方案中的冒号标记方案：权限边界； userinfo 中的冒号是数据。问号打开查询部分；查询值中的斜杠是文字。哈希标记片段开始。位置决定编码需要。查询字符串携带的值本身就是 URI。将 https://example.com/page?param=value 这样的重定向 URL 编码为参数需要将斜杠和冒号编码为 %2F 和 %3A。上下文始终定义安全字符。
工作示例：对真实 URL 的每个字符进行分类 — 未保留、保留为分隔符、保留为数据
RFC 1738 (1994) 认为许多字符不安全。随着部署在 UTF-8 上标准化，后来的标准放宽了限制。波形符 (~) 举例说明了演变：RFC 1738 需要 %7E，RFC 2396 (1998) 将波形符移至未保留状态，RFC 3986 确认未保留状态。演变反映了部署经验教训。标准保留向后兼容性。
RFC 规范化允许解码不必要的百分比编码的非保留字符。 %41 安全地标准化为 A。像 %2F 这样的编码保留字符永远不会解码；改变意义会破坏结构。现代共识使用 RFC 3986 作为参考基线。 URL 编码器和解码器始终遵循 RFC 3986，提供独立于浏览器行为的固定参考。 WHATWG URL 标准在 RFC 之外添加了特定于组件的编码集。标准共存：用于一般 URL 解析的 RFC 3986，用于 Web 浏览器的 WHATWG。图书馆有所不同；检查文档。
6 部分中的规范化指南 — 十六进制大小写、未保留的解码和路径段规则
根据 RFC 3986 进行测试可确保 URL 在跨越数十年的软件中工作。 URL 编码器和解码器提供 RFC 3986 编码基线以应用于构建的组件。阅读解释 URL 库中每个编码决策的标准文档。 WHATWG URL 基于 RFC 3986 构建，而不是完全替换它。为通用浏览器构建 URL？遵循 RFC 3986；浏览器在顶部应用 WHATWG 规则。较旧的系统？测试实际实现。标准化存储？一致地应用 RFC 3986。了解保留/unreserved区别可以告诉您安全字符。
URL 编码不是安全清理。每个上下文（SQL、HTML、JavaScript、URI）都需要自己的输出编码。百分比编码仅保护 URL 结构。在正确的层应用正确的防御。
这不包括什么 - WHATWG URL 标准的不同编码集和 IRI 处理
RFC 2396 (1998) 比 RFC 1738 更严格地阐明了字符集。它形式化了服务于 URI 结构的保留字符，而未保留的字符则作为文字数据。无保留扩展，包括连字符、句点、下划线、波浪号超过原始定义。 RFC 2396 引入了 gen-delims (:, /, ?, #, [, ], @) 和子 delims (!, $, &, ', (, ), *, +, ,, ;, =) 之间的区别。每个组在 URL 中具有不同的结构角色。命名明确了保留字符分为两组。知道名字有助于技术讨论。
RFC 3986 (2005) 是现代参考。它保留了保留/unreserved的区别，但简化了符号。标准机构不会追溯性地破坏网络。故意编码了解您的标准。 URL 编码器和解码器提供 RFC 3986 参考。
要点：标准简短而精确 — URL 编码器和解码器的两种模式如何对应于编码数据与保留分隔符
选择标准取决于上下文。为通用浏览器构建 URL？遵循 RFC 3986；浏览器应用 WHATWG 规则。较旧的系统？测试实际实现。标准化存储？一致地应用 RFC 3986。百分比编码规则从保守的 RFC 1738 发展到澄清的 RFC 2396 和 RFC 3986 到分层的 WHATWG URL 标准。每一代人都反映了经验。现代构建者根据上下文遵循 RFC 3986 或 WHATWG。新旧 URL 共存需要兼容性思维。了解类别可以防止编码错误。
在部署之前验证 URL 编码是否正确。 URL 编码器和解码器演示 RFC 3986 端到端规则。查看确切的十六进制值并了解哪些字符进行编码。通过连接片段构建 URL 时，请使用此工具。 RFC 3986 保留和非保留类别分区字符集以实现一致的 URI 解析。