Java網絡編程之URI、URL研究專題二

　　最後一個組件是fragment盡管該組件作為URI的一部分出現但不是絕對的當使用URI進行某種檢索操作時後面執行操作的軟件使用fragment聚焦於軟件感興趣的資源部分（在該軟件成功檢索到資源的數據後）
　　
　　為了實際表現前面提到的組件信息可以使用下面的URI
　　
　　ftp://:/public/notes?text=shakespeare#hamlet
　　
　　上面的URI把ftp識別為大綱把:識別為基於服務器的授權機構（其中george是用戶信息是主機是端口）把/public/notes識別為路徑把text=shakespeare識別為查詢把hamlet識別為片斷
　　
　　本質上它是一個叫做george的用戶希望通過/public/notes路徑在服務器的端口上檢索shakespeare文本的hamlet信息在shakespeare成功的返回到該程序後程序定位hamlet段並把它呈獻給該用戶
　　
　　標准化可以通過目錄術語來理解假定目錄x直接位於根目錄之下x有子目錄a和bb有文件memotxta是當前目錄為了顯示memotxt中的內容（在微軟Windows下）你可能輸入type \x\\b\memotxt
　　
　　你也可能輸入type \x\a\\b\memotxt在這種情況下a和的出現是沒有必要的這兩種形式都不是最簡單的但是如果輸入\x\b\memotxt你就指定了最簡單的路徑了從根目錄開始訪問memotxt最簡單的\x\b\memotxt路徑就是標准化的路徑
　　
　　通常通過基本的和相對的URI訪問資源基本的URI是絕對的URI它唯一地標識了某種資源的名字空間而相對的URI標識了與基礎的URI相對的資源（與基本的URI不同相對的URI在某種資源的生存周期內可以永遠不需要改變）因為基本的和相對的URI都不能完整的識別某種資源有必要把兩種URI通過解析過程合並相反地通過相對化從合並的URI中提取相對的URI也是可行的
　　
　　注意
　　
　　不透明的URI與其它的URI不同它不服從標准化分解和相對化
　　
　　假定你把x://a/作為基礎的URI並把b/c作為相對的URI根據基礎URI分解這個相對的URI將產生x://a/b/c根據x://a/相對化x://a/b/c將產生b/c
　　
　　URI不能定位或讀取/寫入資源這是統一的資源定位器（URL）的任務URL是一種URI但是它的大綱組件是已知的網絡協議（簡稱協議）並且它把URI組件與某種協議處理程序（一種資源定位器和根據協議建立的約束規則與資源通訊的讀/寫機制）
　　
　　URI一般不能為資源提供持久不便的名稱這是統一的資源命名（URN）的任務URN也是一種URI但是全球唯一的持久不便的即使資源不在存在或不再使用
　　
　　使用URI
　　
　　網絡API通過提供了URI類（位於程序包中）使我們在源代碼層使用URI成為可能URI的構造函數建立了封裝URI的URI對象URI的方法建立URI對象
　　
　　如果授權機構組件是基於服務器的就分析它提取URI組件決定URI對象的URI是絕對的還是相對的決定URI對象的URI是不透明的還是分層的
　　
　　比較兩個URI對象中的URI標准化（normalize）URI對象的URI根據URI對象的基礎URI分解某個相對的URI以得到已分解的URI根據URI對象的基礎URI關聯某個已分解的URI以得到相對的URI把URI對象轉換為URL對象
　　
　　我們進一步查看URI類在它裡面有五個構造函數最簡單的是URI(String uri)這個構造函數把URI作為String類型的參數把URI分解為組件並把這些組件存儲在一個新的URI對象中
　　
　　如果String對象的URI（通過uri引用）違反了RFC 的語法規則其它的四個構造函數URI(String uri)將會產生一個URISyntaxException對象
　　
　　下面的代碼片斷演示了使用URI(String uri)建立封裝了一個簡單的URI組件的URI對象
　　
　　URI uri = new URI ();
From:http://tw.wingwit.com/Article/program/Java/hx/201311/25928.html