假设我需要编写一个函数来搜索文本块以查找类似于URL的内容,并将该部分文本包装在HTML <a href="...">anchor</a>
标记中。假设其中一个要求规定该函数必须能够检测到缺少协议和路径组件的独立域名,如example.com
,并将其转换为http://example.com
的链接。
使用JavaScript中的正则表达式将快速模型放在一起:
function htmlify(sourceText) {
var detector = /([^\s]+\.(?:com|net| ...SNIP... |org|biz))/g;
return sourceText.replace(detector, function(match, p1) {
return '<a href="http://' + p1 + '">' + p1 + '</a>';
});
}
效果很好,但detector
正则表达式需要列出当前存在于世界上的所有TLD。几年前这个列表将保持相对静态,但现在通用TLD正在不断注册,这个正则表达式会很快变得陈旧。但没问题吧?只需从IANA site中拉出列表,解析并过滤它,动态构建一个新的正则表达式...包并部署应用程序...和...... bleh。这很快变得丑陋。
然而,当我在Chrome或Firefox地址栏中输入dad.coffee
并按Enter键时,我会直接转到that domain,而不是将其视为搜索字词。他们是如何做到的呢?他们是否使用不断更新的数据库并将输入文本与其进行比较?他们正在进行DNS查找预取,试图查看它是否会返回NXDOMAIN吗?更聪明的东西?
另外:要求本身是否存在根本缺陷?假设有人输入了这个文本,显然不应该是域名:
SELECT posts.id FROM posts;
.id
是有效的TLD,因此posts.id
将成为指向非预期网站的链接。我没有看到防止这种情况的方法,这让我相信问题可能没有一个理想的解决方案。或者是吗?
编辑:我使用Wireshark和Chrome进行了一些测试。似乎在DNS中查找看起来像FQDN的任何地址栏输入。甚至单个单词也会根据系统DNS搜索列表中的每个域后缀进行检查。这与谷歌的一系列HTTPS流量混合在一起,这很可能会填充“按类型查找”列表。不确定Google是否“帮助”浏览器做出最终决定,或者是否完全是客户端的。
答案 0 :(得分:1)
首先你问:
他们是怎么做到的?
Firefox没有。在Firefox中,没有TLD的验证。如果您将dad.coffeeandmilk
粘贴到地址par并按Enter键,Firefox也会尝试将您带到那里,您将获得:
Firefox无法在www.dad.coffeeandmilk找到服务器。
其次你问:
问题可能没有一个理想的解决方案。或者是吗?
你的预感是对的。无法确保您可以在100%的时间内删除“虚假”域名,因为TLD可以在其他环境中发生,例如VB.NET
。但是,这里有一些提示可以帮助您完成任务:
一个。几年前,人们不再尝试匹配每个TLD。您可能仍然会发现一些大型正则表达式与电子邮件地址相匹配,但它们仅适用于体育精神。
B中。您可以尝试删除您知道不应该发生网址的某些上下文。例如,如果您有SQL字符串的清晰标记,则可以将它们取出。见Match a Pattern Except in Situations s1 s2 s3
℃。为了说明A点,这是您今天在RegexBuddy库中找到的URL(删除http部分):
[-A-Z0-9+&@#/%?=~_|$!:,.;]*[A-Z0-9+&@#/%=~_|$]
答案 1 :(得分:0)
您可以简单地对xxx.yyy
形式的任何内容进行DNS查找。通过点连接的单词在域名之外的文本中并不常见,因此这不应导致过多的DNS查找。您可以保留结果缓存以避免冗余查找。
有一个上下文,这样的单词很常见,但是:编程代码。如果您有任何类型的标记提示代码已发布,请不要尝试在这些块中查找URL。