ios - 如何验证URL是正确的，和/或从任意文本中提取有效的URL？

Question

有时我有一个文本输入表单，我想在其中禁用“接受”按钮，直到用户输入有效的URL。在此处或网上进行搜索会产生大量的正则表达式，但是鉴于URL规范(RFC-3986)的复杂性，几乎不可能为它们编写您自己的验证测试套件。一旦我的应用程序进入App Store，我怎么知道因正则表达式中的缺陷而导致的误报？

其他时候，我需要从网站或其他文本中提取所有有效的URL，并想要获取它们的数组，这样我就可以过滤掉它，只说那些指向图像文件的URL。在这种情况下，错误的正则表达式不太可能成为问题，因为如果我错过了一两张图片，或者得到了虚假的URL，这并不是主要问题。无论如何，正则表达式越好，返回的图像列表就越正确。

因此，如何确定性地将显示的字符串验证为正确的URL？同样，有一种方法可以从任意文本中提取有效的URL。

Answer 1

网络上有大量正则表达式声称可以验证URL。大多数问题是，尽管它们可以工作，但它们没有凭据-也就是说，没有任何方法可以证明一种方法的正确性。

URL的参考规范为RFC-3986，在长时间搜索最佳正则表达式时，我绊倒了Jeff Roberson的regular expression page。他所做的工作是从规范开始，构建小的正则表达式以匹配RFC的低级部分，然后逐步将它们构建为完整的表达式。

例如，这就是获取完整scheme的方式:

# From http://jmrware.com/articles/2009/uri_regexp/URI_regex.html Copyright @ Jeff Roberson
(⌽[A-Za-z][A-Za-z0-9+\-.]*)
# DFH Addition: change ⌽ from "?:" to "" to get capture groups of the various components

第一个“(”之后的unicode字符将更改为“？:”(表示非捕获组)，或将“”变成捕获组。请注意，这会将单个字符与一个或多个包含的字符匹配在第二个“[]”组中，

使用以下表达式可以找到完整的 authority:

# RFC-3986 URI component:  relative-part
(?: //                                                          # ( "//"
  (?: (⌽(?:[A-Za-z0-9\-._~!$&'()*+,;=:]|%[0-9A-Fa-f]{2}☯)* ) @)?     # authority DFH modified to grab the authority without '@'
  (⌽
    \[
    (?:
      (?:
        (?:                                                    (?:[0-9A-Fa-f]{1,4}:){6}
        |                                                   :: (?:[0-9A-Fa-f]{1,4}:){5}
        | (?:                            [0-9A-Fa-f]{1,4})? :: (?:[0-9A-Fa-f]{1,4}:){4}
        | (?: (?:[0-9A-Fa-f]{1,4}:){0,1} [0-9A-Fa-f]{1,4})? :: (?:[0-9A-Fa-f]{1,4}:){3}
        | (?: (?:[0-9A-Fa-f]{1,4}:){0,2} [0-9A-Fa-f]{1,4})? :: (?:[0-9A-Fa-f]{1,4}:){2}
        | (?: (?:[0-9A-Fa-f]{1,4}:){0,3} [0-9A-Fa-f]{1,4})? ::    [0-9A-Fa-f]{1,4}:
        | (?: (?:[0-9A-Fa-f]{1,4}:){0,4} [0-9A-Fa-f]{1,4})? ::
        ) (?:
            [0-9A-Fa-f]{1,4} : [0-9A-Fa-f]{1,4}
          | (?: (?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?) \.){3}
                (?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
          )
      |   (?: (?:[0-9A-Fa-f]{1,4}:){0,5} [0-9A-Fa-f]{1,4})? ::    [0-9A-Fa-f]{1,4}
      |   (?: (?:[0-9A-Fa-f]{1,4}:){0,6} [0-9A-Fa-f]{1,4})? ::
      )
    | [Vv][0-9A-Fa-f]+\.[A-Za-z0-9\-._~!$&'()*+,;=:]+
    )
    \]
  | (?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}
       (?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)
  | 
  (?:[A-Za-z0-9\-._~!$&'()*+,;=]|%[0-9A-Fa-f]{2}☯)*
  )

  (?: : (⌽[0-9]*) )? # DFH addition to grab just the port

 (⌽   # DFH addition to get one capture group
  (⌽ / (?:[A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2}☯)* )*    # path-abempty
| /                                                             # / path-absolute
  (⌽:    (?:[A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2}☯)+
    (?:/ (?:[A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2}☯)* )*
  )?
| (⌽        (?:[A-Za-z0-9\-._~!$&'()*+,;=@] |%[0-9A-Fa-f]{2}☯)+     # / path-noscheme
    (?:/ (?:[A-Za-z0-9\-._~!$&'()*+,;=:@]|%[0-9A-Fa-f]{2}☯)* )*
   ) # DFH Wrapper
|                                                            # / path-empty
      (⌽) # DFH addition so constant number of capture groups
 )
)                                                               # )

# DFH Addition: change ☯ to "|[\u0080-\U0010ffff]" to get inline Unicode detection (making this an IRI, not a URI, but you can later hex encode it), or "" for standard behavior
# DFH Addition: change ⌽ from "?:" to "" to get capture groups of the various components

如果您阅读以上内容，则可以看到，只需在几个地方添加“| [\ u0080- \ U0010ffff]”，即可将该表达式扩展为查找Unicode字符。

因为他实际上是从RFC开始的，并且他的表达的所有部分完全引用了ABNF规范，所以我对它们很有信心。

但是，当我开始测试时，发现说 http://的URL验证器通过了!事实证明，该规范实际上允许所有内容为空字符串!很难用于UI表单验证程序。

因此，我接受了他的表情，并做了一些小的补充。首先，我发现可以将路径说明符从“*”更改为“？”，以便在表单条目中，将迫使用户在“http://”之后至少键入一个“/”。这使验证器比所需的更加严格，但更为实际。

Jeff的正则表达式只使用非捕获组，因此我研究了支持捕获组的方法，因此，如果需要，可以提取URL的所有组件。

另外，请考虑非美国用户，他们通常需要在URL中输入非ASCII字符-他们想输入带重音符号的字符-但普通的验证器会拒绝Unicode字符。验证包含unicode字符的字符串，然后在实际使用前将unicode转换为'％'编码的十六进制会很不错。这需要通过将 |[\\u0080-\\U0010ffff]添加到接受ASCII的部分来扩展表达式以接受Unicode字符。

整个问题都困扰着一个测试工具，该工具可以构造一个或多个正则表达式以及给定应用程序可能需要的选项，并且可以针对各种测试字符串进行测试。因此是 URLFinderAndVerifier。

测试工具使用了从Jeff的页面获取的扩展表达式字符串，其所有空格和注释均完整无缺，并由我提供了其他注释。这些使表达式更易于阅读和理解。测试应用程序将读取文本文件并删除所有注释和空格，并根据UI中选择的选项对其进行预处理，然后设置这些注释和空格以供使用或粘贴(以便您可以在应用程序中使用它们)。测试应用程序还允许您以交互模式使用它，在该模式下，您可以在修改输入文本时进行验证。

选项:

寻找http / https，http / https / ftp或任何方案

用于表单输入，在“scheme://”之后需要一个“/”，这使得“接受”按钮的切换更加逼真(在查询的“？”和frament的“＃”之后还需要至少一个字符)

启用捕获组，因此对于每个URL提取方案，用户信息，主机，端口，路径以及(可选)查询和/或片段)

提取模式下的

，包括或排除查询和/或片段

用法:

克隆项目，并确定所需的正则表达式，然后将其粘贴到结果窗口中，并在您的应用程序中使用(适用于代码中的文本文件或NSString)

将URLFinder界面和实现文件复制到项目

中

实例化URLFinder并从第一步开始为其提供正则表达式。