一、URL概述

1.1 什么是URL?

URL 的全称是(Uniform Resource Locator)，统一资源定位符。你可以把它想象成互联网上某个“资源”的精确地址。

譬如说:

• 访问百度首页的 URL https://www.baidu.com：告诉浏览器 “用 HTTPS 协议，去 www.baidu.com 这个服务器上获取首页资源”；
• 打开本地文件的 URL file:///C:/Users/Photo/1.jpg：告诉系统 “用本地文件协议，去 C 盘 Users/Photo 文件夹下找 1.jpg 图片”。

简单说，URL 就像 “互联网资源的快递地址”：协议是 “快递方式”（如顺丰、京东），服务器域名 / IP 是 “收件城市 / 小区”，路径是 “具体门牌号”，参数是 “收件人备注”。

1.2 URL 的标准结构：遵循 RFC 3986 规范

[方案]://[授权信息]#[片段]
          ↓
    [用户信息@][主机]:[端口]

更完整的语法格式为：

scheme://userinfo@host:port/path?query#fragment

其中，只有 scheme（方案）和 host（主机）是部分场景下的必选组件（如 HTTP/HTTPS 必须有这两个，本地文件协议 file 可省略部分），其他组件根据需求添加。

二、URL的组成

为了让每个组件的理解更具体，我们用一个 “包含所有组件的完整 URL” 作为案例，逐个对应解析：案例 URL：

https://user:pass123@www.example.com:8443/blog/article?category=tech&id=10086#comment-5

2.1 方案（scheme）：如何访问资源（必选）

✅ 作用：定义 “访问资源的协议或方式”，告诉客户端（浏览器、APP）“用什么规则与服务器交互”。

✅ 规则

• 不区分大小写（HTTP 和 http 等价）；
• 必须后跟 ://（是 scheme 与后续组件的分隔符，不可省略）；
• 只能包含字母、数字、+、-、.（如 https、ftp）。

✅ 案例对应：https → 用 “HTTPS 协议” 访问（加密传输，比 HTTP 更安全，常用于敏感数据传输如登录、支付）

✅ 常见 scheme：

scheme	用途	示例
http	超文本传输协议（未加密）	http://www.baidu.com
https	加密超文本传输协议	https://mail.qq.com
ftp	文件传输协议	ftp://ftp.example.com/file.zip
file	本地文件访问	file:///D:/Document/report.pdf
mailto	发送邮件	mailto:service@example.com?subject=反馈
tel	拨打电话（移动端）	tel:10086

2.2 授权信息（authority）

资源在哪个服务器（可选，仅网络资源需要）

✅ 作用：指定 “资源所在的服务器信息”，是网络型 URL（如 HTTP/HTTPS/FTP）的核心定位部分，格式为 [userinfo@]host:port（三部分中，仅 host 【必选】）。

• 用户信息（userinfo）：“服务器身份验证”（几乎不用）

  • 作用：包含 “用户名 + 密码”，用于服务器的基础身份验证（如早期 FTP 登录）。

  • 规则：格式为 用户名:密码，后跟 @ 与主机分隔；

  • 风险：明文传输（即使是 HTTPS，URL 中的 userinfo 也可能被日志记录），现在已被 Token、OAuth 2.0 等安全认证替代，实际几乎不用。

  • 案例对应：user:pass123@ → 用户名 user，密码 pass123（仅示例，实际环境禁止这样写）。

• 主机（host）：“服务器的唯一标识”（【必选】，网络 URL 核心）

  • 作用：指定 “资源所在的服务器地址”，是 URL 定位的 “核心锚点”。

  • 格式两种形式（二选一）：

    • 域名（人类易记，如 www.example.com、baidu.com）；
    • IP 地址（机器识别，如 192.168.1.1（局域网）、202.108.22.5（百度公网 IP））。

  • 案例对应：www.example.com → 资源所在的服务器域名。

• 端口（port）：“服务器的‘门牌号’”（可选）

  • 作用：服务器上 “不同服务的入口”（一台服务器可同时提供 HTTP、FTP 等多个服务，用端口区分）。

  • 规则

    • 范围：0-65535（其中 0-1023 是 “知名端口”，被标准协议占用，用户自定义端口用 1024-65535）；
    • 省略规则：如果使用 “协议默认端口”，可省略端口号（如 HTTP 默认 80，HTTPS 默认 443，FTP 默认 21）。

  • 案例对应：8443 → 自定义 HTTPS 端口（默认是 443，这里指定 8443 需服务器提前配置）。

2.3 路径（path)

资源在服务器中的‘文件夹路径’（可选，但常用）

• 作用：描述 “资源在服务器内部的具体存储或访问路径”，类似本地文件系统的 “文件夹 / 文件名”。

• 规则

  • 用 / 分隔层级（如 /blog/article 表示 “服务器根目录下的 blog 文件夹，再下的 article 资源”）；
  • 可包含字母、数字、-、_、.、~ 等安全字符；特殊字符（如空格、中文、@）需 “URL 编码”（后面详细讲）；
  • 结尾是否带 / 有区别：/blog（可能是文件夹或资源） vs /blog/（明确是文件夹，服务器会返回该文件夹下的默认资源如 index.html）。

• 案例对应：/blog/article → 访问服务器上 blog 目录下的 article 资源（可能是一篇文章的网页，或一个接口）

2.4 查询参数（query）

“向资源传递的额外信息”（可选）

• 作用：给资源传递 “动态参数”，常用于筛选、分页、指定内容等（如搜索关键词、文章 ID）。
• 规则
  • 以 ? 开头（与路径分隔）；
  • 参数格式为 “键值对”：key=value，多个参数用 & 分隔；
  • 参数顺序通常不影响结果（除非服务器特殊处理）；
  • 特殊字符（如空格、中文）需 URL 编码。
• 案例对应：?category=tech&id=10086 → 向 /blog/article 资源传递两个参数：category=tech（分类为技术）、id=10086（文章 ID 为 10086）。

2.5 片段（fragment）

“资源内部的‘子定位’”（可选）

• 作用：规则
  • 以 # 开头（与查询参数分隔）；
  • 内容由开发者自定义（通常对应网页中元素的 id 属性，如 #comment-5 对应 id="comment-5" 的评论区）；
  • 服务器接收请求时，会自动忽略片段部分（比如访问 https://example.com#test，服务器实际收到的请求是 https://example.com）。
• 定位 “资源内部的某个子部分”（如网页中的某个章节、图片的某个区域），仅由客户端（浏览器）处理，不发送给服务器。

• 案例对应：#comment-5 → 浏览器加载文章后，自动滚动到 “ID 为 comment-5 的评论区”。

三、URL的关键技术：URL 编码（百分号编码）

URL 只能包含 “ASCII 可打印字符”（共 95 个，如字母、数字、!、@ 等），如果包含非 ASCII 字符（如中文、日文）或特殊分隔符（如空格、&、?），会导致 URL 解析错误（比如空格会被识别为 “参数分隔”）。因此，需要将这些字符转换为 “% + 十六进制 ASCII 码” 的格式，即 URL 编码（Percent-Encoding）。

3.1 编码规则

• 步骤 1：将字符转换为 “UTF-8 编码”（互联网标准编码，避免中文乱码）；
• 步骤 2：将 UTF-8 编码的每个字节，转换为 “两位十六进制数”；
• 步骤 3：在每个十六进制数前加 %，得到编码结果。

3.2 常见字符编码示例

原始字符	UTF-8 字节	十六进制	URL 编码结果
空格	0x20	20	%20
中文 “中”	0xE4 0xB8 0xAD	E4 B8 AD	%E4%B8%AD
&	0x26	26	%26
?	0x3F	3F	%3F
@	0x40	40	%40

✅ 实际案例

原始 URL（含中文和空格）：https://example.com/search?keyword=URL 
---> 编码编码后 
URL：https://example.com/search?keyword=URL%20%E7%BC%96%E7%A0%81（空格
---> %20，“编”→%E7%BC%96，“码”→%E7%A0%81）

3.3 URL 的常见类型与场景

根据 scheme（方案）的不同，URL 可分为以下几类，覆盖日常 99% 的使用场景：

类型	scheme	核心用途	典型示例
网页 URL	http/https	访问网页、接口（最常用）	https://www.zhihu.com/question/19790488
文件传输 URL	ftp	远程服务器文件上传 / 下载	ftp://ftp.ubuntu.com/ubuntu/dists/
本地文件 URL	file	访问电脑 / 手机本地文件	file:///C:/Users/Documents/resume.pdf
邮件 URL	mailto	唤起邮件客户端发邮件	mailto:support@example.com?subject=问题反馈`
电话 URL	tel	移动端唤起拨号界面	tel:400-800-8888
应用跳转 URL	自定义 scheme	APP 间跳转（如微信、支付宝）	weixin://dl/chat（打开微信聊天）

四、常见误区与注意事项

4.1 误区 1：URL 必须带 www

不是！www 只是 “万维网服务” 的默认子域名，服务器可直接用顶级域名作为 host（如 https://baidu.com 等价于 https://www.baidu.com，后者是前者的别名，需服务器配置解析）。

4.2 误区 2：URL 长度没有限制

虽然 RFC 3986 没有规定 URL 长度，但浏览器和服务器有实际限制：

• 浏览器：IE 最多 2083 字符，Chrome/Firefox 支持更长（但建议不超过 8192 字符）；

• 服务器：Nginx 默认限制 4096 字符，Apache 默认限制 8192 字符。

  若需传递大量数据（如表单提交），建议用POST方法（数据在请求体中），而非GET方法（数据在 URL 查询参数中）。

4.3 误区 3：HTTPS URL 绝对安全

HTTPS 仅保证 “传输过程加密”，但 URL 本身可能泄露信息：

• 浏览器地址栏会显示完整 URL（除了密码）；
• 服务器日志会记录 URL（包括查询参数，若参数含敏感信息如手机号，需加密或用 POST 传递）。

4.4 注意：相对 URL 与绝对 URL 的区别

• 绝对 URL：包含完整的 scheme 和 host（如 https://www.example.com/blog），可直接定位资源；
• 相对 URL：仅包含 path、query、fragment（如 /blog、?id=123），需基于 “基准 URL”（如当前网页 URL）解析为绝对 URL。
• 示例：当前网页 URL 是 https://www.example.com/home，相对 URL /blog 会解析为 https://www.example.com/blog。

4.5 完整示例

https://www.example.com:8080/path/to/myfile.html?key1=value1&key2=value2#Lucky

1. 协议： 使用 HTTPS（加密的）协议。
2. 目标服务器： 连接到 www 子域下的 example.com 这个域名所对应的服务器。
3. 端口： 通过 8080 号端口进行连接。
4. 请求资源： 在服务器的 /path/to/ 目录下，请求名为 myfile.html 的文件。
5. 附带参数： 同时向服务器传递两个参数：key1 的值为 value1，key2 的值为 value2。
6. 定位： 当文件加载完成后，自动滚动到页面中 id="Lucky" 的那个元素处。