4

我目前正在使用以下正则表达式来验证 URL：

^(?#Protocol)(?:(?:ht|f)tp(?:s?)\:\/\/|~\/|\/)?(?#Username:Password)(?:\w+:\w+@)?  (?#Subdomains)(?:(?:[-\w]+\.)+(?#TopLevel Domains)(?:com|org|net|gov|mil|biz|edu|info|mobi|name|aero|jobs|museum|travel|[a-z]{2}))(?#Port)(?::[\d]{1,5})?(?#Directories)(?:(?:(?:\/(?:[-\w~!$+|.,=]|%[a-f\d]{2})+)+|\/)+|\?|#)?(?#Query)(?:(?:\?(?:[-\w~!$+|.,*:]|%[a-f\d{2}])+=?(?:[-\w~!$+|.,*:=]|%[a-f\d]{2})*)(?:&(?:[-\w~!$+|.,*:]|%[a-f\d{2}])+=?(?:[-\w~!$+|.,*:=]|%[a-f\d]{2})*)*)*(?#Anchor)(?:#(?:[-\w~!$+|.,*:=]|%[a-f\d]{2})*)?$

我从网络上的某个地方借了这个（不记得在哪里）来改进这个：

^((https?|file|ftp|gopher|news|nntp):\/\/)([a-z]([a-z0-9\-]*\.)+([a-z]{2}|aero|arpa|biz|com|coop|edu|gov|info|int|jobs|mil|museum|name|nato|net|org|pro|travel)|(([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5])\.){3}([0-9]|[1-9][0-9]|1[0-9]{2}|2[0-4][0-9]|25[0-5]))(\/[a-z0-9_\-\.~]+)*(\/([a-z0-9_\-\.]*)(\?[a-z0-9+_\-\.%=&]*)?)?(#[a-z][a-z0-9_]*)?$

但是，这些都不能验证这个 url（应该是有效的）：

http://somedomain.com/users/1234/images/Staff%20Photos%202008/FirstName%20LastName_1%20(Small).jpg

问题是 %20 和圆括号 ()。尽我所能，我无法让上面的任何一个正则表达式都正确验证上面的 url 而不会破坏其他东西。我没有编写花哨的正则表达式的经验，所以这也无济于事。我发现的所有其他网络结果在诸如此类的愚蠢事情上都失败了：

http://www.test..com

帮助将不胜感激。

4

1 回答 1

4

您正在使用相同的正则表达式验证两件事：

  • 格式正确——语法正确吗？
  • 似是而非——协议和顶级域是否似是而非？

分离这些验证可能是富有成效的。您可以使用此正则表达式来检查 URI 的格式是否正确。它来自RFC 3986，统一资源标识符 (URI)：通用语法，附录 B（第 50 页）：

^(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(\?([^#]*))?(#(.*))?

如果 URI 与此正则表达式匹配，则它的格式正确。比赛组为您提供各种作品，它们是：

scheme    = $2
authority = $4
path      = $5
query     = $7
fragment  = $9

让我们看看您提供的示例 URI 的结果：

2 (scheme)   : "http"
4 (authority): "somedomain.com"
5 (path)     : "/users/1234/images/Staff%20Photos%202008/FirstName%20LastName_1%20(Small).jpg"
7 (query)    : nil
9 (fragment) : nil

现在您已经获得了各个部分，您可以检查每个部分的合理性。例如，要从权威机构获取 TLD，请将此正则表达式应用于权威机构：

\.([^.])$

第 1 组为您提供 TLD（com、org 等），然后您可以对照您的列表进行检查。

于 2010-01-18T01:57:42.083 回答