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

【问题标题】：Which should I be using: urlparse or urlsplit?我应该使用哪个：urlparse 或 urlsplit？
【发布时间】：2011-07-25 05:40:24
【问题描述】：

我应该使用哪个URL parsing function pair，为什么？

urlparse 和 urlunparse，或
urlsplit 和 urlunsplit?

【问题讨论】：

标签： python urllib urlparse urlsplit

【解决方案1】：

直接来自the docs you linked yourself：

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

【讨论】：

由于这些 URL（带有附加参数的任何路径元素）在实践中很少使用，也许值得添加一个示例，显示解析结果的差异？例如喜欢这里：doughellmann.com/PyMOTW/urlparse/#parsing
Updated Python 3 link 对于那些感兴趣的人
您能否提供示例 URL 来说明差异？我已经阅读了 Python 文档并简要查看了 RFC 2396，但除了它们使用分号这一事实之外，还不清楚它们所指的是哪种类型的 URL 参数。

【解决方案2】：

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

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

仅供参考：根据 [RFC2396](https://www.rfc-editor.org/rfc/rfc2396.html#appendix-C)，URL 规范中的 _parameter_ > 对当前客户端应用程序的广泛测试表明，大多数部署的系统不使用“;”字符到指示尾随参数信息，并且存在路径段中的分号不影响相对解析那个片段。因此，参数已作为单独的参数被删除组件，现在可能出现在任何路径段中。他们的影响已从解析相对 URI 的算法中删除参考。

【讨论】：

从您的回答中不清楚您建议使用哪种方法。
这取决于，如果你需要在 URL 中的参数然后使用 urlsplit。

【解决方案3】：

鉴于您链接的文档没有包含带有非空 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 或查询参数/user?id=213，我从未听说过 URL“参数”，我认为它基本上已经过时了。

在开始时，RFC 1738 defined HTTP URL 永远不允许 ; 在 path 中：

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

在<path> 和<searchpart> 组件中，“/”、“;”、“?”保留。

;在其他方案中保留了特殊含义，like ftp:// url-path:

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

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

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

然后在 1998 年，RFC 2396 defined URI 具有相邻的顶级组件 path 和 query：

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

其中path 是defined 作为多个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，defining URI 类似于 RFC 2396：

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

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

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

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

【讨论】：