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:user@example.com?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: