URL语法，编码以及未来的可能性
URL语法
URL 提供了一种定位因特网上任意资源的手段，但这些资源是可以通过各种不同的方案（比如 HTTP、FTP、SMTP）来访问的，因此 URL 语法会随方案的不同而有所不同。大部分 URL 都遵循通用的 URL 语法，而且不同 URL 方案的风格和语法都有不少重叠。大多数 URL 方案的 URL 语法都建立在这个由 9 部分构成的通用格式上：
<scheme>://<user>:<password>@<host>:<port>/<path>?<query>#<fragment>几乎没有哪个 URL 中包含了所有这些组件。
组件 | 描述 | 默认值 |
|---|---|---|
方案（scheme） | 访问服务器以获取资源时要使用哪种协议 | 无 |
用户（user） | 某些方案访问资源时需要的用户名 | 匿名 |
密码（password） | 用户名后面可能要包含的密码，中间由冒号（:）分隔 | <E-mail 地址 > |
主机（host） | 资源宿主服务器的主机名或点分 IP 地址 | 无 |
端口（port） | 资源宿主服务器正在监听的端口号。很多方案都有默认端口号（HTTP 的默认端口号为 80） | 每个方案特有 |
路径（path） | 服务器上资源的本地名，由一个斜杠（/）将其与前面的URL 组件分隔开来。路径组件的语法是与服务器和方案有关的 | 无 |
查询（query） | 某些方案会用这个组件传递参数以激活应用程序（比如数据库、公告板、搜索引擎以及其他因特网网关）。查询组件的内容没有通用格式。用字符“?”将其与 URL 的其余部分分隔开来 | 无 |
片段（fragment） | 一小片或一部分资源的名字。引用对象时，不会将 fragment 字段传送给服务器；这个字段是在客户端内部使用的。通过字符“#”将其与 URL 的其余部分分隔开来 | 无 |
URL语法实际上也挺复杂的。下面我们来介绍每个部分。
方案
方案实际上是规定如何访问指定资源的主要标识符，它会告诉负责解析 URL 的应用程序应该使用什么协议。例如： https://datatracker.ietf.org/doc/html/rfc2396.html，这个URL的scheme就是https。 方案组件必须以一个字母符号开始，由第一个“:”符号将其与 URL 的其余部分分隔开来。方案名是大小写无关的。
用户名和密码
当服务器要求输入用户名和密码才允许用户访问数据的时候，这时候就user和password部分就会派上用场，但是实际中在URL直接携带密码的场景几乎没有，因为这样非常不安全。例如ssh,sftp等，仅允许在url中携带用户名，不能携带密码。
主机和端口
主机组件标识了因特网上能够访问资源的宿主机器。可以用主机名或者 IP 地址来表示主机名。有了主机，就能找到是哪一台机器了，但是还缺乏定位到应用程序的手段，这时候端口就派上用场了，端口可以定位到底和哪一个应用程序进行通信。
路径
URL 的路径组件说明了资源位于服务器的什么地方。路径通常很像一个分级的文件系统路径。例如： https://zy010101.blog.csdn.net/article/details/81252016，路径就是/article/details/81252016
查询
URL中第一个?之后的部分就是查询部分，这部分通常串以一系列键值对的形式出现，键值对之间用字符“&”分隔。例如： https://www.baidu.com/s?ie=UTF-8&wd=aaa，其中query部分就是ie=UTF-8&wd=aaa.
片段
为了引用部分资源或资源的一个片段，URL 支持使用片段组件来表示一个资源内部的片段。比如，URL 可以指向 HTML 文档中一个特定的图片或小节。片段挂在 URL 的右手边，最前面有一个字符“#”。比如： https://docs.python.org/zh-cn/3/library/urllib.parse.html?highlight=urlparse#url-parsing，#之后的url-parsing就是该url的fragment。当你访问这个URL之后，浏览器会自动定位到url-parsing引用的内容。 HTTP 服务器通常只处理整个对象，而不是对象的片段，客户端不能将片段传送给服务器，浏览器从服务器获得了整个资源之后，会根据片段来显示资源。
URL字符问题
希望 URL 可以被所有因特网协议进行传送之外，设计者们还希望 URL 也可供人类阅读。因此，即使不可见、不可打印的字符能够穿过邮件程序，从而成为可移植的，也不能在 URL 中使用。为此，URL的设计者就将转义序列集成了进去。通过转义序列，就可以用 US-ASCII 字符集的有限子集对任意字符值或数据进行编码了，这样就实现了可移植性和完整性。在 URL 中，有一些字符被保留起来，有着特殊的含义。例如URL中的/,?,#等，它们是特殊的，具有特殊含义，不能被用户自定义使用。/代表URL中的分隔符，?代表查询字符串开始了，#代表之后的部分是片段。保留字符是不能被用作自定义部分的。
未来的可能
URL 并不完美。它们表示的是实际的地址，而不是准确的名字。这就意味着URL 会告诉你资源此时处于什么位置。它会为你提供特定端口上特定服务器的名字，告诉你在何处可以找到这个资源。这种方案的缺点在于如果资源被移走了，URL 也就不再有效了。那时，它就无法对对象进行定位了。
为了应对这个问题，因特网工程任务组（Internet Engineering Task Force，IETF）已经对一种名为统一资源名（uniform resource name，URN）的新标准做了一段时间的研究了。无论对象搬移到什么地方（在一个 Web 服务器内或是在不同的 Web服务器间），URN 都能为对象提供一个稳定的名称。永久统一资源定位符（persistent uniform resource locators，PURL）是用 URL 来实现 URN 功能的一个例子。其基本思想是在搜索资源的过程中引入另一个中间层，通过一个中间资源定位符（resource locator）服务器对资源的实际 URL 进行登记和跟踪。客户端可以向定位符请求一个永久 URL，定位符可以以一个资源作为响应，将客户端重定向到资源当前实际的 URL 上去。PURL会导致现有的互联网架构发生变化，做这种改动需要进行大量的工作。因此目前还是URL的天下。
python解析URL
from urllib import parse
urls = ["ftp://anonymous@ftp.prep.ai.mit.edu/pub/gnu",
"ftp://anonymous:my_passwd@ftp.prep.aimit.edu/pub/gnu",
"http://joe:joespasswd@www.joes-hardware.com/sales_info.txt",
"http://www.joes-hardware.com/hammers;sale=false/index.html;graphics=true",
"https://docs.python.org/zh-cn/3/library/urllib.parse.html?highlight=urlparse#url-parsing"
]
for url in urls:
res = parse.urlparse(url=url)
print(res.scheme, res.username, res.password, res.hostname, res.port, res.path, res.params, res.query, res.fragment)parse模块用于解析 URL。具体的api可以参考官方手册。这里有api的详细说明。
参考
- HTTP权威指南
- rfc2396, rfc1738