【问题标题】:The definitive PHP url parser权威的 PHP url 解析器
【发布时间】:2012-10-02 09:29:43
【问题描述】:

在您告诉我使用parse_url 之前,它还不够好,并且有太多错误。关于解析 URL 的主题有很多问题可以在这里找到,但几乎所有问题都只解析某些特定类别的 URL,或者不完整。

我正在寻找一个明确的、符合 RFC 的 PHP 的 URL 解析器,它能够可靠地处理浏览器可能遇到的任何 URL。其中包括:

  • 页面内部链接#, #title
  • 页面相关 URL blah/thing.php
  • 站点相关 URL /blah/thing.php
  • 匿名协议 URL //ajax.googleapis.com/ajax/libs/jquery/1.8.1/jquery.min.js
  • 调用 URL callto:+442079460123
  • 文件 URL file:///Users/me/thisfile.txt
  • 邮件地址mailto:user@example.com?subject=hello, mailto:?subject=hello

并支持所有常见的方案/身份验证/域/路径/查询/片段等,并将所有这些元素分解为一个数组,并为相对/无模式 URL 提供额外的标志。理想情况下,它会附带一个支持相同元素的 URL 重构器(如 http_build_url),并且我还希望应用验证(即,如果 URL 无效,它应该能够对 URL 进行最佳猜测解释,但标记它因此,就像浏览器一样)。

This answer 包含对这种野兽的诱人费马式引用,但它实际上并没有去任何地方。

我查看了所有主要框架,但它们似乎只提供了围绕 parse_url 的薄包装器,这通常是一个不好的起点,因为它会犯很多错误。

那么,这样的事情存在吗?

【问题讨论】:

  • 只是好奇:parse_url() 怎么了?
  • 最终的 url 解析器将源自浏览器的本机代码。您列出的示例应该被浏览器识别为有效。所以,看看它是怎么做的,移植代码。
  • 本质上 parse_url 尝试解析所有内容,就好像它是 HTTP 一样,这意味着它经常会中断任何不是的内容。它经常在域和路径之间混淆,尤其是在没有域的方案中,例如在 callto 中,并且它完全被匿名协议抛出。
  • 浏览器不使用正则表达式来解析 URL,我也不喜欢移植数千行 C 代码,例如在 uriparser.sourceforge.netcode.google.com/p/google-url 中,我想可以换行将它们添加到 PHP 扩展中,但这有点超出我的能力。

标签: php validation url


【解决方案1】:

不确定parse_url() 有多少错误,但这可能会有所帮助:

由于“第一场比赛获胜”算法与“贪婪”算法相同 POSIX正则表达式使用的消歧方法,它是 使用正则表达式解析 URI 引用的潜在五个组成部分。

下面这行是分解a的正则表达式 对其组件的格式良好的 URI 引用。

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?
 12            3  4          5       6  7        8 9

来源:https://www.rfc-editor.org/rfc/rfc3986#page-51

它将位置分解为:

$2 - scheme
$4 - host
$5 - path
$6 - query string
$8 - fragment

要重建,您可以使用:

$1 . $3 . $5 . $6 . $8

【讨论】:

  • 是解析一个 URL 还是仅仅验证一个?也就是说,捕获组是否围绕有意义的数据片段?
  • @millimoose 它并没有真正验证它,只是将它分解成有用的部分;查看更新的答案。
  • 谢谢 - 即使这是对 parse_url 的改进!
猜你喜欢
  • 2019-08-29
  • 1970-01-01
  • 2017-06-26
  • 2011-03-29
  • 1970-01-01
  • 1970-01-01
  • 2011-10-18
  • 2013-05-25
  • 2011-08-01
相关资源
最近更新 更多