我应该使用哪个：urlparse 或 urlsplit？

Question

我应该使用哪个 URL 解析函数对，为什么？

• urlparse 和urlunparse，或
• urlsplit和 urlunsplit ？

Answer 1

直接来自您自己链接的文档：

urllib.parse.urlsplit（urlstring，scheme=''，allow_fragments=True）
这与 urlparse() 类似，但不会将参数从 URL 中分离出来。如果需要更新的 URL 语法，允许将参数应用于 URL 路径部分的每个段（请参阅 RFC 2396），则通常应使用此函数来代替 urlparse()。

Answer 2

鉴于您链接的文档不包含带有非空 params 的示例，我也很困惑，直到我发现 this 。

>>> urllib.parse.urlparse("http://example.com/pa/th;param1=foo;param2=bar?name=val#frag")
ParseResult(scheme='http', netloc='example.com', path='/pa/th', params='param1=foo;param2=bar', query='name=val', fragment='frag')

---

（一些历史，因为我被书呆子狙击了。）

除了 url 组件参数（即 /user/213/settings 或查询）之外，我从未听说过 URL“参数” params /user?id=213 我认为它基本上已经过时了。

一开始，RFC 1738 定义 HTTP URL 永远不允许 ; 在路径中：

http://<host>:<port>/<path>?<searchpart>

在 和 组件中，“/”、“;”、“?”已保留。

; 在其他方案中保留有特殊含义，就像 ftp:// url-path 一样：

<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>

显然是在 1995 年，RFC 1808 定义 URL params作为path和query之间的顶级组件：

<scheme>://<net_loc>/<path>;<params>?<query>#<fragment>

---

然后在1998年, RFC 2396 定义 URI 具有相邻的顶级组件 路径和查询：

<scheme>://<authority><path>?<query>

其中路径是定义为多个path_segments，每个路径可以包含param：

path          = [ abs_path | opaque_part ]
abs_path      = "/"  path_segments
path_segments = segment *( "/" segment )
segment       = *pchar *( ";" param )

---

最终在 2005 年，RFC 3986 废弃了 RFC 1808 和 2396，定义 URI类似于RFC 2396：

URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ] 

hier-part   = "//" authority path-abempty
            / path-absolute
            / path-rootless
            / path-empty

以及特殊语法;params 被视为不透明部分可能特定于 HTTP(S) 方案或只是某些特定实现的 URI 语法：

除了分层路径中的点段之外，通用语法认为路径段是不透明的。 URI 生成应用程序通常使用段中允许的保留字符来分隔特定于方案或特定于解引用处理程序的子组件。例如，分号（“;”）和等号（“=”）保留字符通常用于分隔适用于该段的参数和参数值。逗号（“，”）保留字符通常用于类似目的。例如，一个 URI 生产者可能使用诸如“name;v=1.1”之类的段来指示对“name”版本 1.1 的引用，而另一个 URI 生产者可能使用诸如“name,1.1”之类的段来指示相同的内容。 参数类型可以通过特定于方案的语义来定义，但在大多数情况下参数的语法特定于 URI 解除引用算法的实现。

Answer 3

正如文档所述
urlparse.urlparse 返回 6 元组（带有附加参数元组）
urlparse.urlsplit 返回 5 元组

属性|索引 |价值                                                           |如果不存在则值
参数    |     3   |最后一个路径元素的参数 |空字符串

FYI: According to [RFC2396](https://www.rfc-editor.org/rfc/rfc2396.html#appendix-C), _parameter_ in URL specification
> Extensive testing of current client applications demonstrated that
the majority of deployed systems do not use the ";" character to
indicate trailing parameter information, and that the presence of a
semicolon in a path segment does not affect the relative parsing of
that segment. Therefore, parameters have been removed as a separate
component and may now appear in any path segment. Their influence
has been removed from the algorithm for resolving a relative URI
reference.