9

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

我在 PHP 中寻找一个明确的符合 RFC 标准的 URL 解析器，它能够可靠地处理浏览器可能遇到的任何 URL。在这我包括：

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

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

这个答案包含对这种野兽的诱人的费马式参考，但它实际上并没有去任何地方。

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

那么，这样的事情存在吗？

4

1 回答 1

3

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

由于“first-match-wins”算法与 POSIX 正则表达式使用的“贪婪”消歧方法相同，因此使用正则表达式来解析 URI 引用的潜在五个组件是很自然和常见的。

以下行是将格式良好的 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
于 2012-10-02T09:34:39.207 回答