java.net
類 URI
java.net.URI
所有已實現的接口：
public final class URI
extends Object
implements Comparable<URI>, Serializable
表示一個統一資源標識符 (URI) 引用。
除了以下提到的一些細微不同之處外，此類的實例代表一個 URI 引用，這在以下文檔中定義：RFC 2396: Uniform ResourceIdentifiers (URI):Generic Syntax；在此文件中對其內容又進行了修正：RFC 2732:Format forLiteral IPv6 Addresses in URLs。字面值 IPv6 地址格式還支持 scope_ids。scope_ids 的語法和用法在此處描述。此類提供了用於從其組成部分或通過解析其字符串形式創建 URI 實例的構造方法、用於訪問實例的各個不同組成部分的方法，以及用於對 URI 實例進行規范化、解析和相對化的方法。此類的實例不可變。
URI 語法和組成部分
在最高級別上，字符串形式的 URI 引用（以下簡寫為"URI"）語法如下
[scheme:]scheme-specific-part[#fragment]
其中，方括號 [...] 用於描述可選組成部分，字符 :和 #代表它們自身。
絕對 URI 指定了方案(scheme)；非絕對的 URI 稱為相對URI。URI 還可以根據其是否為不透明的 或分層的 進行分類。
不透明 URI 為絕對 URI，其特定於方案的部分不是以斜線字符 ('/') 開始。不透明 URI 無法進行進一步解析。下面是不透明 URI 的一些示例：
| mailto:java-net@java.sun.com |
|
| news:comp.lang.java |
|
| urn:isbn:096139210x |
|
分層 URI 或者為絕對 URI（其特定於方案的部分以斜線字符開始），或者為相對 URI，即不指定方案的 URI。下面是分層 URI 的一些示例：
http://java.sun.com/j2se/1.3/
docs/guide/collections/designfaq.html#28
http://www.cnblogs.com/../demo/jfc/SwingSet2/src/SwingSet2.java
file:///~/calendar
分層 URI 還要按照下面的語法進行進一步的解析
[scheme:][//authority][path][?query][#fragment]
其中，:、/、?和 #代表它們自身。分層 URI 的特定於方案的部分包含方案和片段部分之間的字符。
分層 URI 的授權組成部分（如果指定）為基於服務器的 或基於注冊表的。基於服務器的授權按照如下眾所周知的語法進行解析：
[user-info@]host[:port]
其中，字符 @和 :代表它們自身。幾乎當前使用的所有 URI 方案都是基於服務器的。不能采用這種方式解析的授權組成部分被視為基於注冊表的。
如果分層 URI 的路徑組成部分以斜線字符 ('/') 開始，則稱此 URI 本身為絕對的；否則它為相對的。分層 URI 或者為絕對的，或者指定了授權的路徑，它始終為絕對的。
如上所述，URI 實例具有以下九個組成部分：
| 組成部分 |
類型 |
| 方案 |
String |
| 特定於方案的部分 |
String |
| 授權 |
String |
| 用戶信息 |
String |
| 主機 |
String |
| 端口 |
int |
| 路徑 |
String |
| 查詢 |
String |
| 片段 |
String |
在給定實例中，任何特殊組成部分都或者為未定義的，或者為已定義的，並且有不同的值。未定義的字符串組成部分由 null 表示，未定義的整數組成部分由 -1 表示。已定義的字符串組成部分的值可以為空字符串；這與未定義的組成部分不等效。
實例中特定的組成部分是已定義的還是未定義的取決於所代表的 URI 類型。絕對 URI 具有方案組成部分。不透明的 URI 具有一個方案、一個特定於方案的部分，以及可能會有一個片段，但是沒有其他組成部分。分層 URI 總是有一個路徑（盡管可能為空）和一個特定於方案的部分（它至少包含一個路徑），還可以包含任何其他組成部分。如果有授權組成部分且它又是基於服務器的，則主機組成部分將被定義，也有可能定義用戶信息和端口組成部分。
針對 URI 實例的運算
此類支持的主要運算有規范化、解析 和相對化 運算。
規范化 是將分層 URI 的路徑組成部分中的不必要的"." 和 ".." 部分移除的過程。每個 "." 部分都將被移除。".." 部分也被移除，除非它前面有一個非 ".." 部分。規范化對不透明 URI 不產生任何效果。
解析 是根據另一個基本 URI 解析某個 URI 的過程。得到的 URI 由兩個 URI 組成部分構造，構造方式由 RFC 2396 指定，從基本 URI 取出原始 URI 中未指定的組成部分。對於分層 URI，原始的路徑根據基本路徑進行解析，然后進行規范化。例如，解析以下 URI
docs/guide/collections/designfaq.html#28 (1)
根據基本 URI http://java.sun.com/j2se/1.3/ 解析，結果為 URI
http://java.sun.com/j2se/1.3/docs/guide/collections/designfaq.html#28
解析相對 URI
http://www.cnblogs.com/../demo/jfc/SwingSet2/src/SwingSet2.java (2)
根據此結果應生成
http://java.sun.com/j2se/1.3/demo/jfc/SwingSet2/src/SwingSet2.java
支持對絕對和相對 URI，以及分層 URI 的絕對和相對路徑的解析。根據任何其他 URI 對 URI file:///~calendar 進行解析只能生成原始的 URI，因為它是絕對路徑。根據相對基礎 URI (1) 解析相對 URI (2) 將生成規范的但依然是相對的 URI
demo/jfc/SwingSet2/src/SwingSet2.java
最后，相對化 是解析的逆過程：對於任何兩個規范的 URI u 和 v，
u.relativize(u.resolve(v)).equals(v)和
u.resolve(u.relativize(v)).equals(v)。
此運算在下面的場合非常有用：構造一個包含 URI 的文檔，該URI 必須盡可能是根據文檔的基本 URI 建立的相對 URI。例如，相對化 URI
http://java.sun.com/j2se/1.3/docs/guide/index.html
根據基本 URI
http://java.sun.com/j2se/1.3
生成了相對 URI docs/guide/index.html。
字符分類
RFC 2396 精確指出 URI 引用中的各個不同組成部分允許使用的字符。以下分類大部分取自該規范，這些約束的用法描述如下：
| alpha |
US-ASCII 字母字符，'A' 到 'Z' 以及 'a' 到 'z' |
| digit |
US-ASCII 十進制數字符，'0' 到 '9' |
| alphanum |
所有 alpha和 digit字符 |
| unreserved |
所有 alphanum字符及字符串 "_-!.~'()*" 中包含的字符 |
| punct |
字符串 ",;:$&+=" 中包含的字符 |
| reserved |
所有 punct字符及字符串 "?/[]@" 中包含的字符 |
| escaped |
轉義八位組，即三部分組合：百分號 ('%') 后跟兩個十六進制數（'0'-'9'、'A'-'F' 和 'a'-'f'） |
| other |
未包含在 US-ASCII 字符集中的 Unicode 字符不是控制字符（根據 Character.isISOControl 方法），並且不是空格字符（根據 Character.isSpaceChar 方法）（與 RFC 2396 有些出入，RFC 2396 限制為 US-ASCII） |
全部合法 URI 字符集包含 unreserved、reserved、escaped和 other字符。
轉義八位組、引用、編碼和解碼
RFC 2396 允許用戶信息、路徑、查詢和片段組成部分中包含轉義八位組。轉義在 URI 中實現兩個目的：
- 當要求 URI 不能包含任何 other 字符以嚴格遵守 RFC 2396 時，需要對非 US-ASCII 字符進行編碼。
- 要引用 組成部分中的非法字符。用戶信息、路徑、查詢和片段組成部分在判斷哪些字符合法哪些字符非法上稍有不同。
在此類中由三個相關的運算實現了這兩個目的：
- 字符的編碼 方式是，用代表該字符在 UTF-8 字符集中的字符的轉義八位組序列取代該字符。例如，歐元符號 ('\u20AC') 編碼后為 "%E2%82%AC"。（與 RFC 2396 有些出入，RFC 2396 未指定任何特殊字符集）。
- 非法字符通過簡單地對它進行編碼來引用。例如，空格字符，用 "%20" 取代它來進行引用。UTF-8 包含 US-ASCII，因此對於 US-ASCII 字符，此轉換具有的效果與 RFC 2396 的要求相同。
- 對轉義八位組序列進行解碼 的方法是，用它所代表的 UTF-8 字符集中的字符的序列將它取代。UTF-8 包含 US-ASCII，因此解碼具有對引用的任何 US-ASCII 字符取消引用的效果，以及對任何編碼的非 US-ASCII 字符進行解碼的效果。如果在對轉義八位組進行解碼時出現解碼錯誤，則出錯的八位組用 Unicode 替換字符 '\uFFFD' 取代。
這些運算在此類的構造方法和方法中公開，如下所示：
- 單參數構造方法要求對參數中的任何非法字符都必須引用，並保留出現的任何轉義八位組和 other字符。
- 多參數構造方法根據其中出現的組成部分的需要對非法字符進行引用。百分號字符 ('%') 始終通過這些構造方法引用。任何 other字符都將被保留。
- getRawUserInfo、getRawPath、getRawQuery、getRawFragment、getRawAuthority 和 getRawSchemeSpecificPart 方法以原始形式返回它們的相應組成部分的值，不解釋任何轉義八位組。由這些方法返回的字符串有可能包含轉義八位組和 other字符，但不包含任何非法字符。
- getUserInfo、getPath、getQuery、getFragment、getAuthority 和 getSchemeSpecificPart 方法解碼相應的組成部分中的任何轉義八位組。由這些方法返回的字符串有可能包含 other字符和非法字符，但不包含任何轉義八位組。
- toString 返回帶所有必要引用的 URI 字符串，但它可能包含 other 字符。
- toASCIIString 方法返回不包含任何 other字符的、完全引用的和經過編碼的 URI 字符串。
標識
對於任何 URI u，下面的標識有效
new URI(u.toString()).equals(u) .
對於不包含冗余語法的任何 URI u，比如在一個空授權前面有兩根斜線（如 file:///tmp/）和主機名后面跟一個冒號但沒有端口（如http://java.sun.com:），以及除必須引用的字符之外不對字符編碼的情況，下面的標識也有效：
new URI(u.getScheme()、
u.getSchemeSpecificPart()、
u.getFragment())
.equals(u)
在所有情況下，以下標識有效
new URI(u.getScheme()、
u.getUserInfo()、 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 還包括一個子類，即統一資源名稱 (URN)，它命名資源但不指定如何定位資源。上面的 mailto、news 和 isbn URI 都是URN 的示例。
URI 和 URL 概念上的不同反映在此類和 URL 類的不同中。
此類的實例代表由 RFC 2396 定義的語法意義上的一個 URI 引用。URI 可以是絕對的，也可以是相對的。對 URI 字符串按照一般語法進行解析，不考慮它所指定的方案（如果有）不對主機（如果有）執行查找，也不構造依賴於方案的流處理程序。相等性、哈希計算以及比較都嚴格地根據實例的字符內容進行定義。換句話說，一個 URI 實例和一個支持語法意義上的、依賴於方案的比較、規范化、解析和相對化計算的結構化字符串差不多。
作為對照，URL 類的實例代表了 URL 的語法組成部分以及訪問它描述的資源所需的信息。URL 必須是絕對的，即它必須始終指定一個方案。URL 字符串按照其方案進行解析。通常會為 URL 建立一個流處理程序，實際上無法為未提供處理程序的方案創建一個 URL 實例。相等性和哈希計算依賴於方案和主機的 Internet 地址（如果有）；沒有定義比較。換句話說，URL 是一個結構化字符串，它支持解析的語法運算以及查找主機和打開到指定資源的連接之類的網絡 I/O 操作。
從以下版本開始：
1.4
另請參見：
RFC 2279: UTF-8, a transformationformat of ISO 10646,
RFC 2373: IPv6 AddressingArchitecture,
RFC 2396: Uniform ResourceIdentifiers (URI): Generic Syntax,
RFC 2732: Format for LiteralIPv6 Addresses in URLs,
URISyntaxException,序列化表格
|
|
|
| URI(String scheme, String ssp, String fragment) |
|
| URI(String scheme, String userInfo, String host, int port, String path, String query, String fragment) |
|
| URI(String scheme, String host, String path, String fragment) |
|
| URI(String scheme, String authority, String path, String query, String fragment) |
|
| 方法摘要 |
|
| int |
|
| static URI |
|
| boolean |
|
| getAuthority() |
|
| getFragment() |
|
| getHost() |
|
| getPath() |
|
| int |
getPort() |
| getQuery() |
|
| getRawAuthority() |
|
| getRawFragment() |
|
| getRawPath() |
|
| getRawQuery() |
|
| getRawSchemeSpecificPart() |
|
| getRawUserInfo() |
|
| getScheme() |
|
| getSchemeSpecificPart() |
|
| getUserInfo() |
|
| int |
hashCode() |
| boolean |
isAbsolute() |
| boolean |
isOpaque() |
| normalize() |
|
| parseServerAuthority() |
|
| relativize(URI uri) |
|
| toASCIIString() |
|
| toString() |
|
| toURL() |
|
| 從類 java.lang.Object 繼承的方法 |
| clone, finalize, getClass, notify, notifyAll, wait, wait, wait |
| 構造方法詳細信息 |
public URI(String str)
throws URISyntaxException
通過解析給定的字符串構造一個URI。
此構造方法解析給定字符串的方式與 RFC 2396 的附錄 A 中指定的語法非常相似，除了以下細微不同：
· 只要空的授權組成部分后面帶一個非空路徑、一個查詢組成部分，或一個片段組成部分，就允許使用該空授權組成部分。這樣就可以對類似 "file:///foo/bar" 的 URI 進行解析，這樣做似乎是 RFC 2396 的意願，盡管其語法不允許這樣。如果授權組成部分為空，則用戶信息、主機和端口組成部分都是未定義的。
· 允許空的相對路徑；這似乎是RFC 2396 的意願，盡管語法不允許這樣。此細微不同帶來的主要后果是，單獨的片段（如"#foo"）將作為帶空路徑和給定片段的相對 URI 進行解析，並可根據基本 URI 進行有效的解析。
· 對主機組成部分中的 IPv4 地址進行嚴格的解析，正如RFC 2732 指定的一樣：點號分隔的由四部分組成的地址的每個元素都必須包含不超過三個十進制數字。每個元素被約束為值不能大於 255。
· 主機組成部分中的主機名如果只包含一個單獨的域標簽，則允許其以 alphanum字符開始。這似乎是 RFC 2396 的 3.2.2 節的意願，盡管其語法不允許這樣。此細微不同帶來的結果是，分層 URI 的授權組成部分（比如 s://123）將作為基於服務器的授權進行解析。
· 主機組成部分允許使用 IPv6 地址。IPv6 地址必須括在方括號 ('[' 和 ']') 中，正如 RFC 2732 指定的一樣。IPv6 地址本身必須按照 RFC 2373 進行解析。IPv6 地址進一步約束為只能描述不超過十六個字節的地址信息，該約束在 RFC 2373隱式給出，沒有在語法中明確說明。
· 只要 RFC 2396 允許轉義八位組，就允許使用其他類別中的字符，即用戶信息、路徑、查詢和片段組成部分以及授權組成部分（如果授權是基於注冊表的）中的內容。這樣，除了 US-ASCII 字符集中的字符，URI 中還可以包含 Unicode 字符。
參數：
str - 要解析為 URI 的字符串
拋出：
NullPointerException - 如果 str 為 null
URISyntaxException - 如果給定字符串違背 RFC 2396，正如上述細微不同的補充
URI
public URI(String scheme,
String userInfo,
String host,
intport,
String path,
String query,
String fragment)
throws URISyntaxException
根據給定的組成部分構造一個分層URI。
如果給定了方案，則路徑（如果也給定）必須為空或以斜線字符 ('/') 開始。否則通過為相應的參數傳入 null，或者在 port 參數的情況下，傳入 -1，新 URI 的組成部分可能保留為未定義。
此構造方法首先根據 RFC2396 中的 5.2 節的步驟 7 指定的規則從給定的組成部分構建一個 URI 字符串：
1. 起初，結果字符串為空。
2. 如果給定了方案，則將方案添加到結果后面，后面再加一個冒號 (':') 字符。
3. 如果給定了用戶信息、主機或端口，則添加 "//" 字符串。
4. 如果給定了用戶信息，則添加該信息，之后是“商用 at”字符 ('@')。任何不屬於unreserved、punct、escaped或 other類別的字符都應該進行 引用。
5. 如果給定了主機，則添加該主機。如果主機為字面值 IPv6 地址但未括在方括號 ('[' 和 ']') 中，則添加方括號。
6. 如果給定了端口名，則添加一個冒號字符 (':')，之后是十進制形式的端口號。
7. 如果給定了路徑，則添加該路徑。任何不屬於 unreserved、punct、escaped或 other類別的字符，以及不等於斜線字符 ('/') 或“商用 at”字符 ('@') 的字符都應該進行引用。
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 的組成部分可能保留為未定義。
該構造方法首先根據 RFC2396 的 5.2 節的步驟 7 指定的規則從給定組成部分構建一個 URI 字符串：
1. 起初，結果字符串為空。
2. 如果給定了方案，則將方案添加到結果后面，后面再加一個冒號 (':')字符。
3. 如果給定了授權，則添加"//" 字符串，之后是授權。如果授權包含一個字面值 IPv6 地址，則該地址必須括在方括號 ('[' 和 ']') 中。任何不屬於 unreserved、punct、escaped或 other類別的字符，以及不等於“商用 at”字符 ('@') 的字符都應該進行引用。
4. 如果給定了路徑，則添加該路徑。任何不屬於 unreserved、punct、escaped或 other類別的字符，以及不等於斜線字符 ('/') 或“商用 at”字符 ('@') 的字符都應該進行引用。
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
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
public static URI create(String str)
通過解析給定的字符串創建 URI。
此便捷工廠方法的工作方式類似於調用 URI(String)構造方法；由該構造方法拋出的任何 URISyntaxException 都被捕獲，並包裝到一個新的 IllegalArgumentException 對象中，然后拋出此對象。
此方法的使用場合是：已知給定的字符串是合法的 URI（例如，程序中聲明的 URI 常量），該字符串無法這樣解析時將被視為編程錯誤。當 URI 從用戶輸入或從其他易於引起錯誤的源構造時，應該使用直接拋出URISyntaxException 的構造方法。
參數：
str - 要解析為 URI 的字符串
返回：
新的 URI
拋出：
NullPointerException - 如果 str 為 null
IllegalArgumentException - 如果給定的字符串違背 RFC 2396
public URI parseServerAuthority()
throws URISyntaxException
嘗試將此 URI 的授權組成部分（如果已定義）解析為用戶信息、主機和端口組成部分。
如果此 URI 的授權組成部分已識別為基於服務器的，則可斷定它已經被解析為用戶信息、主機和端口組成部分。在這種情況下，或者如果此 URI 無任何授權組成部分，此方法只返回此 URI。
否則，此方法會多次嘗試將授權組成部分解析為用戶信息、主機、端口組成部分，並拋出一個描述授權組成部分為何無法用此方法解析的異常。
提供此方法是因為 RFC2396 中指定的常規 URI 語法無法區分非法的基於服務器的授權和合法的基於注冊表的授權。因此，必須把前者的某些實例看作后者的實例。例如，URI 字符串 "//foo:bar" 中的授權組成部分，並不是一個合法的基於服務器的授權，但卻是一個合法的基於注冊表的授權。
在許多一般情況下，例如，當已知正常的 URI 為 URN 或 URL 時，所使用的分層 URI 總是基於服務器的。因此，它們要么同樣被解析，要么同樣被視為錯誤。在這種情況下，類似如下語句
URI u = newURI(str).parseServerAuthority();
可用於確保 u在以下情況始終引用一個 URI：它有一個授權組成部分、一個基於服務器的授權以及適當的用戶信息、主機和端口組成部分。調用此方法還可確保授權無法用相應的方法解析時，能夠根據拋出的異常發出適當的診斷消息。
返回：
其授權字段已作為基於服務器的授權解析的 URI
拋出：
URISyntaxException - 如果此 URI 的授權部分已定義，但是按照 RFC2396 不能解析為基於服務器的授權
public URI normalize()
規范化此 URI 的路徑。
如果此 URI 為不透明的，或者其路徑已經是規范形式，則返回此URI。否則，將構造一個新的 URI，它與此 URI 基本相同，只有路徑是通過規范化此 URI 的路徑計算得出的，規范化的方式與 RFC 2396 的 5.2 節的步驟 6 的子步驟 c 到 f 一致；即：
1. 移除所有 "."部分。
2. 如果".." 部分的前面有一個非 ".." 部分，則這兩個部分都被移除。重復此步驟，直至不適合以上條件。
3. 如果路徑為相對的，並且如果它的第一個部分包含一個冒號字符 (':')，則預先考慮一個 "." 部分。這防止具有諸如 "a:b/c/d" 這樣的路徑的相對 URI 在后續被重新解析為具有方案 "a" 和特定於方案的部分 "b/c/d" 的不透明 URI。（與 RFC 2396 有些出入)
如果 ".." 前面沒有足夠的非".." 部分以允許移除 ".."，則規范化路徑將以一個或多個 ".." 部分開頭。如果已按照上述步驟 3 插入了一個路徑，規范化路徑將以一個 "." 部分開頭。否則，規范化路徑將不包含任何"." 或 ".." 部分。
返回：
一個與此 URI 相等的 URI，但其路徑為規范形式
根據此 URI 解析給定的 URI。
如果給定的 URI 已經是絕對的，或如果此 URI 是不透明的，則返回給定的 URI。
如果給定 URI 的片段組成部分已定義，其路徑組成部分為空，並且其方案、授權及查詢組成部分未定義，則返回一個 URL，它是由一個給定的片段及本 URL 的所有其他組成部分構成。這允許表示單獨片段引用的 URI（比如 "#foo"）根據基本 URI 進行有效的解析。
否則，此方法以與 RFC2396 的 5.2 節一致的方式構造新的分層 URI；即：
1. 用此 URI 的方案和給定 URI 的查詢和片段組成部分構造新的 URI。
2. 如果給定 URI 有一個授權組成部分，則新 URI 的授權和路徑都取自給定 URI。
3. 否則，新 URI 的授權組成部分從此 URI 復制，其路徑按如下方式計算：
a. 如果給定 URI 的路徑是絕對的，則新的 URI 路徑取自給定 URI。
b. 否則，給定 URI 的路徑是相對的，新的 URI 路徑根據此 URI 的路徑對給定 URI 的路徑進行解析而計算得出。方法為：除去此 URI 的路徑的最后一部分（如果有），將此 URI 路徑的其他所有部分與給定 URI 的路徑串聯起來，然后將得到的結果規范化（正如調用normalize方法一樣）。
當且僅當此 URI 為絕對的或者給定 URI 為絕對的，此方法的結果才是絕對的。
參數：
uri - 要根據此 URI 解析的 URI
返回：
結果 URI
拋出：
NullPointerException - 如果 uri 為 null
public URI resolve(String str)
解析給定的字符串，然后在此URI 的基礎上構造一個新的 URI。
此方法工作便捷，並與進行 resolve(URI.create(str))作用相同。
參數：
str - 要解析為 URI 的字符串
返回：
得到的 URI
拋出：
NullPointerException - 如果 str 為 null
IllegalArgumentException - 如果給定字符串違背 RFC 2396
public URI relativize(URI uri)
根據此 URI 將給定 URI 相對化。
根據此 URI 將給定的 URI 相對化按以下方式計算：
1. 如果此 URI 或給定 URI 是不透明的，或者如果兩個 URI 的方案和授權組成部分不相同，或者如果此 URI 的路徑不是給定 URI 的路徑前綴，則返回給定的 URI。
2. 否則，使用從給定 URI 獲取的查詢和片段組成部分，以及通過把此 URI 的路徑從給定 URL 的路徑開頭處移除而得到的路徑組成部分，構造新的相對分層 URL。
參數：
uri - 要根據此 URI 進行相對化的 URI
返回：
得到的 URI
拋出：
NullPointerException - 如果 uri 為 null
public URL toURL()
throws MalformedURLException
根據此 URI 構造一個 URL。
首先檢查得知此 URI 為絕對路徑后，此便捷方法的工作方式就好像調用它與對表達式 new URL(this.toString()) 進行計算是等效的。
返回：
根據此 URI 構造的 URL
拋出：
IllegalArgumentException - 如果此 URL 不是絕對的
MalformedURLException - 如果無法找到 URL 的協議處理程序，或者如果在構造 URL 時發生其他錯誤
public String getScheme()
返回此 URI 的方案組成部分。
URI 的方案組成部分（如果定義了）只包含 alphanum類別和字符串"-.+" 中的字符。方案始終以 alpha 字符開始。
URI 的方案組成部分不能包含轉義八位組，因此此方法不執行任何解碼操作。
返回：
此 URI 的方案組成部分，或者如果方案未定義，則返回 null
public boolean isAbsolute()
判斷此 URI 是否為絕對的。
當且僅當 URI 具有方案組成部分時，它才是絕對的。
返回：
當且僅當此 URI 是絕對的，才返回 true
public boolean isOpaque()
判斷此 URI 是否為不透明的。
當且僅當 URI 是絕對的且其特定於方案的部分不是以斜線字符('/') 開始時，此 URI 才是不透明的。不透明的 URI具有一個方案、一個特定於方案的部分，以及可能會有的一個片段；所有其他組成部分都是未定義的。
返回：
當且僅當此 URI 是不透明的，才返回 true
public String getRawSchemeSpecificPart()
返回此 URI 原始的、特定於方案的部分。特定於方案的部分永遠不會是未定義的，但它可能為空。
URI 的特定於方案的部分只包含合法的 URI 字符。
返回：
此 URI 的特定於方案的原始部分（從不為 null）
public String getSchemeSpecificPart()
返回此 URI 的特定於方案的解碼部分。
除了轉義八位組的所有序列都已解碼之外，此方法返回的字符串與 getRawSchemeSpecificPart方法返回的字符串相等。
返回：
此 URI 的特定於方案的解碼部分（從不為 null）
public String getRawAuthority()
返回此 URI 的原始授權組成部分。
URI 的授權組成部分（如果定義了）只包含“商用 at”字符 ('@') 和unreserved、punct、escaped和 other類別中的字符。如果授權是基於服務器的，則它被進一步約束為具有有效的用戶信息、主機和端口組成部分。
返回：
此 URI 的原始授權組成部分，如果授權未定義，則返回 null
public String getAuthority()
返回此 URI 的已解碼的授權組成部分。
除了轉義八位組的所有序列都已解碼之外，此方法返回的字符串與 getRawAuthority方法返回的字符串相等。
返回：
此 URI 的已解碼的授權組成部分，如果授權未定義，則返回 null
public String getRawUserInfo()
返回此 URI 的原始用戶信息組成部分。
URI 的用戶信息組成部分（如果定義了）只包含 unreserved、punct、escaped和 other類別中的字符。
返回：
此 URI 的原始用戶信息組成部分，如果用戶信息未定義，則返回 null
public String getUserInfo()
返回此 URI 的已解碼的用戶信息組成部分。
除了轉義八位組的所有序列都已解碼之外，此方法返回的字符串與 getRawUserInfo方法返回的字符串相等。
返回：
此 URI 的已解碼的用戶信息組成部分，如果用戶信息未定義，則返回 null
public String getHost()
返回此 URI 的主機組成部分。
URI 的主機組成部分（如果定義了）將具有以下形式之一：
· 由一個或多個由句點字符('.') 分隔的標簽 組成的域名，后面可以跟隨一個句點字符。每個標簽由 alphanum字符及連字符 ('-') 組成，但是連字符從不會出現在標簽的第一個或最后一個字符位置。由兩個或多個標簽組成的域名中最右邊的標簽以alpha字符開始。
· 點號分隔的由四部分組成的IPv4 地址，其形式為數字+.數字+.數字+.數字+，其中，數字 序列不超過三個字符，任何序列都不能大於 255。
· 包含在方括號 ('[' 和 ']') 中的 IPv6 地址，由十六進制數、冒號字符 (':') 和可能會有的一個嵌入式 IPv4 地址組成。IPv6 地址的完整語法在 RFC 2373:IPv6 AddressingArchitecture 中指定。
URI 的主機組成部分不能包含轉義八位組，因此此方法不執行任何解碼操作。
返回：
此 URI 的主機組成部分，如果主機未定義，則返回 null
public int getPort()
返回此 URI 的端口號。
URI 的端口組成部分（如果定義了）是一個非負整數。
返回：
此 URI 的端口組成部分，如果端口未定義，則返回 -1
public String getRawPath()
返回此 URI 的原始路徑組成部分。
URI 的路徑組成部分（如果定義了）只包含斜線字符 ('/')、“商用 at”字符 ('@') 以及 unreserved、punct、escaped和 other類別中的字符。
返回：
此 URI 的路徑組成部分，如果路徑未定義，則返回 null
public String getPath()
返回此 URI 的已解碼的路徑組成部分。
除了轉義八位組的所有序列都已解碼之外，此方法返回的字符串與 getRawPath方法返回的字符串相等。
返回：
此 URI 的已解碼的路徑組成部分，如果路徑未定義，則返回 null
public String getRawQuery()
返回此 URI 的原始查詢組成部分。
URI 的查詢組成部分（如果定義了）只包含合法的 URI 字符。
返回：
此 URI 的原始查詢組成部分，如果查詢未定義，則返回 null
public String getQuery()
返回此 URI 的已解碼的查詢組成部分。
除了轉義八位組的所有序列都已解碼之外，此方法返回的字符串與 getRawQuery方法返回的字符串相等。
返回：
此 URI 的解碼查詢組成部分，如果查詢未定義，則返回 null
public String getRawFragment()
返回此 URI 的原始片段組成部分。
URI 的片段組成部分（如果定義了）只包含合法的 URI 字符。
返回：
此 URI 的原始片段組成部分，如果片段未定義，則返回 null
public String getFragment()
返回此 URI 的已解碼的片段組成部分。
除了轉義八位組的所有序列都已解碼之外，此方法返回的字符串與 getRawFragment方法返回的字符串相等。
返回：
此 URI 的已解碼的片段組成部分，如果片段未定義，則返回 null
public boolean equals(Object ob)
測試此 URI 與另一對象的相等性。
如果給定的對象不是一個 URI，則此方法立即返回 false。
如果要使兩個 URI 相等，則要求兩者都是不透明的或都是分層的。兩者的方案必須都是未定義的或相等（不區分大小寫）。兩者的片段必須都是未定義的或相等。
如果要使兩個不透明的 URI 相等，則其特定於方案的部分必須相等。
如果要使兩個分層 URI 相等，則其路徑必須相等，並且其查詢必須都是未定義的或相等。兩者的授權必須都是未定義的，或者都是基於注冊表的，或者都是基於服務器的。如果其授權是定義的且都是基於注冊表的，則它們一定是相等的。如果其授權是定義的且都是基於服務器的，則其主機一定是相等的（不區分大小寫），其端口號一定是相等的，並且其用戶信息組成部分也一定相等。
測試兩個 URI 的用戶信息、路徑、查詢、片段、授權或特定於方案的部分是否相等時，比較的是這些組成部分的原始形式，而不是編碼后的形式，並且在比較轉義八位組的十六進制數字時，不區分大小寫。
此方法滿足 Object.equals方法的常規協定。
覆蓋：
參數：
ob - 此對象將與之比較的對象
返回：
當且僅當給定的對象是一個與此URI 相同的 URI 時，返回 true
另請參見：
public int hashCode()
返回此 URI 的哈希碼值。哈希碼基於所有的 URI 組成部分，且滿足 Object.hashCode方法的常規協定。
覆蓋：
返回：
此 URI 的哈希碼值
另請參見：
Object.equals(java.lang.Object),Hashtable
public int compareTo(URI that)
將此 URI 與另一個對象（也必須是 URI）進行比較。
比較兩個 URI 的相應組成部分時，如果其中一個組成部分是未定義的，而另一個是定義的，則認為第一個小於第二個。除非另外說明，字符串組成部分按照其自然的、區分大小寫的順序進行排序，正如在String.compareTo方法中定義的一樣。比較經過編碼的字符串組成部分時，應按照其原始形式進行比較，而不是經過編碼的形式。
URI 的排序定義如下：
· 兩個具有不同方案的 URI 按照其方案的順序進行排序，不區分大小寫。
· 分層 URI 視為小於具有相同方案的不透明 URI。
· 兩個具有相同方案的不透明 URI按照其特定於方案的部分的順序進行排序。
· 兩個具有相同方案和特定於方案的部分的不透明 URI 按照其段的順序進行排序。
· 兩個具有相同方案的分層 URI 按照其授權組成部分的順序進行排序：
· 如果兩個授權組成部分都是基於服務器的，則 URI 按其用戶信息組成部分進行排序；如果這些組成部分都相同，則 URI 按其主機的順序進行排序，不區分大小寫；如果主機相同，則 URI 按其端口的順序進行排序。
· 如果授權組成部分中有一個或兩個都是基於注冊表的，則 URI 按照其授權組成部分的順序進行排序。
· 最后，具有相同方案和授權組成部分的兩個分層 URI 按照其路徑的順序進行排序；如果其路徑相同，則按照其查詢的順序進行排序；如果查詢相同，則按照其段的順序進行排序。
此方法滿足 Comparable.compareTo方法的常規協定。
指定者：
接口 Comparable<URI> 中的 compareTo
參數：
that - 此 URI 將與之比較的對象
返回：
當此 URI 小於、等於或大於給定 URI 時，返回負整數、零或正整數
拋出：
ClassCastException - 如果給定對象不是一個 URI
public String toString()
以字符串形式返回此 URI 的內容。
如果此 URI 通過調用此類的構造方法之一創建，則視情況返回一個與原始輸入字符串，或與從原始給定組成部分計算得出的字符串相等的字符串。否則，將通過規范化、解析或相對化創建此 URI，並根據 RFC 2396 的 5.2 節第 7 步指定的規則從此URI 組成部分構造一個字符串。
覆蓋：
返回：
此 URI 的字符串形式
public String toASCIIString()
以 US-ASCII 字符串形式返回此 URI 的內容。
如果此 URI 未包含 other類別的任何字符，則調用此方法將返回的值與調用 toString方法返回的值相同。否則，此方法的工作方式類似於調用該方法，然后對結果進行編碼。
返回：
此 URI 的字符串形式，根據需要進行編碼以保證它只包含 US-ASCII 字符集中的字符