Question

Java的URI类定义了不透明的URI，如下所示（强调我的）。

如果且仅当它是绝对的并且其特定于方案的部分不以斜杠字符（'/'）开头时，URI是不透明的。不透明URI具有方案，方案特定部分，并且可能是片段; 所有其他组件未定义。

对于文档，对于查询参数，不透明URI返回null。

URI uri = URI.create("stackoverflow:foo?key=value#frag");
uri.isOpaque() == true
uri.getScheme() == stackoverflow
uri.getSchemeSpecificPart() == foo?key=value
uri.getQuery() == null
uri.getFragment() == frag

此行为是否特定于Java的URI实现，或者URI规范是否禁止不透明URI中的查询参数？

Answer 1

Java的URI类documented符合RFC 2396和RFC 2732：

除了下面提到的一些小偏差之外，此类的实例表示RFC 2396定义的URI引用：统一资源标识符（URI）：通用语法，由RFC 2732修改：URL中的文字IPv6地址格式。 / p>

第3节.URI句法组件并未明确禁止 opaque URI中的查询组件，而只是不为他们定义语法。根据定义，不透明的URI需要特定于方案的知识才能知道 if 是否存在类似于查询组件的内容以及如何解析它。拥有一个是完全合法的，但是如果没有那些特殊的知识，它就不能在一般意义上（在此RFC下）得到支持。相关的RFC文本是：

URI语法取决于方案。一般来说，绝对的   URI编写如下：

<scheme>:<scheme-specific-part>

绝对URI包含正在使用的方案的名称（<scheme>）   后跟冒号（“：”）然后是一个字符串（<scheme-specific-part>）   其解释取决于计划。

只有通用语法提供了RFC定义的查询组件，并且该语法在紧跟第一个冒号（/）之后需要至少一个斜杠（:）该计划。


URI语法不要求scheme-specific-part具有   任何一般结构或一组语义，这是所有人共同的   URI。但是，URI的一个子集确实共享一个共同的语法   表示命名空间内的层次关系。这个   “通用URI”语法由四个主要组件序列组成：

<scheme>://<authority><path>?<query>
     除了<scheme>之外，
中的每一个都可能不在特定的URI中。   例如，某些URI方案不允许<authority>组件，   和其他人不使用<query>组件。

absoluteURI = scheme ":" ( hier_part | opaque_part ) ... hier_part = ( net_path | abs_path ) [ "?" query ] net_path = "//" authority [ abs_path ]> abs_path = "/" path_segments

前面提到的两个RFC都是obsoleted by RFC 3986，但由于backwards-compatibility原因，Java现有的API和行为是unlikely to be changed。

URI实现与较新的RFC不同，不仅在于如何定义URI的有效组件，还在于行为。例如，请参阅：

Is Java's URI.resolve incompatible with RFC 3986 when the relative URI contains an empty path?

快速搜索至少会发现一个尝试提供RFC 3986兼容实现的开源library，但之前的链接既不是认可也不是推荐。与现有基于java.net.URI的API的兼容性可能会受到限制。

是否允许在不透明的URI中使用查询参数？

1 个答案: