URL格式：
scheme://[login[:password]@](host_name|host_address)[:port][/hierarchical/path/to/resource[?search_string][#fragment_id]]
下面詳細解釋一下各個部分：
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。
訪問資源的認證信息（可選），當沒有提供認證信息時，瀏覽器將嘗試匿名獲取資源。
絕大部分瀏覽器在此部分接受幾乎所有的字符，有兩個例外：
Saferi拒絕 < > { } 字符，Firefox拒絕換行。
服務器地址，正常的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
服務器端口（可選），他表示采用非默認的協議端口來訪問服務，例如http的默認端口80，ftp的21等。
幾乎所有的瀏覽器以及第三方應用使用TCP或UDP作為底層的傳輸方法。
并依靠TCP和UDP的16位端口號分開一臺機器上運行不同服務的通信。
當用戶將瀏覽器定向到http://mail.example.com:25/而25端口是SMTP服務，不是http服務，可能引起安全問題，后面會討論。
路徑，用來定位服務器上的資源。
頁面的某個位置，其功能是讓用戶打開某個網頁時，自動定位到指定位置上。
在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: