问题标签 [rfc3986]

RFC 3986 指定 URI 的主机组件是“不区分大小写”的。但是，它没有指定 UCS 或 UTF-8 字符中“不区分大小写”的含义。

RFC 中给出的示例（例如“ <HTTP://www.EXAMPLE.com/> 等同于<http://www.example.com/>”）允许我们推断“不区分大小写”意味着字符 AZ 至少被认为等同于 UTF-8 字符集中它们前面的字符 32，即AZ 但是，没有提到应该如何处理超出此范围的字符。因此，鉴于www.OLÉ.com的非编码、非规范化注册名称，我看到 RFC 允许的三种潜在规范化形式：

1. 小写到 www.olé.com然后百分比编码到 www.ol%E9.com
2. 仅小写 AZ 字符到www.olÉ.com，然后百分比编码到 www.ol%C9.com
3. 百分比编码为 www.OL%C9.com，然后将非百分比编码部分小写为 www.ol%C9.com，产生与 2 相同的结果。

所以问题是：哪个是正确的？如果是 case 1.，什么定义了哪些字符被认为是大写的，哪些被认为是小写的（哪些字符没有大小写）？

显然 % 需要被编码。关于标准的维基百科文章说：

因为百分比 ("%") 字符用作百分比编码八位位组的指示符，所以它必须以百分比编码为 "%25"，才能将该八位位组用作 URI 中的数据。

为什么它不被列为保留字符？显然，它被保留以表示 URI 上下文中的特殊内容......

对于我的单元测试，我想找到一个无法匹配UriComponentsBuilder#URI_PATTERNSpring MVC 3.1.1 的正则表达式的无效 URI 示例：

我正在努力寻找一个会导致UriComponentsBuilder.fromUriString()失败的字符串IllegalArgumentException。我尝试的任何东西都通过正则表达式检查作为有效的 URI。

我考虑设置一个服务器来处理包括电子邮件地址在内的 URL，例如

根据 RFC 3986，我的用户立场 @ 在权限部分 = //mydomain.com/ 上保留，但在路径部分 /....... 上未保留，所以目前我认为可以在传递时使用电子邮件地址。

话虽如此，我仍然不确定 在生产中使用http://mydomain.com/me@mail.com是否安全。

请指教。谢谢。

在 RFC3986 中，它排除了 RFC1738 中定义单个 URI 方案的特定语法的部分，并且文档说这些部分将作为单独的文档进行更新，但我找不到。任何人都可以告诉我在哪里可以找到更新的单独文档。我想写一个HTTP URL scheme parsestrong text，所以需要参考一下。

根据RFC 3986 第 3 节 - 语法组件：

方案和路径组件是必需的，但路径可能为空（无字符）。

有人可以澄清如果路径组件可以为空，如何需要它？也许我在这种情况下误解了“必需”的定义，但我认为它的意思是“必须非空”，这显然与这里的规范相冲突。

我有一个关于 URL 的问题：

我已经阅读了RFC 3986并且仍然对一个 URL 有疑问：

如果 URI 包含权限组件，则路径组件
必须为空或以斜杠 ("/") 字符开头。如果 URI 不包含权限组件，则路径不能
以两个斜杠字符（“//”）开头。此外，URI 引用
（第 4.1 节）可能是相对路径引用，在这种情况下，
第一个路径段不能包含冒号（“：”）字符。ABNF
需要五个单独的规则来消除这些情况的歧义，其中只有一个会匹配给定 URI 引用中的路径子字符串。我们使用通用术语“路径组件”来描述
解析器匹配到这些规则之一的 URI 子字符串。

我知道，这//server.com:80/path/info是有效的（它是一个架构相对 URL）

我也知道这http://server.com:80/path//info是有效的。

但我不确定以下是否有效：

我的问题背后的问题是，http://server.com:80//path/info当由http://server.com:80/path/info限制为的 URI 创建时，cookie 不会发送到/path

我读过这个问题：URL 中可以有括号吗？和相关的RFC 3986。

这个问题的答案说，[并且]被 RFC 归类为gen-delims，因此应该被编码，但没有解释不这样做会有问题。

所以，我不明白 URL 可能有什么问题，例如：

例如，为什么&应该进行编码是显而易见的，因为它被用作查询参数之间的分隔符。

但是，如果 URL 没有进行 URL 编码，那么在 URL中使用[and]会使他们的意图混乱吗？

我认为 Java 的 URI.resolve 方法的定义和实现与RFC 3986 第 5.2.2 节不兼容。我知道 Java API 定义了该方法的工作原理，如果现在更改它会破坏现有的应用程序，但我的问题是：谁能确认我的理解是该方法与 RFC 3986 不兼容？

我正在使用这个问题的示例：java.net.URI resolve against only query string，我将在此处复制：

我正在尝试使用 JDK java.net.URI 构建 URI。我想附加到一个绝对 URI 对象，一个查询（在字符串中）。例如：

理论（或我认为）是 resolve 应该返回：

但我得到的是：

我对RFC 3986 第 5.2.2 节的理解是，如果相对 URI 的路径为空，则将使用基本 URI 的整个路径：

并且仅当指定了路径时，才会将相对路径与基本路径合并：

但是 Java 实现总是进行合并，即使路径为空：

如果我的阅读是正确的，要从 RFC 伪代码中获取此行为，您可以在查询字符串之前在相对 URI 中放置一个点作为路径，根据我在网页中使用相对 URI 作为链接的经验，这是我所期望的：

但我希望，在网页中，页面“http://example.com/something/more/long”到“?query”的链接会转到“http://example.com/something/ more/long?query”，而不是“http://example.com/something/more/?query”——换句话说，与 RFC 一致，但与 Java 实现不一致。

我对 RFC 的阅读是否正确，Java 方法与之不一致，还是我遗漏了什么？

当 URLhttp:///example.org在 Firefox 或基于 webkit 的浏览器中打开时，它会打开http://example.org. 我想知道这是否是一种有效的行为，即是否应该去除多余的斜线并将example.org其视​​为授权组件。我阅读了规范（RFC 3986），我的印象是这样的 URI 的权限组件应该被认为是空的。其他一些 HTTP 客户端（例如 curl 或 links2）不会解析 URL。

这是浏览器中的错误，还是符合 RFC 的有效行为？编辑：或者一个预期的功能，以使浏览器更加用户友好？