scheme://login:password@address:port/path/to/resource?query_string#fragment

• scheme：协议名称
• //：层级URL标记符号
• login@password：访问资源需要的凭证
• address:获取数据的服务器
• port：连接的端口号
• /path/to/resource：指向资源的层级UNIX文件路径
• query_string：查询字符串参数
• fragment：片段ID
  

协议

 协议名称由一串不区分大小写的字符串组成，以冒号结束，表明获取该资源需要使用的协议

RFC1738对绝对URL的规定：冒号":" 之前，只能出现字母、数字、"+"、"-"和"."。各浏览器实现有差别（IE忽略不可打印字符，Chrome在此基础上忽略0x00和NUL空字符，大 多数浏览器会忽略协议名中的换行和制表符，Opera接受在协议字符串中出现高位字符）

 

层级URL标记符号

RFC1738规定：每个层级结构的绝对URL应包含固定字符串"//"

层级URL示例：http://example.com

非层级URL示例：mailto:user@example.com?subject=Hello+world

上述规定对以下情况作何处理未明确：

• 非层级URL带有"//"
• 层级URL不带有"//"

在之后的RFC3986中出于兼容性考虑，允许解析这类URL

• http:example.com/   没有符合要求的基准URL环境，Firefox、Chrome和Safari将其等同于http://example.com，有基准URL，认为是指向目录example.com的相对路径

访问资源的身份验证

对不支持身份验证的协议，如果URL中强行添加了这部分信息该如何处理，协议未做规定

若未提供身份验证信息，浏览器默认以匿名形式获取数据（HTTP和其他几种协议这意味着没有传送任何身份验证信息；对FTP协议，这包含一个名为ftp的帐号和一个假的密码）

服务器地址

服务器地址部分：

• 不去分大小写的域名
• 一个IPv4地址
• 在一对方括号中的IPv6地址

服务器端口

服务器端口是可选的，通常在网络端口是非标准端口时才会用到。基本上浏览器支持的所有协议及第三方应用都会以TCP或UDP作为传输方式，TCP和UDP都依赖于一个16位端口来区分一台机器上的不同服务，服务器上的每种协议都关联一个默认的服务端口

层级文件路径

支持"/../"和"/./"格式的相对路径

查询字符串

用于把一串非层级格式的任意参数传递给由前面路径所对应的资源。如下示例将用户提供的信息传递给服务器脚本

http://example.com/search.php?query=Hello+World

浏览器处理HTML文件的表单时会生成如下格式的查询字符串

  name1=value1&name2=value2...

但这并不是强制的

Fragment ID

用于客户端而非服务器端

用途：指向HTML页面的某个锚点名称，用于页面浏览定位。（如果URL里的锚点名称于HTML页面里面设定的锚点标签匹配，文档滚动到该定位标签位置）

解析URL

1. 提取协议名称

    第一个“：”字符左边是协议名称，如果其中有不应有的字符，则它可能是相对URL而不是协议名称

2. 取出层级URL标记符

    “//”跟在协议后面，如果发现，跳过；没有发现，不去管。（URL标记符在某些环境下可能不用“/”，用一个、两个甚至三个以上“/”，很多浏览器接受”\“代替”/“）

3. 获取授权信息部分

    一次扫描”/“、”？“或”#“（另”\“也需考虑），哪个先出现以哪个为准进行截取（分号在某些浏览器中也是授权信息部分接受的分隔符）

  a. 如果有，定位登录信息：如果存在@符号，其前面是登录信息（登录信息的“：”前面是用户名，后面是密码数据）

  b. 提取目标地址：剩下部分是目标地址，第一个“：”分割了主机名和端口

4. 确定路径

    授权部分结尾的“/”（“\“，”;“如果支持的话）和之后第一个出现的”?“、“#”或字符串结尾之间的部分即路径部分，将其根据UNIX路径予以进行规范化处理

5. 提取查询字符串

    上一条解析结尾是“?“，则该”?“和之后出现的第一个”#“或字符串结尾之间的部分未查询字符串

6. Fragment ID

    成功解析上一条信息之后跟着“#”，则该”#“后面剩下的部分未Fragment ID