因此,如果用户 1 输入“ http://www.facebook.com/index.php ”,用户 2 输入“ http://facebook.com ”,用户 3 输入“www.facebook.com”,我该怎么做最好将它们“转换”为所有这些都解决的问题:“ http://www.facebook.com/ ”
您将通过修复无效 URL 来解决用户 3。www.facebook.com
不是一个 URL,但你可以猜到它http://
应该从一开始就开始。空路径部分与/
路径相同,因此您可以确定它也需要继续。一个好的 URL 解析器应该能够做到这一点。
您可以通过向 URL 发出 HTTP HEAD 请求来解析用户 2。如果返回状态码为301
,则您将永久重定向到Location
响应标头中的真实 URL。Facebook 这样做是为了向 发送facebook.com
流量www.facebook.com
,这绝对是网站应该做的事情(即使在现实世界中很多都不是)。您可能允许考虑允许3xx
系列中的其他重定向状态代码执行相同的操作;这不是真正正确的做法,但有些网站使用302
而不是301
重定向,因为它们有点厚。
如果您有时间和网络资源(加上更多代码以防止您或其他人滥用该功能),您还可以考虑获取目标网页并对其进行解析(假设它不是 HTML)。如果页面中有<link rel="canonical" href="..." />
元素,您还应该将该 URL 视为正确的 URL。(查看源代码:堆栈溢出就是这样做的。)
但是,很遗憾,用户 1 的情况无法解决。Facebook 提供一个页面/
和一个页面/index.php
,虽然我们可以查看它们并说它们是相同的,但没有描述这种关系的技术方法。在理想的世界中,Facebook 将包含301
重定向响应或<link rel="canonical" />
告诉人们这/
是访问特定资源的正确格式 URL,而不是/index.php
(反之亦然)。但他们没有,事实上大多数数据库驱动的网站也没有这样做。
为了解决这个问题,一些搜索引擎 (*) 比较不同 [子] 域中的内容,并且在有限的范围内还比较同一主机上的不同路径,如果内容足够相似,则猜测它们是相同的。当然,这是一项繁重的工作,需要大量的存储和处理,并且最终并不是非常可靠。
除了像在用户 3 案例中那样修复 URL 之外,我真的不会为此烦恼太多。根据您的描述,“相同”的页面必须共享实际身份似乎并不重要,除非您没有提到特定的用例。
(*:好吧,无论如何,谷歌;更传统的传统上没有并且很乐意为同一页面提供多个链接,但我认为其他专业现在正在做类似的事情。)