url與資源
本章我們將介紹以下內容:
- url語法菇怀,以及各種url組件的含義及其所做的工作咕痛;
- 很多web客戶端都支持url的快捷方式麻惶,包括相對url和自動擴展url;
- url編碼和字符規(guī)則宪拥;
- 支持各種因特網信息系統(tǒng)的常見url方案仿野;
- url的未來,包括urn-這種框架可以在對象從一處搬移到另一處時她君,保持穩(wěn)定的訪問名稱脚作。
2.1瀏覽因特網資源
url是瀏覽器尋找信息時所需要的資源位置。通過url人類和應用程序才能找到并共享因特網上大量的數(shù)據(jù)資源缔刹。url是人們對http和其它協(xié)議的常用訪問點鳖枕;一個人將瀏覽器指向一個url,瀏覽器會在幕后發(fā)送適當?shù)膮f(xié)議報文來獲取人們所期望的資源桨螺。
- url的第一部分稱為方案(scheme)說明了資源所使用的協(xié)議宾符,例如http協(xié)議。
- 第二部分是服務器的因特網地址灭翔,例如www.baidu.com魏烫。
- 其余部分指定了web服務器上的某個資源。例如/index.html
這一部分在第一章已經說過肝箱,在這里重復一下哄褒。
2.2url的語法
url提供了一種定位網上任意資源的手段,這些資源可以通過不同的方案(http煌张,ftp呐赡,smtp)來訪問,因此骏融,url語法會隨方案的不同而有所不同链嘀。
大多數(shù)的url語法都建立在這9個部分構成的通用格式上:
<scheme>://<user>:<password>@<host>:<port>/<path>;<params>?<query>#<frag>
組件 | 描述 |
---|---|
方案 | 訪問服務器以獲取資源時要使用那種協(xié)議 |
用戶 | 某些方案訪問資源時需要的用戶名 |
密碼 | 用戶名后面可能要包含的密碼中間由冒號分隔 |
主機 | 資源宿主服務器的主機名或點分ip地址 |
端口 | 宿主服務器正在監(jiān)聽的端口,很多方案都有默認端口號 |
路徑 | 服務器上的資源的本地名档玻,由一個斜杠與前面的url分隔開怀泊,路徑組件的語法與服務器和方案有關 |
參數(shù) | 某些方案會用到這個組件來指定輸入參數(shù),參數(shù)為名/值對误趴。url中可以包含多個參數(shù)字段霹琼,他們互相之間以及與路徑的其余部分用分號分隔 |
查詢 | 某些方案會用到這個組件傳遞參數(shù)以激活應用程序。查詢組件的內容沒有通用格式凉当。用字符枣申?將其與url的其它部分分隔開 |
片段 | 一小片或一部分資源的名字。引用對象時看杭,不會將frag字段傳遞給服務器忠藤,這個字段是客戶端內部使用的,通過字符#將其與其它部分分隔開 |
2.2.1方案-使用什么協(xié)議
方案是規(guī)定如何訪問指定資源的主要標識符泊窘,它會告訴負責解析url的應用程序應該使用什么協(xié)議熄驼。
方案組件必須以一個字母符號開頭,由第一個:將其與其余部分分隔開烘豹。方案名與大小寫無關瓜贾。
2.2.2主機與端口
要想在因特網上找到資源,應用程序要知道哪臺機器裝載了資源携悯,以及在那臺機器的什么地方可以找到對應能對目標資源訪問的服務器祭芦。url的主機和端口組件提供了這兩組信息。
主機組件標識了因特網上能夠訪問資源的宿主機器憔鬼。端口組件標識了服務器正在監(jiān)聽的網絡端口
2.2.3用戶名和密碼
更有趣的是用戶名和密碼組件龟劲,不少服務器要求輸入用戶名和密碼才允許訪問數(shù)據(jù),例如一個典型的ftp服務器轴或。
2.2.4路徑
url的路徑組件說明了資源位于服務器的什么地方昌跌。路徑通常像一個分級的文件系統(tǒng)路徑。例如用/將http url的路徑附件分成一些路徑段(path segment)每個路徑段都有自己的參數(shù)組件
2.2.5參數(shù)
負責解析url的應用程序需要這些協(xié)議參數(shù)來訪問資源照雁。否則另一端的服務器可能就不會為請求提供服務蚕愤,或者提供錯誤的服務
2.2.6查詢字符串
很多資源都是可以通過提問或進行查詢來縮小請求資源類型范圍的。例如數(shù)據(jù)庫饺蚊。按照常規(guī)萍诱,很多網關希望查詢字符串以一系列的名/值對的形式出現(xiàn),名/值對之間用字符&分隔開
2.2.7片段
有些資源類型污呼,除了資源級之外裕坊,還可以做進一步的劃分。為了引用部分資源或資源的一個片段燕酷,url支持使用片段(frag)表示一個資源內部的片段
http服務器通常只處理整個對象籍凝,而不是對象的片段,客戶端不能將片段傳送給服務器苗缩。瀏覽器從服務器獲得整個資源后静浴,會根據(jù)片段來顯示我們感興趣的部分
2.3url快捷方式
web客戶端可以理解并使用幾種url快捷方式。相對url是在某資源內部指定一個資源的邊界縮略方式挤渐。很多瀏覽器還支持url的自動擴展苹享,也就是用戶鍵入一個關鍵部分,然后由瀏覽器將其余部分填充起來
2.3.1相對url
url有兩種方式:絕對的和相對的浴麻。到目前為止得问,我們只見過絕對url中包含訪問得全部信息
另一方面,相對url是不完整的要從相對url中獲取訪問全部信息软免,就必須相對于另一個宫纬,被稱為其基礎的url進行解析。
相對url是url的一種便捷記法膏萧。如果你手工寫過html的話漓骚,可能就會發(fā)現(xiàn)相對url是多么便捷蝌衔。
1.基礎url
轉換處理的第一步就是找到基礎url◎蝓澹基礎url是作為相對url的參考點使用可以來自以下幾個地方噩斟。
- 在資源中現(xiàn)實提供
有些資源會顯式的指定基礎url。比如html文檔中可能會包含一個定義了基礎url的html標記<base>通過他來轉換那個html文檔中的所有相對url - 封裝資源的基礎url
如果在一個沒有顯示指定基礎url的資源中發(fā)現(xiàn)一個相對url - 沒有基礎url在某些情況下沒有基礎url這通常意味著你有一個相對url孤个,但有時可能只是是個不完整或損壞了的url剃允。
2.解析相對引用
前面我們介紹了url的基本組件和語法。要將相對url轉換為一個絕對url下一步要做的就是將相對url和基礎url花分成組件段齐鲤。
實際上斥废,這樣只是在解析url,但這種做法會將其劃分一個個組件因此通常會稱作分解(decomposing)url.只要將基礎和相對url劃分成了組件就可以應用算法來轉換了给郊。
2.3.2自動擴展url
有些瀏覽器會在用戶提交url之后牡肉,或者在用戶輸入的時候嘗試這自動擴展url。這就為用戶提供了一條捷徑:用戶不需要輸入完整的url淆九,因為瀏覽器會自動擴展荚板。
這些自動擴展特性有以下兩種方式。
主機名擴展
在主機名擴展中吩屹,只要有些小提示跪另,瀏覽器就可以在沒有幫助的情況下,將你輸入的主機名擴展為完整的主機名煤搜。歷史擴展
瀏覽器用來節(jié)省用戶輸入url時間的另一種技巧是免绿,將用戶訪問過的url歷史存儲起來,當你輸入url時擦盾,他們就可以將你輸入的ulr與歷史url前綴進行匹配嘲驾,并提供一些完整的選項供你選擇。
2.4令人頭疼的字符
url是可移植的(protable).他要統(tǒng)一的命名因特網上所有的資源迹卢,這也就意味著要通過各種不同的協(xié)議來傳送這些資源辽故。這些協(xié)議在傳輸數(shù)據(jù)時都會使用不同的機制。所以設計url腐碱,使其可以通過任意因特網協(xié)議安全的傳輸是很重要的誊垢。
安全傳輸意味著url傳輸不能丟失信息。有些協(xié)議症见,所使用的傳輸方法就會剝去一些特定的字符喂走。為了避開這些問題,url只能使用一些相對較小的通用的安全字母表中的字符谋作。
除了希望url刻意被所有因特網協(xié)議進行傳送外芋肠,設計者還希望url是可讀的。因此即使不可見遵蚜,不可打印的字符能夠穿過郵件協(xié)議帖池,從而稱為可移植的奈惑,也不能在url中使用。
url還得是完整的睡汹,這就使問題變得更加復雜了肴甸。url的設計者們認識到有時人們可能會希望url中包含除通用的安全字符外的二進制數(shù)據(jù)或字符。因此帮孔,需要有一種轉義機制雷滋,能夠將不安全的字符編碼為安全字符不撑,再進行傳輸文兢。
2.4.1url字符集
默認的計算機系統(tǒng)字符集通常都傾向于以英語為中心。從歷史上來看焕檬,很多計算機程序使用的都是us-ascll字符集姆坚。
由于ascll的歷史悠久,所以可移植性很好实愚。但是兼呵,它不支持在其他地方使用。
而且腊敲,有些url中還會包含二進制數(shù)據(jù)击喂。認識到對完整性的需求之后,url的設計者就將轉義序列集成進去了碰辅,通過轉義序列懂昂,就可以用ascll字符集的有限子集對任意字符之或數(shù)據(jù)進行編碼了,這樣就實現(xiàn)了可移植性和完整性没宾。
2.4.2編碼機制
為了避開安全字符集表示法帶來的限制凌彬,人們設計了一種編碼機制用來在url中表示不安全的字符。這種編碼機制就是通過一種“轉義”表示法來表示不安全的字符循衰。這種轉義表示法包含一個百分號铲敛,后面跟著兩個表示字符ascll碼的十六進制數(shù)。
2.4.3字符限制
有幾個字符被保留起來会钝,有著特殊含義伐蒋。有些字符不在定義的ascll課打印字符集中。還有些會與某些因特網網關協(xié)議產生混淆迁酸。因此不贊成使用咽弦。
字符 | 保留/受限 | |
---|---|---|
% | 保留作為編碼字符的轉義標志 | |
/ | 保留作為路徑組件分隔路徑段的定界符 | |
. | 保留在路徑組件中使用 | |
.. | 保留在路徑組件中使用 | |
# | 保留作為分段定界符使用 | |
? | 保留作為查詢字段定界符使用 | |
; | 保留作為參數(shù)定界符使用 | |
: | 保留作為方案、用戶/口令胁出、以及主機/端口組件的定界符使用 | |
$,+ | 保留 | |
@$= | 在某些方案上下文中有特殊含義型型,保留 | |
{}^~[]' | 由于各種方案上下文中有特殊含義,保留 | |
<>" | 不安全:這些字符在url范圍之外通常是有意義的全蝶,比如在文檔中對url自身進行定界闹蒜,所以應該對其進行編碼 | |
0x00-0x1f,0x7f | 受限寺枉,這些十六進制范圍內的字符都在ascll字符集的不可打印區(qū)間內 | |
>0x7f | 受限,十六進制再次范圍內的字符都不在ascll字符集的7位二進制范圍內 |
2.4.4另外一點說明
你可能感到奇怪绷落,為什么使用不安全的字符沒有什么不好的事姥闪。對于某些傳輸協(xié)議來說,使用其中的一些字符不會出現(xiàn)問題砌烁,但對于程序開發(fā)人員來說筐喳,對非安全字符進行編碼仍然是明智的。
應用程序要按照一定規(guī)范工作函喉”芄椋客戶端應用程序在其它應用程序發(fā)送任意url之前,最好把所有不安全的或受限字符進行轉換管呵。只要對所有不安全字符進行編碼梳毙,這個url就是可以在各應用之間共享的規(guī)范形式;也就無需操心其它應用程序會被字符的任何特殊含義迷惑了
最合適判斷是否需要對字符進行編碼的程序就是從用戶處獲得url的源端應用程序捐下。url的每個組件都會有自己的安全不安全字符账锹,那些字符是安全的與方案有關,因此只有從用戶那里接受url的應用程序才能夠判斷需要對那些字符進行編碼坷襟。
另外奸柬,另一種極端的做法就是應用程序對所有字符都進行編碼。盡管不建議這么做婴程,但也沒有強硬而嚴格的規(guī)則規(guī)定不能對安全字符進行編碼廓奕;但在實際的應用程序中,有些應用程序可能會假定不對安全字符進行編碼排抬,這么做的話可能會產生一些奇怪的破壞行為懂从。
有時,有些人會惡意的對額外的字符進行編碼蹲蒲,以繞過那些對url進行模式匹配的應用程序番甩,比如web過濾程序。
2.5方案的世界
方案 | 描述 |
---|---|
http | 超文本傳輸協(xié)議方案届搁,除了沒有用戶名和密碼之外缘薛,與通用的url格式相符。如果省略了端口卡睦,默認為80.基本格式:http://<host>:<port>/<path>?<query>#<frag> |
https | 方案https與http是一對宴胧,唯一的區(qū)別在于方案https使用了ssl加密。語法與http相同表锻,默認端口443. |
mailto | mailto url指向的是E-mail地址由于mail的行為與其它方案都不同恕齐,所以mailto url的格式與標準url的格式也有所不同,因特網mail地址的語法記錄在rfc833中瞬逊∠云纾基本格式:mailto:<rfc-822-addr-spec> |
ftp | 文件傳輸協(xié)議url可以用來從服務器下載或上傳文件仪或,并獲取ftp服務器上的目錄結構內容列表∈恐瑁基本格式:ftp://<user>:<password>@<host>:<port>:<params> |
rtsp,rtspu | rtsp url 是可以通過實時流傳輸協(xié)議(real time streaming protocol)解析的音/視頻媒體資源的標識符范删。rtspu中的u表示使用udp協(xié)議來獲取資源的】郊。基本格式:rspt(u)://<user>:<password>@<host>:<port>/<path> |
file | 表示指定一臺主機上可直接的文件到旦。各字段都采用通用格式。如果省略了主機名巨缘,就默認為正在使用url的本機地址添忘。基本格式:file://<host>/<path> |
news | 用來訪問一些特定的文章或新聞組带猴。他有一個很獨特的性質:news url自身包含的信息不足以對資源進行定位昔汉。新聞資源可以從多個服務器中獲得懈万,被稱為位置無關的拴清,因為他們的訪問不依賴服務器。news url保留字符@區(qū)分指向新聞組的news url和指向特定文章的news url会通】谟瑁基本格式:news:<newsgroup>,news:<news-article-id> |
telnet | 用于交互式訪問業(yè)務。他表示的并不是對象自身涕侈,而是可以通過telnet訪問的交互式程序沪停。基本格式:telnet://<user>:<password>@<host>:<port>/ |
2.6未來展望
url是一種非常有用的工具裳涛,命名現(xiàn)有對象木张,而且很方便的包含了一些新格式。url提供了可以在各種因特網協(xié)議共享的統(tǒng)一命名的機制端三。
這種方案的缺點在于一旦自愿被移走了舷礼,url也就不在有效了。為了解決這個問題郊闯,因特網工程任務組(internet engineering task force ietf)已經對一種名為統(tǒng)一資源名(urn)進行了研究妻献。
如果不是現(xiàn)在,那是什么時候
urn已經出現(xiàn)了一段時間团赁,但到現(xiàn)在為止還沒有投入使用育拨。從url到urn的標準化的工作很緩慢。url仍然有很大的能量欢摄,所以還要等待時機庸疾。