作者：
瞌睡龍
·
2013/06/19 18:54
URL格式：
scheme://[login[:password]@](host_name|host_address)[:port][/hierarchical/path/to/resource[?search_string][#fragment_id]]
下面詳細解釋一下各個部分：
scheme
scheme是協議名不區分大小寫，以冒號結尾，表示需要使用的協議來檢索資源。
URL協議是由IANA（The Internet Assigned Numbers Authority，網際網路數字分配機構）與個標準化組織一同管理的。
下面的網址列舉出目前有的scheme:
http://www.iana.org/assignments/uri-schemes.html
有一些大家很熟悉的例如：http:、https:、ftp:等。
在現實中，一些非正式的協議也會被支援，如javascript等，這可能會有一些安全隱患，將在後面進行討論。
在RFC1738中定義scheme中只能包含字母、數字、+、- ，現實中瀏覽器沒有嚴格的遵守。
IE中會忽略所有的非列印字元ASCII中的0x01到0x1F。
chrome中會跳過0x00即NULL字元。
為了符合RFC1738中的語法規範，每個URL中需要在認證資訊前面加入“//”。
在省略“//”字串的情況下，會造成解析錯誤。
但在個別情況下不會解析錯誤，如mailto:[email protected]?subject= Hello+world，由郵件客戶端開啟的時候不會出錯。
但是由於瀏覽器的特性：
1 http:baidu.com/ 這個地址在最新版Chrome、Safari、Firefox、IE中都可以定向到http://baidu.com/ 。
2 javascript://example.com/%0Aalert(1)
<iframe src="javascript://baidu.com/%0Aalert(1)"> 最新版Chrome、Safari、Firefox、IE中都可以彈出1。
[login[:password]@]
訪問資源的認證資訊（可選），當沒有提供認證資訊時，瀏覽器將嘗試匿名獲取資源。
絕大部分瀏覽器在此部分接受幾乎所有的字元，有兩個例外：
Saferi拒絕 < > { } 字元，Firefox拒絕換行。
(host_name|host_address)
伺服器地址，正常的URL是DNS指向的域名例如baidu.com，或者IPv4地址如127.0.0.1，或IPv6的地址如[0:0:0:0:0:0:0:1]。
雖然RFC中的IP地址只允許規範的符號，但是大多數應用程式呼叫的是標準的C庫，導致會寬鬆很多。
http://127.0.0.1/ 這是一個典型的IPv4地址。
http://0x7f.1/ 這是用十六進位制表示的127.0.0.1
http://017700000001/ 用八進位制表示的127.0.0.1
[:port]
伺服器埠（可選），他表示採用非預設的協議埠來訪問服務，例如http的預設埠80，ftp的21等。
幾乎所有的瀏覽器以及第三方應用使用TCP或UDP作為底層的傳輸方法。
並依靠TCP和UDP的16位埠號分開一臺機器上執行不同服務的通訊。
當使用者將瀏覽器定向到http://mail.example.com:25/而25埠是SMTP服務，不是http服務，可能引起安全問題，後面會討論。
[/hierarchical/path/to/resource[?search_string]
路徑，用來定位伺服器上的資源。
[#fragment_id]]
頁面的某個位置，其功能是讓使用者開啟某個網頁時，自動定位到指定位置上。
在RFC 3986的文件中定義了一個URI的基本結構，定義了沒有特殊意義的字元
0-9 A-Z a-z - . _ ~
以及一些在某些地方可能有特殊意義的字元
: / ? # [ ] @ ! $ ' ( ) * + , ; =
還有一些字元，當他們直接放在Url中的時候，可能會引起解析程式的歧義。這些字元被視為不安全字元，原因有很多。
1 空格：Url在傳輸的過程，或者使用者在排版的過程，或者文字處理程式在處理Url的過程，都有可能引入無關緊要的空格，或者將那些有意義的空格給去掉。
2 引號以及<>：引號和尖括號通常用於在普通文字中起到分隔Url的作用
3 %：百分號本身用作對不安全字元進行編碼時使用的特殊字元，因此本身需要編碼
4 {}|\^[]`~：某一些閘道器或者傳輸代理會篡改這些字元
其他的字元都可以用%加16進位制字串（%nn）來表示，包括%它本身。
由於伺服器可能需要能夠接受那些字元如使用者搜尋那些字元時，此時就採用%nn的方式來轉碼後請求。
導致下面三個URL是等效的：
1、http://example.com/
2、http://%65xample.%63om/
3、http://%65%78%61%6d%70%6c%65%2e%63%6f%6d/
非US-ASCII文字的處理：
對於非ASCII字元，需要使用ASCII字符集的超集進行編碼得到相應的位元組，然後對每個位元組執行百分號編碼。
對於Unicode字元，RFC文件建議使用utf-8對其進行編碼得到相應的位元組，然後對每個位元組執行百分號編碼。
如"中文"使用UTF-8字符集得到的位元組為0xE4 0xB8 0xAD 0xE6 0x96 0x87，經過Url編碼之後得到"%E4%B8%AD%E6%96%87"。
針對域名的編碼：
Punycode是一個根據RFC 3492標準而制定的編碼系統,主要用於把域名從地方語言所採用的Unicode編碼轉換成為可用於DNS系統的編碼。
Punycode可以防止所謂的IDN欺騙。
目前，因為作業系統的核心都是英文組成，DNS伺服器的解析也是由英文程式碼交換，所以DNS伺服器上並不支援直接的中文域名解析。
所有中文域名的解析都需要轉成punycode碼，然後由DNS解析punycode碼。
其實目前所說和各種瀏覽器完美支援中文域名，只是瀏覽器軟體裡面主動加入了中文域名自動轉碼，不需要原來的再次安裝中文域名轉碼控制元件來完成整個流程。
例子：中國.cn，用Punycode轉換後為：xn--fiqs8s.cn
同樣其他語言也是如此。
例如下面的網址列出一個攻擊方式，輸入想要偽造的網址，選擇相近的字元，可以幫你生成一個：
http://www.irongeek.com/homoglyph-attack-generator.php
瀏覽器本身支援的協議：http: https: ftp: file:(之前是local:，用來獲取本地檔案或者NFS與SMB共享)
第三方應用或者外掛支援的協議： acrobat: callto sip: daap: itpc: itms: mailto: news: nntp: mmst: mmsu: msbd:rtsp: 等等。
偽協議：一些保留協議用來呼叫瀏覽器指令碼引擎或者函式，沒有真正取回任何遠端內容，也沒有建立一個獨立的檔案。
如：javascript: data:
data協議例子：data:text/html;base64,PGlmcmFtZS9vbmxvYWQ9YWxlcnQoMSk+
封裝的偽協議：view-source:http://www.example.com/
view-source:是由Chrome與Firefox提出的用來檢視當前頁面原始碼的協議。
其他的類似協議還有jar: wyciwyg: view-cache: feed: hcp: its: mhtml: mk: ms-help: ms-its: ms-itss:
本文章來源於烏雲知識庫，此映象為了方便大家學習研究，文章版權歸烏雲知識庫！