2

我需要帮助构建一个可以正确匹配自由文本中的 URL 的正则表达式。

  • 方案
    • 以下之一：ftp、http、https（ftps是协议吗？）
  • 可选用户（和可选通行证）
  • 主机（支持 IDN）
    • 支持www和子域（支持 IDN）
    • TLD 的基本过滤（[a-zA-Z]{2,6}我认为就足够了）
  • 可选端口号
  • 路径（可选，支持 Unicode 字符）
  • 查询（可选，支持 Unicode 字符）
  • 片段（可选，支持 Unicode 字符）

以下是我可以找到的有关子域的信息：

“子域”表示相对依赖，而不是绝对依赖：例如，wikipedia.org 包含 org 域的子域，而 en.wikipedia.org 包含域 wikipedia.org 的子域。理论上，这个细分可以下到 127 级深度，每个 DNS 标签最多可以包含 63 个字符，只要整个域名的总长度不超过 255 个字符。

关于域名本身，我找不到任何可靠的来源，但我认为非 IDN的正则表达式（我不确定如何编写 IDN 兼容版本）类似于：

[0-9a-zA-Z][0-9a-zA-Z\-]{2,62}

有人可以帮我解决这个正则表达式或指出一个好的方向吗？

4

3 回答 3

4

以 Daring Fireball 闻名的 John Gruber最近发表了一篇文章，详细介绍了他对良好的 URL 识别正则表达式字符串的追求。他想出的是这样的：

\b(([\w-]+://?|www[.])[^\s()<>]+(?:\([\w\d]+\)|([^[:punct:]\s]|/)))

这显然也适用于包含 Unicode 的 URL。您需要对其进行轻微修改以获取您要查找的其余内容 - 方案、用户名、密码等。Alan Storm写了一篇解释 Gruber 的正则表达式模式的文章，这是我绝对需要的（正则表达式是所以写一次就没有线索了如何再读一次！）。

于 2009-12-29T15:06:20.483 回答
0

如果您需要该协议并且不太担心误报，那么到目前为止最简单的方法是匹配周围的所有非空白字符://

于 2009-12-29T14:46:27.950 回答
0

这将使您大部分时间到达那里。如果您需要更精细，请提供测试数据。

(ftp|https?)://([-\w\.]+)+(:\d+)?(/([\w/_\.]*(\?\S+)?)?)?
于 2009-12-29T14:47:50.707 回答