模块 java.base
 java.net

类 URI

java.lang.Object
java.net.URI
所有已实现的接口:
Serializable , Comparable<URI>

public final class URI extends Object implements Comparable <URI >, Serializable
表示统一资源标识符 (URI) 引用。

除了下面提到的一些小偏差之外,此类的实例表示由 RFC 2396:统一资源标识符 (URI):通用语法 定义并由 RFC 2732:URL 中文字 IPv6 地址的格式 修改的 URI 引用。 Literal IPv6 地址格式也支持 scope_ids。 这里 描述了 scope_ids 的语法和用法。此类提供用于从其组件或通过解析其字符串形式创建 URI 实例的构造函数、用于访问实例的各种组件的方法以及用于规范化、解析和相对化 URI 实例的方法。此类的实例是不可变的。

URI 语法和组件

在最高级别,字符串形式的 URI 引用(以下简称“URI”)具有以下语法
[方案: ]方案特定部分[# 分段]
其中方括号 [...] 描述可选组件和字符: # 代表自己。

一个绝对URI 指定一个方案;一个非绝对的 URI 被称为相对的. URI 也根据它们是否是不透明或者分层的.

一个不透明URI 是一个绝对 URI,其特定于方案的部分不以斜杠字符 ('/') 开头。不透明的 URI 不受进一步解析的影响。不透明 URI 的一些示例是:

  • mailto:java-net@www.example.com
  • news:comp.lang.java
  • urn:isbn:096139210x

A 分层的URI 可以是绝对 URI,其方案特定部分以斜杠字符开头,也可以是相对 URI,即未指定方案的 URI。分层 URI 的一些示例是:

http://example.com/languages/java/
sample/a/index.html#28
../../demo/b/index.html
file:///~/calendar

分层 URI 需要根据语法进行进一步解析

[方案: ][// 授权][path][? 询问][# 分段]
字符在哪里: , / , ? , 和# 代表自己。分层 URI 的特定于方案的部分由方案和片段组件之间的字符组成。

如果指定,分层 URI 的权限组件是基于服务或者基于注册表.基于服务的权限根据熟悉的语法进行解析

[用户信息@ ]主持人[: port]
字符在哪里@ : 代表自己。当前使用的几乎所有 URI 方案都是基于服务的。不以这种方式解析的权限组件被认为是基于注册表的。

如果分层 URI 的路径组件以斜杠字符 ('/') 开头,则它本身就是绝对的;否则它是相对的。绝对的或指定权限的分层 URI 的路径始终是绝对的。

总而言之,一个 URI 实例有以下九个组成部分:

描述 URI 的组件:scheme、scheme-specific-part、authority、user-info、host、port、path、query、fragment
Component Type
方案 String
方案特定部分 String
授权 String
用户信息 String
主持人 String
port int
path String
询问 String
分段 String
在给定的实例中,任何特定的组件都是不明确的或者定义的具有独特的值。未定义的字符串组件由 null 表示,而未定义的整数组件由 -1 表示。可以将字符串组件定义为将空字符串作为其值;这不等同于该组件未定义。

特定组件是否在实例中定义取决于所表示的 URI 的类型。绝对 URI 具有方案组件。不透明的 URI 有一个方案、一个特定于方案的部分,可能还有一个片段,但没有其他组件。分层 URI 始终具有路径(尽管它可能为空)和特定于方案的部分(至少包含路径),并且可能具有任何其他组件。如果授权组件存在并且是基于服务的,那么主机组件将被定义并且用户信息和端口组件可以被定义。

对 URI 实例的操作

此类支持的关键操作是正常化, 解决, 和相对化.

正常化是从分层 URI 的路径组件中删除不必要的 "."".." 段的过程。每个 "." 段都被简单地删除了。只有在 ".." 段前面有非 ".." 段时,它才会被删除。规范化对不透明的 URI 没有影响。

解决是将一个 URI 解析为另一个 URI 的过程,base网址。生成的 URI 是按照 RFC 2396 指定的方式从两个 URI 的组件构建的,从基本 URI 中获取原始 URI 中未指定的组件。对于分层 URI,原始路径根据基础路径进行解析,然后进行规范化。例如,解决的结果

sample/a/index.html#28                  (1)
针对基本 URI http://example.com/languages/java/ 是结果 URI
http://example.com/languages/java/sample/a/index.html#28
解析相对 URI
../../demo/b/index.html     (2)
反对这个结果反过来,
http://example.com/languages/java/demo/b/index.html
支持解析绝对和相对 URI,以及分层 URI 情况下的绝对和相对路径。根据任何其他 URI 解析 URI file:///~calendar 只会产生原始 URI,因为它是绝对的。将上面的相对 URI (2) 与相对基础 URI (1) 进行解析会产生规范化但仍然是相对的 URI
demo/b/index.html

相对化,最后,可以看作是分辨率的倒数。让u是任何以斜杠字符 ('/') 结尾的规范化绝对 URI,并且v是任何不以句点字符 ('.') 或斜杠字符 ('/') 开头的规范化相对 URI。那么,以下陈述为真:

u.relativize( u.resolve( v)).equals( v)
u是任何以斜杠字符 ('/') 结尾的规范化绝对 URI,并且v是任何规范化的绝对 URI。那么,以下陈述为真:
u.resolve( u.relativize( v)).equals( v)
在构建包含必须尽可能相对于文档的基本 URI 的 URI 的文档时,此操作通常很有用。例如,相对化 URI
http://example.com/languages/java/sample/a/index.html#28
针对基础 URI
http://example.com/languages/java/
产生相对 URI sample/a/index.html#28

字符类别

RFC 2396 精确指定了 URI 引用的各个组件中允许使用哪些字符。以下类别(其中大部分取自该规范)在下面用于描述这些约束:
描述类别 alpha、digit、alphanum、unreserved、punct、reserved、escaped 和其他
Category Description
alpha US-ASCII 字母字符,'A''Z''a''z'
数字 US-ASCII 十进制数字字符,'0''9'
字母数字 全部alpha数字characters
毫无保留 全部字母数字字符与字符串 "_-!.~'()*" 中的字符一起
点点 字符串",;:$&+="中的字符
预订的 全部点点字符与字符串 "?/[]@" 中的字符一起
逃脱 转义八位字节,即由百分比字符 ('%') 后跟两个十六进制数字('0' -'9''A' -'F''a' -'f')组成的三元组
其他 不在US-ASCII字符集中的Unicode字符,不是控制字符(根据Character.isISOControl 方法),也不是空格字符(根据Character.isSpaceChar 方法)(偏离 RFC 2396,仅限于 US-ASCII)

所有合法 URI 字符的集合包括毫无保留, 预订的, 逃脱, 和其他人物。

转义八位字节、引用、编码和解码

RFC 2396 允许转义的八位字节出现在用户信息、路径、查询和片段组件中。在 URI 中转义有两个目的:
  • encode非 US-ASCII 字符,当要求 URI 不包含任何内容以严格遵守 RFC 2396 时其他人物。

  • quote组件中非法的字符。用户信息、路径、查询和片段组件在哪些字符被视为合法和非法方面略有不同。

这些目的在此类中通过三个相关操作来实现:
  • 一个字符是编码的通过用代表 UTF-8 字符集中该字符的转义八位字节序列替换它。例如,欧元货币符号 ('\u20AC') 被编码为 "%E2%82%AC"(偏离 RFC 2396,它没有指定任何特定的字符集。)

  • 非法字符是只需对其进行编码。例如,空格字符通过用 "%20" 替换来引用。 UTF-8 包含 US-ASCII,因此对于 US-ASCII 字符,此转换具有 RFC 2396 所需的效果。

  • 转义的八位字节序列是解码通过用它在 UTF-8 字符集中表示的字符序列替换它。 UTF-8 包含 US-ASCII,因此解码具有取消引用任何引用的 US-ASCII 字符以及解码任何编码的非 US-ASCII 字符的效果。如果在解码转义的八位字节时出现 解码错误,则错误的八位字节将替换为 '\uFFFD',即 Unicode 替换字符。

这些操作在此类的构造方法和方法中公开如下:

身份

对于任何 URIu, 总是这样
new URI( u.toString()).equals( u)  .
对于任何 URIu不包含冗余语法,例如空权限前的两个斜杠(如 file:///tmp/ 中)或主机名后的冒号但没有端口(如 http://www.example.com: 中),并且不编码字符,除了必须引用的字符,以下身份也成立:
   new URI(u.getScheme(),
       u.getSchemeSpecificPart(),
       u.getFragment())
   .equals(u)
在所有情况下,
   new URI(u.getScheme(),
       u.getAuthority(),
       u.getPath(), u.getQuery(),
       u.getFragment())
   .equals(u)
如果u是分层的,
   new URI(u.getScheme(),
       u.getUserInfo(), u.getHost(), u.getPort(),
       u.getPath(), u.getQuery(),
       u.getFragment())
   .equals(u)
如果u是分层的,没有权限或基于服务的权限。

URI、URL 和 URN

URI是统一资源标识符而 URL 是统一资源定位器.因此,抽象地说,每个 URL 都是一个 URI,但并非每个 URI 都是一个 URL。这是因为URI还有一个子类,uniform resource名字(URNs),它命名资源但不指定如何定位它们。上面显示的 mailtonewsisbn URI 是 URN 的示例。

URI 和 URL 的概念区别体现在这个类和URL 类的区别上。

此类的实例表示 RFC 2396 定义的句法意义上的 URI 引用。URI 可以是绝对的,也可以是相对的。 URI 字符串根据通用语法进行解析,而不考虑它指定的方案(如果有的话)。不执行主机查找(如果有的话),并且不构造依赖于方案的流处理程序。相等、散列和比较严格根据实例的字符内容来定义。换句话说,一个 URI 实例只不过是一个结构化的字符串,它支持比较、规范化、解析和相对化的句法、独立于方案的操作。

相比之下,URL 类的实例表示 URL 的句法组件以及访问它描述的资源所需的一些信息。 URL 必须是绝对的,也就是说,它必须始终指定一个方案。 URL 字符串根据其方案进行解析。总是为 URL 建立流处理程序,实际上不可能为没有可用处理程序的方案创建 URL 实例。相等性和散列取决于方案和主机的 Internet 地址(如果有);比较未定义。换句话说,URL 是一个结构化的字符串,它支持解析的句法操作以及查找主机和打开到指定资源的连接的网络 I/O 操作。

API 注意:
使用文件路径和文件 URI 的应用程序应该非常小心地使用适当的方法在两者之间进行转换。 Path.of(URI) 工厂方法和 File(URI) 构造函数可用于从文件 URI 创建 Path File 对象。 Path.toUri() File.toURI() 可用于从文件路径创建 URI 。应用程序永远不应尝试从 FilePath 实例的直接字符串表示形式 构造parseresolve a URI

URL 或 URI 的某些组成部分,例如用户信息, 可能会被滥用来构建误导性的 URL 或 URI。处理 URL 或 URI 的应用程序应考虑 RFC3986,第 7 节,安全注意事项 中建议的建议。

自从:
1.4
参见:
  • 构造方法详细信息

    • URI

      public URI(String  str) throws URISyntaxException
      通过解析给定的字符串构造一个 URI。

      此构造函数完全按照附录 A RFC 2396 中的语法指定的方式解析给定的字符串,除了以下偏差:

      • 允许空权限组件,只要它后跟非空路径、查询组件或片段组件。这允许解析诸如 "file:///foo/bar" 之类的 URI,这似乎是 RFC 2396 的意图,尽管语法不允许这样做。如果权限组件为空,则用户信息、主机和端口组件未定义。

      • 允许空的相对路径;这似乎是 RFC 2396 的意图,尽管语法不允许这样做。这种偏差的主要后果是独立片段(如 "#foo")解析为具有空路径和给定片段的相对 URI,并且可以有用地 解决 反对基本 URI。

      • 严格解析主机组件中的 IPv4 地址,如 RFC 2732 所指定:点分四组地址的每个元素必须包含不超过三个十进制数字。每个元素被进一步限制为具有不大于 255 的值。

      • 仅包含单个域标签的主机组件中的主机名允许以字母数字特点。这似乎是 RFC 2396 第 3.2.2 节的意图,尽管语法不允许这样做。这种偏差的结果是分层 URI(例如 s://123)的权限组件将解析为基于服务的权限。

      • 主机组件允许使用 IPv6 地址。 IPv6 地址必须按照 RFC 2732 的规定括在方括号('['']' )中。 IPv6 地址本身必须根据 RFC 2373 进行解析。 IPv6 地址被进一步限制为描述不超过 16 个字节的地址信息,该限制隐含在 RFC 2373 中但无法在语法中表达。

      • 中的字符其他只要 RFC 2396 允许,就允许类别逃脱八位字节,即在用户信息、路径、查询和片段组件中,以及在权限组件中(如果权限是基于注册表的)。这允许 URI 包含 US-ASCII 字符集中以外的 Unicode 字符。

      参数:
      str - 要解析为 URI 的字符串
      抛出:
      NullPointerException - 如果 strnull
      URISyntaxException - 如果给定的字符串违反了 RFC 2396,如上述偏差所增加
    • URI

      public URI(String  scheme, String  userInfo, String  host, int port, String  path, String  query, String  fragment) throws URISyntaxException
      从给定的组件构造分层 URI。

      如果给出了方案,则路径(如果也给出)必须为空或以斜杠字符 ('/') 开头。否则,通过为相应参数传递 null 或在 port 参数的情况下,通过传递 -1 可以保留未定义新 URI 的组件。

      此构造函数首先根据 RFC 2396 部分 5.2,步骤 7 中指定的规则从给定组件构建 URI 字符串:

      1. 最初,结果字符串为空。

      2. 如果给出了方案,则将其附加到结果,后跟冒号字符 (':')。

      3. 如果提供了用户信息、主机或端口,则会附加字符串 "//"

      4. 如果提供了用户信息,则会附加该信息,后跟商业字符 ('@')。任何不在毫无保留, 点点, 逃脱, 或者其他类别是

      5. 如果给出主机,则将其附加。如果主机是文字 IPv6 地址但未括在方括号('['']')中,则添加方括号。

      6. 如果给出了端口号,则会附加一个冒号字符 (':'),然后是十进制的端口号。

      7. 如果给出了路径,则会附加它。任何不在毫无保留, 点点, 逃脱, 或者其他类别,并且不等于斜杠字符 ('/') 或商业字符 ('@'),被引用。

      8. 如果给出查询,则附加一个问号字符 ('?'),然后是查询。引用任何不是 合法的 URI 字符 的字符。

      9. 最后,如果给出一个片段,则附加一个散列字符 ('#'),然后是片段。引用任何不是合法 URI 字符的字符。

      然后解析生成的 URI 字符串,就像调用 URI(String) 构造函数,然后根据结果调用 parseServerAuthority() 方法一样;这可能会导致抛出 URISyntaxException

      参数:
      scheme - 方案名称
      userInfo - 用户名和授权信息
      host - 主机名
      port - 端口号
      path - 路径
      query - 查询
      fragment - 片段
      抛出:
      URISyntaxException - 如果方案和路径都给定但路径是相对的,如果从给定组件构造的 URI 字符串违反 RFC 2396,或者如果字符串的授权组件存在但不能解析为基于服务的授权
    • URI

      public URI(String  scheme, String  authority, String  path, String  query, String  fragment) throws URISyntaxException
      从给定的组件构造分层 URI。

      如果给出了方案,则路径(如果也给出)必须为空或以斜杠字符 ('/') 开头。否则,通过为相应参数传递null,可以保留未定义新 URI 的组件。

      此构造函数首先根据 RFC 2396 部分 5.2,步骤 7 中指定的规则从给定组件构建 URI 字符串:

      1. 最初,结果字符串为空。

      2. 如果给出了方案,则将其附加到结果,后跟冒号字符 (':')。

      3. 如果给出权限,则附加字符串 "//",后跟权限。如果授权机构包含文字 IPv6 地址,则该地址必须括在方括号中('['']')。任何不在毫无保留, 点点, 逃脱, 或者其他类别,不等于商业字符 ('@'),是

      4. 如果给出了路径,则会附加它。任何不在毫无保留, 点点, 逃脱, 或者其他类别,并且不等于斜杠字符 ('/') 或商业字符 ('@'),被引用。

      5. 如果给出查询,则附加一个问号字符 ('?'),然后是查询。引用任何不是 合法的 URI 字符 的字符。

      6. 最后,如果给出一个片段,则附加一个散列字符 ('#'),然后是片段。引用任何不是合法 URI 字符的字符。

      然后解析生成的 URI 字符串,就像调用 URI(String) 构造函数,然后根据结果调用 parseServerAuthority() 方法一样;这可能会导致抛出 URISyntaxException

      参数:
      scheme - 方案名称
      authority - 权威
      path - 路径
      query - 查询
      fragment - 片段
      抛出:
      URISyntaxException - 如果方案和路径都给定但路径是相对的,如果从给定组件构造的 URI 字符串违反 RFC 2396,或者如果字符串的授权组件存在但不能解析为基于服务的授权
    • URI

      public URI(String  scheme, String  host, String  path, String  fragment) throws URISyntaxException
      从给定的组件构造分层 URI。

      通过传递 null 可以保留未定义的组件。

      这个便利构造方法的工作方式就像调用七参数构造方法一样,如下所示:

      new URI (scheme, null, host, -1, path, null, fragment);
      参数:
      scheme - 方案名称
      host - 主机名
      path - 路径
      fragment - 片段
      抛出:
      URISyntaxException - 如果从给定组件构造的 URI 字符串违反 RFC 2396
    • URI

      public URI(String  scheme, String  ssp, String  fragment) throws URISyntaxException
      从给定的组件构造一个 URI。

      通过传递 null 可以保留未定义的组件。

      此构造方法首先使用给定的组件构建字符串形式的 URI,如下所示:

      1. 最初,结果字符串为空。

      2. 如果给出了方案,则将其附加到结果,后跟冒号字符 (':')。

      3. 如果给出了特定于方案的部分,则将其附加。任何不是 合法的 URI 字符 的字符都是

      4. 最后,如果给出了片段,则将哈希字符 ('#') 附加到字符串,然后是片段。引用任何不是合法 URI 字符的字符。

      然后解析生成的 URI 字符串,以创建新的 URI 实例,就像调用 URI(String) 构造函数一样;这可能会导致抛出 URISyntaxException

      参数:
      scheme - 方案名称
      ssp - 方案特定部分
      fragment - 片段
      抛出:
      URISyntaxException - 如果从给定组件构造的 URI 字符串违反 RFC 2396
  • 方法详情

    • create

      public static URI  create(String  str)
      通过解析给定的字符串创建 URI。

      这个方便的工厂方法就像调用 URI(String) 构造函数一样工作;构造函数抛出的任何 URISyntaxException 都被捕获并包装在一个新的 IllegalArgumentException 对象中,然后被抛出。

      提供此方法是为了在已知给定字符串是合法 URI 的情况下使用,例如在程序中声明的 URI 常量,因此如果字符串不这样解析将被视为编程错误。直接抛出 URISyntaxException 的构造函数应该用于从用户输入或其他可能容易出错的来源构造 URI 的情况。

      参数:
      str - 要解析为 URI 的字符串
      返回:
      新的 URI
      抛出:
      NullPointerException - 如果 strnull
      IllegalArgumentException - 如果给定的字符串违反了 RFC 2396
    • parseServerAuthority

      public URI  parseServerAuthority() throws URISyntaxException
      尝试将此 URI 的授权组件(如果已定义)解析为用户信息、主机和端口组件。

      如果此 URI 的权限组件已被识别为基于服务,则它已被解析为用户信息、主机和端口组件。在这种情况下,或者如果此 URI 没有权限组件,则此方法仅返回此 URI。

      否则,此方法会再次尝试将授权组件解析为用户信息、主机和端口组件,并抛出一个异常来描述无法以这种方式解析授权组件的原因。

      提供此方法是因为 RFC 2396 中指定的通用 URI 语法不能始终区分格式错误的基于服务的权限和合法的基于注册表的权限。因此,它必须将前者的某些实例视为后者的实例。例如,URI 字符串 "//foo:bar" 中的权限组件不是合法的基于服务的权限,但它作为基于注册表的权限是合法的。

      在许多常见情况下,例如,当已知工作 URI 是 URN 或 URL 时,所使用的分层 URI 将始终是基于服务的。因此,它们必须被这样解析或被视为错误。在这些情况下,声明如

      URI u = new URI(str).parseServerAuthority();

      可用于确保u总是指一个 URI,如果它有一个权限组件,那么它有一个基于服务的权限,带有适当的用户信息、主机和端口组件。调用此方法还可以确保,如果无法以那种方式解析权限,则可以根据抛出的异常发出适当的诊断消息。

      返回:
      其权限字段已被解析为基于服务的权限的 URI
      抛出:
      URISyntaxException - 如果此 URI 的权限组件已定义但无法根据 RFC 2396 解析为基于服务的权限
    • normalize

      public URI  normalize()
      规范化此 URI 的路径。

      如果这个 URI 是不透明的,或者如果它的路径已经是正常形式,则返回这个 URI。否则,将构造一个与此 URI 相同的新 URI,除了其路径是通过以与 RFC 2396 部分 5.2,步骤 6,子步骤 c 到 f 一致的方式规范化此 URI 的路径来计算的;那是:

      1. 所有 "." 段都被删除。

      2. 如果 ".." 段之前是非 ".." 段,则这两个段都将被删除。重复此步骤,直到它不再适用。

      3. 如果路径是相对的,并且如果它的第一段包含冒号字符 (':'),则会在前面添加一个 "." 段。这可以防止具有 "a:b/c/d" 等路径的相对 URI 稍后被重新解析为具有 "a" 方案和 "b/c/d" 方案特定部分的不透明 URI。(偏离 RFC 2396)

      如果在它们之前没有足够的非 ".." 段以允许删除它们,则规范化路径将从一个或多个 ".." 段开始。如果在上面的步骤 3 中插入了一个规范化路径,则该路径将以 "." 段开头。否则,规范化路径将不包含任何 "."".." 段。

      返回:
      与此 URI 等效的 URI,但其路径为正常形式
    • resolve

      public URI  resolve(URI  uri)
      根据此 URI 解析给定的 URI。

      如果给定的 URI 已经是绝对的,或者如果这个 URI 是不透明的,则返回给定的 URI。

      如果给定 URI 的片段组件已定义,其路径组件为空,并且其方案、权限和查询组件未定义,则返回具有给定片段但所有其他组件与此 URI 相同的 URI。这允许表示独立片段引用的 URI(例如 "#foo")根据基本 URI 进行有效解析。

      否则,此方法以与 RFC 2396 ,第 5.2 节一致的方式构造新的分层 URI;那是:

      1. 一个新的 URI 是用这个 URI 的方案和给定的 URI 的查询和片段组件构造的。

      2. 如果给定的 URI 具有权限组件,则新 URI 的权限和路径取自给定的 URI。

      3. 否则,新 URI 的权限组件将从该 URI 复制,其路径计算如下:

        1. 如果给定的 URI 路径是绝对路径,则新 URI 的路径取自给定的 URI。

        2. 否则,给定 URI 的路径是相对的,因此新 URI 的路径是通过根据此 URI 的路径解析给定 URI 的路径来计算的。这是通过将此 URI 路径的最后一段(如果有的话)与给定的 URI 路径连接起来,然后像调用 normalize 方法一样对结果进行规范化来完成的。

      当且仅当此 URI 是绝对的或给定的 URI 是绝对的时,此方法的结果才是绝对的。

      参数:
      uri - 要针对此 URI 解析的 URI
      返回:
      生成的 URI
      抛出:
      NullPointerException - 如果 urinull
    • resolve

      public URI  resolve(String  str)
      通过解析给定的字符串然后根据此 URI 解析它来构造一个新的 URI。

      这种便捷方法的工作方式就好像调用它等同于计算表达式 resolve (URI. create (str)) 一样。

      参数:
      str - 要解析为 URI 的字符串
      返回:
      生成的 URI
      抛出:
      NullPointerException - 如果 strnull
      IllegalArgumentException - 如果给定的字符串违反了 RFC 2396
    • relativize

      public URI  relativize(URI  uri)
      将给定的 URI 相对于此 URI 相对化。

      给定 URI 相对于此 URI 的相对化计算如下:

      1. 如果此 URI 或给定 URI 是不透明的,或者如果两个 URI 的方案和权限组件不相同,或者如果此 URI 的路径不是给定 URI 路径的前缀,则给定 URI 是回。

      2. 否则,将使用从给定 URI 中获取的查询和片段组件以及通过从给定 URI 路径的开头删除此 URI 的路径计算出的路径组件来构造新的相对分层 URI。

      参数:
      uri - 要相对于此 URI 相对化的 URI
      返回:
      生成的 URI
      抛出:
      NullPointerException - 如果 urinull
    • toURL

      public URL  toURL() throws MalformedURLException
      从此 URI 构造一个 URL。

      这个便捷方法的工作原理就好像调用它等同于在首先检查此 URI 是绝对的之后评估表达式 new URL(this.toString())

      返回:
      从此 URI 构造的 URL
      抛出:
      IllegalArgumentException - 如果这个 URL 不是绝对的
      MalformedURLException - 如果找不到 URL 的协议处理程序,或者在构建 URL 时发生其他错误
    • getScheme

      public String  getScheme()
      返回此 URI 的方案组件。

      URI 的方案组件(如果已定义)仅包含字母数字类别和字符串 "-.+" 。方案总是以alpha特点。

      URI 的方案组件不能包含转义的八位字节,因此该方法不执行任何解码。

      返回:
      此 URI 的方案组件,如果方案未定义,则为 null
    • isAbsolute

      public boolean isAbsolute()
      判断此 URI 是否是绝对的。

      当且仅当 URI 具有方案组件时,它才是绝对的。

      返回:
      true 当且仅当此 URI 是绝对的
    • isOpaque

      public boolean isOpaque()
      告知此 URI 是否不透明。

      当且仅当 URI 是绝对的并且其特定于方案的部分不以斜杠字符 ('/') 开头时,URI 才是不透明的。一个不透明的 URI 有一个方案,一个特定于方案的部分,可能还有一个片段;所有其他组件均未定义。

      返回:
      true 当且仅当此 URI 是不透明的
    • getRawSchemeSpecificPart

      public String  getRawSchemeSpecificPart()
      返回此 URI 的原始方案特定部分。特定于方案的部分永远不会是未定义的,尽管它可能是空的。

      URI 的方案特定部分仅包含合法的 URI 字符。

      返回:
      此 URI 的原始方案特定部分(从不 null
    • getSchemeSpecificPart

      public String  getSchemeSpecificPart()
      返回此 URI 的已解码方案特定部分。

      此方法返回的字符串与 getRawSchemeSpecificPart 方法返回的字符串相同,只是所有转义八位字节序列都是 解码

      返回:
      此 URI 的解码方案特定部分(从不 null
    • getRawAuthority

      public String  getRawAuthority()
      返回此 URI 的原始授权组件。

      URI 的权限组件(如果已定义)仅包含商业字符 ('@') 和毫无保留, 点点, 逃脱, 和其他类别。如果授权是基于服务的,那么它被进一步限制为具有有效的用户信息、主机和端口组件。

      返回:
      此 URI 的原始权限组件,如果权限未定义,则为 null
    • getAuthority

      public String  getAuthority()
      返回此 URI 的解码授权组件。

      此方法返回的字符串与 getRawAuthority 方法返回的字符串相同,只是所有转义八位字节序列都是 解码

      返回:
      此 URI 的解码权限组件,如果权限未定义,则为 null
    • getRawUserInfo

      public String  getRawUserInfo()
      返回此 URI 的原始用户信息组件。

      URI 的用户信息部分(如果已定义)仅包含毫无保留, 点点, 逃脱, 和其他类别。

      返回:
      此 URI 的原始用户信息组件,如果用户信息未定义,则为 null
    • getUserInfo

      public String  getUserInfo()
      返回此 URI 的已解码用户信息组件。

      此方法返回的字符串与 getRawUserInfo 方法返回的字符串相同,只是所有转义八位字节序列都是 解码

      返回:
      此 URI 的已解码用户信息组件,如果用户信息未定义,则为 null
    • getHost

      public String  getHost()
      返回此 URI 的主机组件。

      URI 的主机组件(如果已定义)将具有以下形式之一:

      • 由一个或多个组成的域名标签由句点字符 ('.') 分隔,可以选择后跟一个句点字符。每个标签包括字母数字字符以及连字符 ('-'),尽管连字符永远不会作为标签中的第一个或最后一个字符出现。由两个或多个标签组成的域名最右边的标签以alpha特点。

      • 形式的点分四组 IPv4 地址数字+. 数字+. 数字+. 数字+ ,其中没有数字序列长于三个字符,并且没有序列的值大于 255。

      • IPv6 地址括在方括号('['']')中,由十六进制数字、冒号字符(':')和可能的嵌入式 IPv4 地址组成。 RFC 2373:IPv6 寻址架构 中指定了 IPv6 地址的完整语法。

      URI 的主机组件不能包含转义的八位字节,因此此方法不执行任何解码。
      返回:
      此 URI 的主机组件,如果主机未定义,则为 null
    • getPort

      public int getPort()
      返回此 URI 的端口号。

      URI 的端口组件(如果已定义)是一个非负整数。

      返回:
      此 URI 的端口组件,如果端口未定义,则为 -1
    • getRawPath

      public String  getRawPath()
      返回此 URI 的原始路径组件。

      URI 的路径部分(如果已定义)仅包含斜杠字符 ('/')、commercial-at 字符 ('@') 和毫无保留, 点点, 逃脱, 和其他类别。

      返回:
      此 URI 的路径组件,如果路径未定义,则为 null
    • getPath

      public String  getPath()
      返回此 URI 的解码路径组件。

      此方法返回的字符串与 getRawPath 方法返回的字符串相同,只是所有转义八位字节序列都是 解码

      返回:
      此 URI 的解码路径组件,如果路径未定义,则为 null
    • getRawQuery

      public String  getRawQuery()
      返回此 URI 的原始查询组件。

      URI 的查询组件(如果已定义)仅包含合法的 URI 字符。

      返回:
      此 URI 的原始查询组件,如果查询未定义,则为 null
    • getQuery

      public String  getQuery()
      返回此 URI 的解码查询组件。

      此方法返回的字符串与 getRawQuery 方法返回的字符串相同,只是所有转义八位字节序列都是 解码

      返回:
      此 URI 的解码查询组件,如果查询未定义,则为 null
    • getRawFragment

      public String  getRawFragment()
      返回此 URI 的原始片段组件。

      URI 的片段组件(如果已定义)仅包含合法的 URI 字符。

      返回:
      此 URI 的原始片段组件,如果片段未定义,则为 null
    • getFragment

      public String  getFragment()
      返回此 URI 的解码片段组件。

      此方法返回的字符串与 getRawFragment 方法返回的字符串相同,只是所有转义八位字节序列都是 解码

      返回:
      此 URI 的解码片段组件,如果片段未定义,则为 null
    • equals

      public boolean equals(Object  ob)
      测试此 URI 是否与另一个对象相等。

      如果给定对象不是 URI,则此方法立即返回 false

      两个 URI 被认为是相等的要求要么都是不透明的,要么都是分层的。它们的方案要么都未定义,要么不分大小写相等。它们的片段必须要么都是未定义的,要么是相等的。

      两个不透明的 URI 被认为是相等的,它们特定于方案的部分必须相等。

      对于被视为相等的两个分层 URI,它们的路径必须相等,并且它们的查询必须都未定义或相等。它们的权限必须要么都是未定义的,要么都是基于注册表的,要么都是基于服务的。如果它们的权限是定义的并且是基于注册表的,那么它们必须是平等的。如果它们的权限已定义并且是基于服务的,那么它们的主机无论大小写都必须相等,它们的端口号必须相等,并且它们的用户信息组件也必须相等。

      当测试两个 URI 的用户信息、路径、查询、片段、权限或方案特定部分是否相等时,比较这些组件的原始形式而不是编码形式,并且比较转义八位字节的十六进制数字而不考虑案例。

      此方法满足Object.equals 方法的一般契约。

      重写:
      equals 在类 Object
      参数:
      ob - 此对象要与之比较的对象
      返回:
      true 当且仅当给定对象是与此 URI 相同的 URI
      参见:
    • hashCode

      public int hashCode()
      返回此 URI 的哈希码值。散列码基于 URI 的所有组件,并满足 Object.hashCode 方法的一般约定。
      重写:
      hashCode 在类 Object
      返回:
      此 URI 的哈希码值
      参见:
    • compareTo

      public int compareTo(URI  that)
      将此 URI 与另一个必须是 URI 的对象进行比较。

      当比较两个 URI 的相应组件时,如果一个组件未定义而另一个组件已定义,则认为第一个小于第二个。除非另有说明,否则字符串组件根据 String.compareTo 方法定义的自然、区分大小写的顺序进行排序。受编码影响的字符串组件通过比较它们的原始形式而不是它们的编码形式来比较,并且比较转义八位字节的十六进制数字而不考虑大小写。

      URI 的顺序定义如下:

      • 两个具有不同方案的 URI 根据其方案的顺序进行排序,而不考虑大小写。

      • 分层 URI 被认为小于具有相同方案的不透明 URI。

      • 两个具有相同方案的不透明 URI 根据其方案特定部分的顺序进行排序。

      • 两个具有相同方案和方案特定部分的不透明 URI 根据其片段的顺序进行排序。

      • 具有相同方案的两个分层 URI 根据其权限组件的顺序进行排序:

        • 如果两个权限组件都是基于服务的,那么 URI 将根据它们的用户信息组件进行排序;如果这些组件相同,则 URI 将根据其主机的顺序进行排序,而不考虑大小写;如果主机相同,则 URI 将根据其端口的顺序进行排序。

        • 如果一个或两个权限组件是基于注册表的,则 URI 将根据其权限组件的顺序进行排序。

      • 最后,两个具有相同方案和权限组件的分层 URI 根据其路径的顺序进行排序;如果它们的路径相同,则根据查询的顺序对它们进行排序;如果查询相同,则根据片段的顺序对它们进行排序。

      此方法满足Comparable.compareTo 方法的一般契约。

      指定者:
      compareTo 在接口 Comparable<URI>
      参数:
      that - 此 URI 要与之比较的对象
      返回:
      负整数、零或正整数,因为此 URI 小于、等于或大于给定 URI
      抛出:
      ClassCastException - 如果给定对象不是 URI
    • toString

      public String  toString()
      以字符串形式返回此 URI 的内容。

      如果此 URI 是通过调用此类中的构造函数之一创建的,则返回一个字符串,该字符串等效于原始输入字符串,或者等效于从原始给定组件计算的字符串(视情况而定)。否则,此 URI 是通过规范化、解析或相对化创建的,因此根据 RFC 2396 部分 5.2,步骤 7 中指定的规则,从该 URI 的组件构造一个字符串。

      重写:
      toString 在类 Object
      返回:
      此 URI 的字符串形式
    • toASCIIString

      public String  toASCIIString()
      将此 URI 的内容作为 US-ASCII 字符串返回。

      如果此 URI 中不包含任何字符其他category 那么调用此方法将返回与调用 toString 方法相同的值。否则,此方法的工作方式就好像调用该方法然后encoding结果一样。

      返回:
      此 URI 的字符串形式,根据需要进行编码,以便它仅包含 US-ASCII 字符集中的字符