我应该使用哪个URL 解析函数对,为什么?
3 回答
直接来自您自己链接的文档:
urllib.parse.urlsplit(urlstring, scheme='', allow_fragments=True)
这类似于urlparse()
,但不会从 URL 中拆分参数。urlparse()
如果需要更新的 URL 语法,允许将参数应用于 URL 的路径部分的每个段(请参阅 RFC 2396),则通常应使用此方法。
正如文档所说,
urlparse.urlparse
返回 6 元组(带有附加参数元组)
urlparse.urlsplit
返回 5 元组
属性 |索引 | 价值 | 如果不存在
参数值 | 3 | 最后一个路径元素的参数 | 空字符串
仅供参考:根据 [RFC2396](https://www.rfc-editor.org/rfc/rfc2396.html#appendix-C),URL 规范中的 _parameter_ > 对当前客户端应用程序的广泛测试表明,大多数部署的系统都可以不要使用“;” 用于指示尾随参数信息的字符,并且路径段中分号的存在不会影响该段的相对解析。因此,参数已作为单独的组件被删除,现在可能出现在任何路径段中。它们的影响已从解析相对 URI 引用的算法中移除。
鉴于您链接的文档没有包含一个非空示例,params
我也很困惑,直到我找到这个。
>>> 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')
(一些历史,因为我被书呆子狙击了。)
/user/213/settings
除了 url 组件参数 ie或查询参数之外,我从未听说过 URL“参数” /user?id=213
,我认为它基本上已经过时了。
一开始,RFC 1738将 HTTP URL定义为不允许;
在path
:
http://<host>:<port>/<path>?<searchpart>
在
<path>
and<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定义为具有相邻的顶级组件path
和query
:
<scheme>://<authority><path>?<query>
其中path
被定义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
被认为是 URI 语法的不透明部分,可能特定于 HTTP(S) 方案或只是一些特定的实现:
除了层次路径中的点段之外,路径段被通用语法认为是不透明的。生成 URI 的应用程序通常使用段中允许的保留字符来分隔特定于方案或特定于解引用处理程序的子组件。例如,分号 (";") 和等号 ("=") 保留字符通常用于分隔适用于该段的参数和参数值。逗号 (",") 保留字符通常用于类似目的。例如,一个 URI 生产者可能使用诸如“name;v=1.1”之类的段来指示对“name”版本 1.1 的引用,而另一个 URI 生产者可能使用诸如“name,1.1”之类的段来指示相同。 参数的语法特定于 URI 的解引用算法的实现。