Web机器人是能够在无摇人类干预的情况下自动进行一系列Web事务处理的软件程序。
很多机器人会从一个Web站点逛到另一个Web站点, 获取内容,跟踪超链,并对它们找到的数据进行处理。根据这些机器人自动探查Web站点的方式, 人们为它们起了一些各具特色的名字, 比如“爬虫”、“蜘蛛”、“蠕虫” 以及“机器人”等, 就好像它们都有自己的头脑一样。
一. 爬虫的爬行方式
1. 从哪里开始: 根集
挑选根集时, 应该从足够多不同的站点中选择URL, 这样,爬遍所有的链接才能最终到达大部分你感兴趣的Web页面。
2. 链接的提取以及相对链接的标准化
爬虫在Web上移动时, 会不停地对HTML页面进行解析。它要对所解析的每个页
面上的URL链接进行分析, 并将这些链接添加到需要爬行的页面列表中去。随着
爬虫的前进, 当其发现需要探查的新链接时, 这个列表常常会迅速地扩张。 爬虫
要通过简单的HTML解析, 将这些链接提取出来, 并将相对URL转换为绝对形式。
3 . 避免环路的出现
机器人必须知道它们到过何处, 以避免环路的出现。环路会造成机器人陷阱, 这些陷阱会暂停或减缓机器人的爬行进程。
4 . 循环与复制
至少出千下列三个原因, 环路对爬虫来说是有害的。
• 它们会使爬虫陷人可能会将其困住的循环之中。循环会使未经良好设计的爬虫不
臣可停地兜圈子, 把所有时间都耗费在不停地获取相同的页面上。爬虫会消耗掉很多
网络带宽, 可能完全无法获取任何其他页面了。
• 爬虫不断地获取相同的页面时, 另一端的Web服务器也在遭受着打击。如果爬
虫与服务器连接良好, 它就会击垮Web站点, 阻止所有真实用户访问这个站点。
这种拒绝服务是可以作为法律诉讼理由的。
• 即使循环自身不是什么问题,爬虫也是在获取大呈重复的页面[通常被称为"dups"
(重复), 以便与"loops" (循环)押韵 ]。爬虫应用程序会被重复的内容所充斥,
这样应用程序就会变得毫无用处。返回数百份完全相同页面的因特网搜索引擎就
是一个这样的例子。
5 . 面包屑留下的痕迹
记录曾经到过哪些地方井不总是一件容易的事,这里列出了大规模Web爬虫对其访问过的地址进行管理时使用的一些有用的技术。
• 树和散列表
复杂的机器人可能会用搜索树或散列表来记录已访问的URL。这些是加速URL查找的软件数据结构。
• 有损的存在位图
为了减小空间, 一些大弝爬虫会使用有损数据结构, 比如存在位数组(presencebit array)。用一个散列函数将每个URL都转换成一个定长的数字, 这个数字在数组中有个相关的“ 存在位” 。爬行过一个URL时, 就将相应的“ 存在位” 置位。如果存在位已经置位了, 爬虫就认为已经爬行过那个URL了。
• 检查点
一定要将已访问URL列表保存到硬盘上, 以防机器人程序崩溃。
• 分类
随若Web的扩展, 在一台计算机上通过单个机器人来完成爬行就变得不太现实了。那台计算机可能没有足够的内存、磁盘空间、计算能力, 或网络带宽来完成爬行任务。
6. 别名与机器人环路
由于URL "别名” 的存在, 即使使用了正确的数据结构, 有时也很难分辨出以前是否访问过某个页面。如果两个URL 看起来不一样, 但实际指向的是同一资源, 就称这两个URL 互为“别名” 。
9-1 同一文档的不同URL别名
第一个URL | 第二个URL | 什么时候是别名 | |
---|---|---|---|
a | http://www.foo.com/bar.html | http://www.foo.com:80/bar.html | 默认端口为80 |
b | http://www.foo.com/~fred | http://www.foo.com/%7Ffred | %7F与~相同 |
c | http://www.foo.com/x.html#arly | http://www.foo.com/x.html#middle | 标签井没有修改页面内容 |
d | http://www.foo.com/readme.htm | http://www.foo.com/README.HTM | 服务器是大小写无关的 |
e | http://www.foo.com/ | http://www.foo.com/index.html | 默认页面为index.html |
f | http://www.foo.com/index.html | http://209.231.87.45/indcx.html | www.foo.com使用这个IP地址 |
7. 规范化URL
(1) 如果没有指定端口的话, 就向主机名中添加":80"。
(2) 将所有转义符%xx都转换成等价字符。
(3) 删除#标签。
经过这些步骤就可以消除表9-1中a-c所列的别名问题了。
8. 文件系统连接环路
件系统中的符号连接会造成特定的潜在环路, 因为它们会在目录层次深度有限的情况下,造成深度无限的假象。
图 9-3 符号连接环路
图9-3b的文件系统中, 可能会发生下列情况:
(1) GET http://www.foo.com/index.html
获取 /index.html, 找到指向 subdir/index.html 的链接。
(2) GET http://www.foo.com/subdir/index.html
获取 subdir/index.html, 但得到的还是同一个 index.html。
(3) GET http://www.foo.com/subdir/subdir/index.html
获取 subdir/subdir/index.html。
(4) GET http://www.foo.com/subdir/subdir/subdir/index.html
获取 subdir/subdir/subdir/index.html。
图9-3b的问题是subdir/是个指向"!" 的环路, 但由千URL 看起来有所不同, 所以机器人无法单从URL本身判断出文档是相同的。毫无戒备的机器人就有了陷入循环的危险。
9. 动态虚拟Web空间
恶意网管可能会有意创建一些复杂的爬虫循环来陷害那些无辜的、亳无戒备的机器人。尤其是, 发布一个看起来像普通文件, 实际上却是网关应用程序的URL 是很容易的。这个应用程序可以在传输中构造出包含了到同一服务器上虚构URL 链接的HTML。请求这些虚构的URL时, 这个邪恶的服务器就会捏造出一个带有新的虚构URL的新HTML页面来。
即使这个恶意Web服务器实际上井不包含任何文件, 它也可以通过无限虚拟的Web空间将可怜的机器人带人爱丽丝漫游仙境之旅。更糟的是, 每次的URL和HTML看起来都有很大的不同, 机器人很难检测到环路。图9-4显示了一个恶意Web服务器生成假内容的例子。
比如, 我们来看一个基于CGI的日历程序, 它会生成一个月历和一个指向下个月的链接。
10. 避免循环和重复
在机器人会遇到的各种危险的Web中, 有些技术的使用可以使机器人有更好的表现。
• 规范化URL
将URL转换为标准形式以避免语法上的别名
• 广度优先的爬行
每次爬虫都有大量潜在的URL要去爬行。以广度优先的方式来调度URL去访问Web站点, 就可以将环路的影响最小化。即使碰到了机器人陷阱, 也可以在回到环路中获取的下一个页面之前, 从其他Web站点中获取成百上千的页面。如果采用深度优先方式, 一头扎到单个站点中去, 就可能会跳人环路, 永远无法访问其他站点。
• 节流
限制一段时间内机器人可以从一个Web站点获取的页面数址。如果机器人跳进了一个环路, 试图不断地访问某个站点的别名, 也可以通过节流来限制重复的页面总数和对服务器的访问总数。
• 限制URL的大小
机器人可能会拒绝爬行超出特定长度(通常是1KB) 的URL。如果环路使URL
的长度增加, 长度限制就会最终终止这个环路。有些Web服务器在使用长URL时会失败, 因此, 被URL增长环路困住的机器人会使某些Web服务器崩溃。这会让网管错误地将机器人当成发起拒绝服务攻击的攻击者。
要小心, 这种技术肯定会让你错过一些内容。现在很多站点都会用URL来管理用户的状态(比如, 在一个页面引用的URL中存储用户ID)。用URL长度来限制爬虫可能会带来些麻烦`但如果每当请求的URL达到某个特定长度时, 都记录一次错误的话, 就可以为用户提供一种检查某特定站点上所发生情况的方法。
• URL/站点黑名单
维护一个与机器人环路和陷阱相对应的已知站点及URL列表, 然后像躲避瘟疫一样避开它们。发现新问题时, 就将其加人黑名单。
这就要求有人工进行干预。但现在很多大型爬虫产品都有某种形式的黑名单, 用于避开某些存在固有问题或者有恶意的站点。还可以用黑名单来避开那些对爬行大惊小怪的站点。
• 模式检测
文件系统的符号连接和类似的错误配置所造成的环路会遵循某种模式, 比如,URL会随着组件的复制逐渐增加。有些机器人会将具有重复组件的URL当作潜在的环路, 拒绝爬行带有多千两或三个重复组件的URL。
重复并不都是立即出现的(比如,"/subdir/subdir/subdir… “)。有些环路周期可能为2或其他间隔, 比如”/subdir/images/subdir/images/subdir/images/…”。有些机器人会查找具有几种不同周期的重复模式。
• 内容指纹
一些更复杂的Web爬虫会使用指纹这种更直接的方式来检测重复。使用内容指纹的机器人会获取页面内容中的字节, 并计算出一个校验和(checksum)。这个校验和是页面内容的压缩表示形式。如果机器人获取了一个页面, 而此页面的校验和它曾经见过, 它就不会再去爬行这个页面的链接了一—如果机器人以前见过页面的内容, 它就已经爬行过页面上的链接了。
必须对校验和函数进行选择, 以求两个不同页面拥有相同校验和的几率非常低。MDS这样的报文摘要函数就常被用千指纹计算。
有些Web服务器会在传输过程中对页面进行动态的修改, 所以有时机器人会在校验和的计贷中忽略Web页面内容中的某些部分, 比如那些嵌入的链接。而且,无论定制了什么页面内容的动态服务器端包含(比如添加日期、访问计数等)都可能会阻碍重复检测。
• 人工监视
Web就是一片荒野。勇敢的机器人最终总会陷入一个采用任何技术都无能为力的闲境。设计所有产品级机器人时都要有诊断和日志功能, 这样人类才能很方便地监视机器人的进展, 如果发生了什么不寻常的事情就可以很快收到警告。在某些情况下, 愤怒的网民会给你发送一些无礼的邮件来提示你出了问题。
二. 机器人的HTTP
机器人和所有其他HTTP客户端程序井没有什么区别。它们也要遵守HTTP规范中的规则。发出HTTP请求并将自己广播成HTTP/1.1客户端的机器人也要使用正确的HTTP请求首部。
很多机器人都试图只实现请求它们所查找内容所需的最小HTIP集。这会引发一些问题,但短期内这种行为不会发生什么改变。结果就是, 很多机器人发出的都是HTTP/1.0请求, 因为这个协议的要求很少。
1. 识别请求首部
尽管机器人倾向于只支持最小的HTIP集, 但大部分机器人确实实现井发送了一些识别首部一一最值得一提的就是User-Agent 首部。建议机器人实现者们发送一些基本的首部信息, 以通知各站点机器人的能力、机器人的标识符, 以及它是从何处起源的。
在追踪错误爬虫的所有者, 以及向服务器提供机器人所能处理的内容类型时, 这些信息都是很有用的。鼓励机器人实现者们使用的基本识别首部包括如下内容。
• User-Agent
将发起请求的机器人名字告知服务器。
• From
提供机器入的用户/管理者的E-mail地址。
• Accept
告知服务器可以发送哪些媒体类型。“这有助千确保机器人只接收它感兴趣的内容(文本、图片等)。
• Referer
提供包含了当前请求URL 的文档的URL。
2. 虚拟主机
机器人实现者要支持Host 首部。随着虚拟主机(参见第5章)的浣行, 请求中不包含Host首部的话, 可能会使机器人将错误的内容与一个特定的URL关联起来。因此, HTTP/1.1要求使用Host首部。
在默认情况下, 大多数服务器都被配置为提供一个特定的站点。因此, 不包含Host首部的爬虫向提供两个站点的服务器发起请求时, 就像图9-5中的站点一样(www.joes-hardware.com和www.foo.com), 假设默认情况下服务器被配置为提供WWW.joes-hardware.com站点(且不需要Host首部), 那么, 若请求www.foo.com上的某个页面, 爬虫实际获取的就是Joe的五金商店的站点上的内容。更糟糕的是, 爬虫会认为来自Joe的五金站点上的那些内容是来自www.foo.com的。如果带有相对立的政治色彩或其他观点的两个站点是由同一台服务器提供的, 你肯定能想象到会有更不幸的局面出现。
图 9-5 发送请求时没有携带Boat首部,虚拟docroot会引发问题的例子
3. 条件请求
鉴于这些机器人的努力程度, 尽量减少机器人所要获取内容的数量通常是很有意义的。对因特网搜索引擎机器人来说, 需要下载的潜在页面有数十亿, 所以, 只在内容发生变化时才重新获取内容是很有意义的。
有些机器人实现了条件HTTP请求, “它们会对时间戳或实体标签进行比较, 看看它们最近获取的版本是否已经升级了。这与HTTP缓存查看已获取资源的本地副本是否有效的方法非常相似。更多与缓存对资源本地副本的验证有关的信息请参见第7章。
4. 对响应的处理
很多机器人的兴趣主要在千用简单的GET方法来获取所请求的内容,所以,一般不会在处理响应的方式上花费太多时间。但是,使用了某些HTTP特性(比如条件请求)的机器人,以及那些想要更好地探索服务器,井与服务器进行交互的机器人则要能够对各种不同类型的HTTP响应进行处理。
1 . 状态码
总之,机器人至少应该能够处理一些常见的,以及预期的状态码。所有机器人都应该理解200 OK和404 Not Found这样的状态码。它们还应该能够根据响应的一般类别对它并不十分理解的状态码进行处理。第3章的表3-2给出了不同状态码的分类及其含义。
有些服务器并不总能返回适当的错误代码,认识到这一点是很重要的。有些服务器甚至会将HTTP状态码200 OK与描述错误状态的报文主体文本一同返回!很难对此做些什么一只是实现者应该要了解这些情况。
2 . 实体
除了HTTP首部所嵌的信息之外,机器人也会在实体中查找信息。HTML元标签,比如元标签http-equiv, 就是内容编写者用千嵌入资源附加信息的一种方式。
胀务器可能会为它所处理的内容提供一些首部,标签http-equiv为内容编写者提供了一种覆盖这些首部的方式:
<meta http-equive="Refresh" content="1;URL=index.html">
这个标签会指示接收者处理这个文档时,要当作其HTTP响应首部中有一个值为l,URL=index.h七ml’的RefreshHTTP首部。
5. User-Agent导向
Web 管理者应该记住, 会有很多的机器人来访问它们的站点, 因此要做好接收机
器人请求的准备。很多站点会为不同的用户代理进行内容优化, 并尝试着对浏览器
类型进行检测, 以确保能够支持各种站点特性。这样的话, 当实际的HTIP 客户端
根本不是浏览器, 而是机器人的时候, 站点为机器人提供的就会是出错页面而不是
页面内容了。在某些搜索引擎上执行文本搜索, 搜索短语"your browser does not
support frames" (你的浏览器不支持框架), 会生成一个包含那条短语的出错页面
列表。
站点管理者应该设计一个处理机器人请求的策略。比如, 它们可以为所有其他特性
不太丰富的浏览器和机器人开发一些页面, 而不是将其内容限定在特定浏览器所支
持的范围。至少, 管理者应该知道机器人是会访问其站点的, 不应该在机器人访问
时感到猝不及防。
三. 行为不当的机器人
不守规矩的机器人会造成很多严重问题。这里列出了一些机器人可能会犯的错误,
及其恶劣行为所带来的后果。
• 失控机器人
机器人发起HTTP 请求的速度要比在Web 上冲浪的人类快得多, 它们通常都运
行在具有快速网络链路的高速计算机上。如果机器人存在编程逻辑错误, 或者陷
入r环路之中, 就可能会向Web 服务器发出大昼的负载——很可能会使服务器
过载, 并拒绝为任何其他人提供服务。所有的机器人编写者都必须特别小心地设
计一些保护措施, 以避免失控机器人带来的危害。
• 失效的URL
有些机器人会去访问URL 列表。这些列表可能很老了。如果一个Web 站点对其
内容进行了大量的修改, 机器入可能会对大量不存在的URL 发起请求。这会激
怒某些Web 站点的管理员, 他们不喜欢他们的错误日志中充满了对不存在文档
的访问请求, 也不希望提供出错页面的开销降低其Web 服务器的处理能力。
• 很长的错误URL
由于环路和编程错误的存在, 机器人可能会向Web 站点请求一些很大的、无意
义的URL。如果URL 足够长的话, 就会降低Web 服务器的性能, 使Web 服务
器的访问日志杂乱不堪, 甚至会使一些比较脆弱的Web服务器崩溃。
• 爱打听的机元人
有些机器人可能会得到一些指向私有数据的URL, 这样, 通过因特网搜索引擎
和其他应用程序就可以很方便地访间这些数据了。如果数据的所有者没有主动宣
传这些Web页面, 那么在最好的情况下, 他只是会认为机器人的发布行为惹人
讨厌, 而在最坏的情况下, 则会认为这种行为是对隐私的侵犯。”
通常, 发生这种情况是由千机器人所跟踪的、指向“私有“ 内容的超链已经存在
了(也就是说, 这些内容并不像其所有者认为的那么隐密, 或者其所有者忘记删
除先前存在的超链了)。偶尔也会因为机器人非常热衷干寻找某站点上的文档而
出现这种情况, 很可能就是在没有显式超链的情况下去获取某个目录的内容造
成的。
从Web上获取大量数据的机器人的实现者们应该清楚, 他们的机器人很可能会
在某些地方获得敏感的数据一站点的实现者不希望通过因特网能够访问到这些
数据。这些敏感数据可能包含密码文件, 甚至是信用卡信息。很显然, 一且被指
出, 就应该有某种机制可以将这些数据丢弃(井从所有搜索索引或归档文件中将
其删除), 这是非常重要的。现在已知一些恶意使用搜索引擎和归档的用户会利
用大型Web爬虫来查找内容一有些搜索引擎, 比如Google, 18 实际上会对它
们爬行过的页面进行归档, 这样, 即使内容被删除了, 在一段时间内还是可以找
到井访问它。
• 动态网关访问
机器人井不总是知道它们访问的是什么内容。机器人可能会获取一个内容来自
网关应用程序的URL。在这种情况下, 获取的数据可能会有特殊的目的, 计算
的开销可能很高。很多Web站点管理员并不喜欢那些去请求网关文档的幼稚机
器人。
四. 拒绝机器人访问
机器人社团能够理解机器人访问Web站点时可能引发的问题。1994年, 人们提出
了一项简单的自愿约束技术, 可以将机器人阻挡在不适合它的地方之外, 井为网站
管理员提供了一种能够更好地控制机器人行为的机制。这个标准被称为“拒绝机器
人访问标准",但通常只是根据存储访问控制信息的文件而将其称为robots.txt。
robots.txt的思想很简单。所有Web服务器都可以在服务器的文档根目录中提供一
个可选的、名为robots.txt的文件。这个文件包含的信息说明了机器人可以访问服务
器的哪些部分。如果机器人遵循这个自愿约束标准, 它会在访问那个站点的所有其臣习
他资源之前, 从Web站点请求robots.txt文件。例如, 图9-6中的机器人想要从Joe
的五金商店下载http://www.joes-hardware.com/specials/acetylene-torcbes.html。但在
机器人去请求这个页面之前, 要先去查看robots.txt文件, 看看它是否有获取这个页
面的权限。在这个例子中,robots.txt文件并没有拦截机器人, 因此机器人获取了这
个页面。
图9-6 在爬行目标文件之前,先获取robots.txt, 验证是否可以进行访问
1. 拒绝机器人访问标准
拒绝机器人访问标准是一个临时标准。编写本书的时候还没有官方标准机构承认这
个标准, 不同的厂商实现了这个标准的不同子集。但是, 具备一些对机器人访问
Web站点的管理能力, 即使井不完美, 也总比一点儿都没有要好, 而且大部分主要
的生产厂商和搜索引擎爬虫都支持这个拒绝访问标准。
尽管没有很好地定义版本的名称, 但拒绝机器人访问标准是有三个版本的。我们采
用了表9-2列出的版本编号。
表9-2 拒绝机器人访问标准的版本
版本 | 标题及描述 | 日期 |
---|---|---|
0.0 | 拒绝机器人标准-Martijo Koster提出的带右Disallow (不允许)指令的原始robots.txt机制 | 1994年6月 |
1.0 | 控制Web机器人的方法一Martijn Koster提供了额外支持Allow (允许)的IETF草案 | 1996年11月 |
2.0 | 拒绝机器人访问的扩展标准一Sean Conner提出的扩展标准, 包括了正则表达式和定时信息,没有得到广泛的支持 | 1996年11月 |
现在大多数机器人采用的都是标准vO.O 或vl.O。版本v2.0 要复杂得多, 没有得到
广泛的应用。可能永远也不会得到广泛应用。这里我们重点介绍vl.O 标准, 因为它
的应用很广泛, 而且与vO.O 完全兼容。
2. Web站点和robots.txt文件
如果一个Web站点有robots.txt文件, 那么在访问这个Web站点上的任意URL 之
前,机器人都必须获取它并对其进行处理。“由主机名和端口号定义的整个Web站
点上仅有一个robots.txt资源。如果这个站点是虚拟主机, 每个虚拟的docroot都可
以有一个不同的robots.txt文件, 像所有其他文件一样。
通常不能在Web站点上单独的子目录中安装“本地" robots.txt文件。网管要负责
创建一个聚合型robots.txt文件, 用以描述Web站点上所有内容的拒绝访问规则。
1 . 获取robots.txt
机器人会用HTTP的GET 方法来获取robots.txt资源, 就像获取Web 服务器上所有
其他资源一样。如果有robots.txt文件的话, 服务器会将其放在一个textlplain主体
中返回。如果服务器以404 Not Found HTTP 状态码进行响应, 机器人就可以认为这
个服务器上没有机器人访问限制, 它可以请求任意的文件。
机器人应该在From首部和User心gent首部中传输标识信息, 以帮助站点管理者
对机器人的访问进行跟踪, 井在站点管理者要查询, 或投诉的机器人事件中提供一
些联系信息。下面是一个来自商业Web机器人的HTTP 爬虫请求实例:
GET /robots.txt HTTP/1.0
Host: www.joes-hardware.com
User-Agent: Slurp/2.0
Date: Wed Oct 3 20:22:48 EST 2001
2 . 响应码
很多Web站点都没有robots.txt资源, 但机器人井不知道这一点。它必须尝试着从
每个站点上获取robots.txt资源。机器人会根据对robots.txt检索的结果采取不同的
行动。
• 如果服务器以—个成功状态(HTIP状态码2XX)为响应, 机器人就必须对内容
进行解析, 并使用排斥规则从那个站点上获取内容。
• 如果服务器响应说明资源并不存在(HTTP状态码404),机器人就可以认为服务
器没有激活任何排斥规则, 对此站点的访问不受robots.txt的限制。臣且
• 如果服务器响应说明有访问限制(HTTP状态码401或403),机器人就应该认为
对此站点的访问是完全受限的。
• 如果请求尝试的结果是临时故障(HITP状态码503),机器人就应该推迟对此站
点的访问, 直到可以获取该资源为止。
• 如果服务器响应说明是重定向(HTTP状态码3XX),机器人就应该跟着重定向,
直到找到资源为止。
3. robots.txt文件的格式
robots.txt文件采用了非常简单的, 面向行的语法。robots.txt文件中有三种类型的
行: 空行、注释行和规则行。规则行看起来就像HTIP首部(<Field>:<value>
一样, 用千模式匹配。比如:
# this robots.txt file allows Slurp & Webcrawler to crawl
# the public parts of our site, but no other robots ...
User-Agent: slurp
User-Agent: webcrawler
Disallow: /private
User-Agent: •
Disallow:
robots.txt文件中的行可以从逻辑上划分成“记录”。每条记录都为一组特定的机
器人描述了一组排斥规则。通过这种方式, 可以为不同的机器人使用不同的排斥
规则。
每条记录中都包含了一组规则行, 由一个空行或文件结束符终止。记录以一个
或多个User-Agent行开始, 说明哪些机器人会受此记录的影响, 后面跟着一些
Disallow和Allow行, 用来说明这些机器人可以访问哪些URL。
前面的例子显示了一个robots.txt文件, 这个文件允许机器人Slurp和Webcrawler
访问除了private子目录下那些文件之外所有的文件。这个文件还会阻止所有其他机
器人访问那个站点上的任何内容。
我们来看看User-Agent、Disallow和Allow行。
1. User-Agent行
每个机器人记录都以一个或多个下列形式的User-Agent行开始:
User-Agent: <robot-name>
或
User-Agent: *
在机器人HTIP GET请求的User-Agent首部中发送(由机器人实现者选择的)机
器人名。
机器人处理robots.txt文件时, 它所遵循的记录必须符合下列规则之一:
• 第一个<robot-name>是机器人名的大小写无关的子字符串,
• 第一个<robot-name>为"*"。
如果机器人无法找到与其名字相匹配的User-Agent行, 而且也无法找到通配的
User-Agent:*行, 就是没有记录与之匹配, 访问不受限。
由于机器人名是与大小写无关的子字符串进行匹配, 所以要小心不要匹配错了。比如,
User-Agent:bot就与名为Bot、Robot、Bottom-Feeder、Spambot 和Dont-Bother-Me
的所有机器人相匹配。
2. Disallow和Allow行
Disallow和Allow行紧跟在机器人排斥记录的User-Agent行之后。用来说明显
式禁止或显式允许特定机器人使用哪些URL路径。
机器人必须将期望访问的URL按序与排斥记录中所有的Disallow和Allow规
则进行匹配。使用找到的第一个匹配项。如果没有找到匹配项, 就说明允许使用这
个URL。
要使Allow/Disallow 行与一个URL 相匹配, 规则路径就必须是URL 路径大小写
相关的前缀。例如, Disallow: /tmp 就和下面所有的URL 相匹配:
http://www.joes-hardware.com/tmp
http://www.joes-hardware.com/tmp/
http://www.joes-hardware.com/tmp/pliers.html
http://www.joes-hardware.com/tmpspc/stuff.txt
3. Disallow/Allow前缀匹配
下面是Disallow/Allow 前缀匹配的一些细节。
• Disallow 和Allow 规则要求大小写相关的前缀匹配。(与User-Agent 行不同)这里的星号没什么特殊的含义, 但空字符串可以起到通配符的效果。
• 在进行比较之前, 要将规则路径或URL路径中所有”被转义” 的字符(%XX)都反转为字节(除了正斜杠%2F之外, 它必须严格匹配)。
• 如果规则路径为空字符串, 就与所有内容都匹配。
表9-3 列出了几个在规则路径和URL 路径间进行匹配的例子。
表9-3 robots.txt路径匹配示例
规则路径 | URL路径 | 匹配吗? | 注释 |
---|---|---|---|
/tmp | /tmp | ✓ | 规则路径==URL路径 |
/tmp | /tmpfile.html | ✓ | 规则路径是URL路径的前缀 |
/tmp | /tmp/a.htrnl | ✓ | 规则路径是URL路径的前缀 |
/tmp/ | /tmp | ✕ | /tmp/不是/tmp的前缀 |
README.TXT | ✓ | 空的规则路径匹配千所有的路径 | |
/-fred/hi.html | /% 7Efred/hi.html | ✓ | 将%7E与~同等对待 |
/% 7Efred/hi.html | /-fred小i.html | ✓ | 将%7E与~同等对待 |
/%7efred/hi.html | /%7Efred小i.html | ✓ | 转义符是大小写无关的 |
/~fred/hi.html | -fred%2Fhi.html | ✕ | %2F是一个斜杠, 但斜杠是种特殊情况, 必须完全匹配 |
前缀匹配通常都能很好地工作, 但有几种情况下它的表达力却不够强。如果你希望
无论使用什么路径前缀, 都不允许爬行一些特别的子目录, 那robots.txt 是无能为
力的。比如, 你可能希望禁止在用千RCS版本控制的子目录中爬行。除了将到达
各RCS子目录的每条路径都分别枚举出来之外, 1.0版的robots.txt 方案无法提供此
功能。
4. 其他有关robots.txt的知识
解析robots.txt文件时还甜遵循其他一些规则。
• 随着规范的发展,robots.txt文件中可能会包含除了User-Agent、Disallow和
Allow之外的其他字段。机器人应该将所有它不理解的字段都忽略掉。
• 为了实现后向兼容,不能在中间断行。
• 注释可以出现在文件的任何地方,注释包括可选的空格,以及后面的注释符(#) 、
注释符后面的注释,直到行结束符为止。
• 0.0版的拒绝机器人访问标准并不支持Allow行。有些机器人只实现了0.0版的
规范, 因此会忽略Allow行。在这种情况下, 机器人的行为会比较保守, 有些
允许访问的URL它也不去获取
5. 缓存和robots.txt的过期
如果一个机器人在每次访问文件之前都要重新获取robots.txt文件,Web服务器上
的负载就会加倍,机器人的效率也会降低。机器人使用的替代方法是,它会周期性
地获取robots.txt文件,并将得到的文件缓存起来。机器人会使用这个robots.txt文
件的缓存副本, 直到其过期为止。原始服务器和机器人都会使用标准的HTTP缓存
控制机制来控制robots.txt文件的缓存。机器人应该留意HTTP响应中的CacheControl
和Expires首部。
现在很多产品级爬虫都不是HTTP/1.1的客户端, 网管应该意识到这些爬虫不一定
能够理解那些为robots.txt资源提供的缓存指令。
如果没有提供Cache-Control指令,规范草案允许将其缓存7天。但实际上,这
个时间通常太长了。不了解robots.txt文件的Web服务器管理员通常会在响应机器
人的访问时创建一个新的文件,但如果将缺乏信息的robots.txt文件缓存一周,新创
建的robots.txt文件就没什么效果了,站点管理员会责怪机器人管理员没有遵守拒绝
机器人访问标准。
6. 拒绝机器人访问的Perl代码
有几个公共的Perl库可以用来与robots.txt文件进行交互。CPAN公共Perl文档中
的WWW: : RobotsRules模块就是一个这样的例子。
将已解析的robots.txt 文件保存在WWW:: RobotRules 对象中, 这个对象提供了一些
方法, 可以用千查看是否禁止对某指定URL 进行访问。同一个叩W:: RobotRules
可以用于解析多个robots.txt 文件。
下面是WWW: : RobotRules API 的一些主要方法。
• 创建RobotRules 对象
$rules = WWW::RobotRules->new($robot_name);
• 装载robots.txt 文件
$rules->parse($url, $content, $fresh_until);
• 查看站点URL是否可获取
$can_fetch = $rulee-:;,allowed($url);
下面这个短小的Perl 程序说明了WWW: :RobotRules 的用法:
require WWW:: RobotRules;
# Create the RobotRules object, naming the robot "SuperRobot"
my $robotsrules = new WWW: : Robo仁Rules 'SuperRobot/1.0';
use LWP::Simple qw(get);
# Get and parse the robots.txt file for Joe's Hardware, accumulating
# the rules
$url = "http://www.joes-hardware.com/robots.txt";
my $robots_txt = get $url;
$robotsrules->parse($url, $robots_txt);
# Get and parse the robots.txt file for Mary's Antiques, accumulating
# the rules
$url = "http://www.mary's antiques.com/robots.txt";
my $robots_txt ; get $url;
$robotsrules->parse($url, $robots_txt);
# Now RobotRules contains the set of robot exclusion rules for several
# different sites. It keeps them all separate. Now we can use RobotRules
# to test if a robot is allowed to access various URLs.
if ($robotsrules->allowed($some target url))
{
$c = get $url;
...
}
下面是www.marys-antiques.com 的假想robots.txt 文件:
#####################################################################
# This is the robots.txt file for Mary's Antiques web site
#####################################################################
# Keep Suzy's robot out of all the dynamic URLs because it doesn't
# understand them, and out of all the private data, except for 匕he
# small section Mary has reserved on the site for Suzy.
User-Agent: Suzy-Spider
Disallow: /dynamic
Allow: /private/suzy-stuff
Disallow: /private.
# The Furniture-Finder robot was specially designed to understand
# Mary's antique store's furniture inventory program, so let it
# crawl that resource, but keep it out of all the other dynamic
# resources and out of all the private data.
Oser-Agent: Furniture-Finder
Allow: /dynamic/check-inventory
Disallow: /dynamic
Disallow: /private
# Keep everyone else out of the dynamic gateways and private data.
User-Agent: *
Disallow: /dynamic
Disallow: /private
这个robots.txt 文件中包含了一条机器人SuzySpider 的记录, 一条机器人FumitureFinder
的记录, 以及一条用千所有其他机器人的默认记录。每条记录都对不同的机器人使
用了一组不同的访问策略。
• SuzySpider 的排斥记录不允许机器人爬行以/dynamic 开头的商店库存网关URL,以及在为Suzy 保留的区域之外的其他私有用户数据。
• FumitureFinder 机器人的记录允许机器人爬行家具库存网关URL。这个机器人可能能够理解Mary 的网关格式和规则。
• 其他机器人都不能访问所有的动态和私有Web 页面, 但它们可以爬行其余的URL。
表9-4 列出了几个机器人实例, 这几个机器人具有不同的Mary 古董网站访问权限。
表9-4 Mary古董网站的机器人访问权限
URL | SuzySpider | FumitureFlnder | NosyBot |
---|---|---|---|
http://www.marys-antiques.com/ | ✓ | ✓ | ✓ |
http:/lwww.marys-antiques.com/index.html | ✓ | ✓ | ✓ |
http://www.marys-antiques.com/private/payroll.xls | X | X | X |
http://www.marys-antiques.com/private/suzy-stuff/taxes.txt | ✓ | X | X |
http://www.marys-antiques.com/dynamic/buy-stuff?id=3546 | X | X | X |
http://www.marys-antiques.com/dynamic/chcck-inventory?kitchen | X | ✓ | X |
7. HTML的robot-control元标签
robots.txt 文件允许站点管理员将机器人排除在Web 站点的部分或全部内容之外。
robots.txt 文件的一个缺点就是它是Web 站点管理员, 而不是各部分内容的作者所
有的。
HTML 页面的作者有一种更直接的方式可以限制机器人访问那些独立的页面。他
们可以直接在HMTL 文档中添加robot-control 标签。遵循robot-control
HTML 标签规则的机器人仍然可以获取文档, 但如果其中有机器人排斥标签, 它们
就会忽略这些文档。比如, 因特网搜索引擎机器人就不会在其搜索索引中包含这个
目录了。和robots.txt 标准一样, 鼓励但并不强制使用这个标签。
机器人排斥标签是以如下形式, 通过HTML 的META 标签来实现的:
<META NAME="ROBOTS" CONTENT=directive-liat>
1. 机器人的META指令
机器人META 指令有几种不同的类型, 而且随着时间的推移, 以及搜索引擎及机器
人对其行为和特性集的扩展, 很可能还会添加一些新的指令。最常用的两个机器人
META 指令如下所示。
• NOINDEX
告诉机器人不要对页面的内容进行处理, 忽略文档(也就是说, 不要在任何索引
或数据库中包含此内容)。
<META NAME="ROBOTS" CONTENT="NOINOEX">
• NOFOLLOW
告诉机器人不要爬行这个页面的任何外连链接。
<META NAME="ROBOTS" CONTENT皿"NOFOLLOW">
除了NOINDEX和NOFOLLOW 之外, 还有相对应的INDEX 指令、FOLLOW 指令、
NOARCHIVE 指令以及ALL和NONE 指令。下面对这些机器人META标签指令进行
了总结。
• INDEX
告诉机器人它可以对页面的内容进行索引。
• FOLLOW
告诉机器人它可以爬行页面上的任何外连链接。
• NOARCHIVE
告诉机器人不应该缓存这个页面的本地副本。
• ALL
等价千INDEX、FOLLOW。
• NONE
等价于NOINDEX 、NOFOLLOW 。
与所有HTML 的META标签类似, 机器人META标签必须出现在HTML 页面的HEAD区域中:
<html>
<head>
<meta name="robots" content="noindex,nofollow">
<title> ... </title>
</head>
<body>
...
</body>
</html>
注意,标签的名称robots和内容都是大小写无关的。
很显然, 不能发出一些会产生冲突或重复的指令, 比如:
<meta name="robots" content="INDEX,NOINDEX,NOFOLLOW,FOLLOW,FOLLOW">
这种指令的行为很可能是未定义的, 肯定会随机器人实现的不同而有所不同。
2. 搜索引擎的META标签
我们刚刚讨论了机器人的META 标签, 可以用来控制Web 机器人的爬行和索引行
为。所有的机器人META 标签中都包含了name:“robots” 属性。
还有很多其他类型的META 标签可用, 包括表9-5 所示的各种标签。对内容索引型
搜索引擎机器人来说, DESCRIPTION 和KEYWORDS META 标签都非常有用。
表9-5 其他META标签指令
name= | content= | 描述 |
---|---|---|
DESCRIPTION | <文本> | 允许作者为Web页面定义一个短小的文本摘要. 很多搜索引擎都会查看META DESCRIPTION标签, 允许页面作者指定一些短小的摘要来描述其Web页面 |
<meta name=“description” content=“Welcome to Mary’s Antiques Web site”> | ||
KEYWORDS | <逗号列表> | 关联一个由逗号分隔的Web页面描述词列表, 为关键字搜索提供帮助 |
<meta name=“keywords” content=“antiques,mary,furniture,reatoration”> | ||
REVISIT-AFTER | <天数> | 告诉机器入或搜索引擎应该在指定天数之后重访页面,估计那时候页面可能会发生变化 |
<meta name=“revisit-after” content=“10 days”> |
5. 机器人的规范
1993 年, Web 机器人社会的先驱Martijn Koster 为Web 机器人的编写者们编写了
一个指南列表。有些建议已经过时了, 但有很多建议仍然非常有用。在http://www.
robotstxt.org/wc/guidelines.html 上可以找到Martijn 的原始论文"Guidelines for
Robot Writers"。
表9-6是为机器人设计者和操作人员提供的现代更新, 这些更新的建议主要还是建
立在原始列表的思想和内容之上的。大部分指南都是针对万维网机器人提出的,但
它们同样适用千较小规模的爬虫。
表9-6 Web机器人操作员指南
操作指南 | 描述 |
---|---|
(1)识别 | |
识别你的机器入 | 用HITP的User-Agent字段将机器人的名字告诉Web服务器。这样可以帮助管理员理解机器人所做的事情。有些机器人还会在User-Agent首部包含一个描述机器入目的和策略的URL |
识别你的机器 | 确保机器人是从一台带有DNS条目的机器上运行的,这样Web站点才能够将机器人的IP地址反向DNS为主机名。这有助于管理者识别出对机器人负资的组织 |
识别联络人 | 用HTTP的From字段提供一个联络的E-mail地址 |
(2)操作 | |
保持警惕 | 机器人可能会惹一些麻烦或引发一些抱怨. 其中一些是由那些行为有偏差的机器人造成的. 一定要小心, 注意保持机器人的正常行为. 如果机器人要全天候运行, 就要格外小心。需要有操作人员不间断地对机器人进行监视, 直到它有了丰富的经验为止 |
做好准备 | 开始一次重要的机菩人之旅时, 一定要通知你所在的组织. 你的组织可能要观测网络带宽的耗费, 作好应对各种公共查询的准备 |
监视并记录日志 | 机器入应该装备有丰富的诊断和日志记录工具, 这样才能记录进展、识别所有的机器人陷阱` 进行完整性桧壹看看工作是否正常。监视井记录机器人行为的重要性怎么强调也不过分. 问题和抱怨总是会有的, 对爬虫行为的详细记录, 有助千机器人操作者回溯所发生的事情. 不管是为了调试出错的Web爬虫, 还是为了在不合理的投诉面前为其行为进行辩护, 监视和记录工作都是非常重要的 |
学习并适应 | 在每次爬行中你都会学到新的东西. 要让机器人逐步适应, 这样, 它在每次爬行之后都会有所进步, 并能避开一些常见的陷阱 |
(3)约束自己的行为 | |
对URL进行过滤 | 如果一个URL指向的好像是你不理解或不感兴趣的数据, 你可能会希望跳过它。比如, 以.z、.gz 、.tar或者.zip结尾的URL很可能是压缩文件或归档文件。以.exe结尾的URL可能就是程序. 以.gif、tif、.jpg结尾的URL很可能是图片。要确保你得到的就是你想要的 |
过滤动态URL | 通常, 机器人不会想去爬行来自动态网关的内容. 机器人不知道应该如何正确地格式化查询请求, 井将其发送给网关, 而它得到的结果也很可能是错误的或临时的. 如果一个URL中包含了cgi, 或者有一个“?飞机器人可能就不会去爬行这个URL了 |
对Accept首部进行过滤 | 机器人应该用HTTP的Accept首部来告诉服务器它能够理解哪种内容 |
遵循robots.txt | 机器人应该接受站点上robots.txt的控制 |
制约自己 | 机器人应该记录访间每个站点的次数以及访间的时间, 井通过这些信息来确保它没有太频繁地访问某个站点.机器入访问站点的频率高于儿分钟一次时, 管理员就要起疑心了.机器人每隔几秒钟就访问一次站点时, 有些管理员就会生气了。机器人尽可能频繁地去访间一个站点, 将所有其他浣量都拒之门外时, 管理员就会暴怒起来。 |
总之, 应该限制机器人, 使其每分钟最多只发送几条请求, 并确保每条请求之间有儿秒钟的间隔.还应该限制对站点的访间总次数, 以防止环路的出现 | |
(4)容忍存在环路、熏复和其他问题 | |
处理所有返回代码 | 必须做好处理所有HTTP状态码的准备, 包括各种重定向和错误码。还应该对这些代码进行记录和监视.如果某站点出现大量不成功的结果, 就应该对其进行调查。可能是很多URL过期了, 或者服务器拒绝向机器人提供这些文档 |
规范URL | 试诸将所有URL都转化为标准形式来消除常见的别名 |
积极地避免环路的出现 | 努力地检测并避免环路的出现。将操纵爬虫的过程当作一个反馈回路。应该将问题的结果和解决方法回馈到下一次爬行中, 使爬虫在每次迭代之后都能表现得更 |
监视陷阱 | 有些环路是故意造成的恶意环路. 这些环路可能很难检测。有的站点会带有一些怪异的URL, 要监视对这类站点进行的大量访问。这种情况可能就是陷阱 |
维护一个黑名单 | 找到陷阱、环路、故障站点和不希望机器人访问的站点时, 要将其加人一个黑名单, 不要再次访问这些站点 |
(5)可扩展性 | |
了解所需空间 | 享先通过数学计算明确你要解决的问题规摸有多大. 你可能会对应用程序完成一项机器人任务所需的内存规模感到非常吃惊, 这是由Web庞大的规模造成的 |
了解所需带宽 | 了解你有多少网络带宽可用, 以及在要求的时间内完成机器人任务所需的带宽大小。监视网络带宽的实际使用情况。你很可能会发现输出带宽(请求)要比输入带宽(响应)小得多。通过对网络使用情况的监视, 可能还会找到一些方法来更好地优化你的机器人, 通过更好地使用其TCP连接更好地利用网络带宽 |
了解所需的时间 | 了解机器人完成其任务所需花费的时间, 检查这个进度是否与自己的估计相符. 如果机器人的耗费与自己的估计相去甚远, 可能就会有问题, 需要进行调查 |
分而治之 | 对大规模的爬行来说, 很可能需要使用更多的硬件来完成这项工作, 可以使用带有多个网卡的大型多处理器服务器, 也可以使用多台较小的计算机共同配合工作 |
(6)可靠性 | |
彻底测试 | 在将机器人放出去之前. 要对其进行彻底的内部测试. 作好非现场测试准备时, 要先进行几次小型的处女航。收集大量结果井对性能和内存使用情况进行分析, 估计一下它们会怎样累积成较大问题 |
检查点 | 所有严谨的机器人都要保存其进展的快照, 出现故障时可以从那里重新开始。故障总是存在的:你会发现一些软件的bug, 硬件也会出故障. 大规模机器人不能在每次出现这种情况时都从头开始. 一开始就要设计检查点/熏启机制 |
故障恢复 | 预测故障的发生. 对机器人进行设计、使其能够在发生故障时继续工作 |
(7)公共关系 | |
做好准备 | 机器人可能会让很多人感到困惑. 要作好快速响应其询问的准备。制定一个Web页面政策声明, 对机器人进行描述, 其中包括创建robots.txt文件的详细指南 |
充分理解 | 有些与你联系, 讨论机器人问题的人是了解情况并赞成的, 有些人则很幼稚. 少数人会异常愤怒. 有些人看起来好像都要发疯了。去争辩机器人的努力有多么重要通常是没什么效果的. 向他们解释拒绝机器人访问标准,如果他们仍然很不高兴, 就立即将投诉者的URL从爬行列表中删除. 并将其加人黑名单 |
积极响应 | 大多数不满意的网管都只是不太了解机器人. 如果你能够进行迅速且专业的响应,90%的投诉都会很快消失. 另一方面, 如果你等好几天才响应.而机器人在继续访问这个站点, 你面对的就将是一个非常愤怒的对手 |
六. 搜索引擎
得到最广泛使用的Web机器入都是因特网搜索引擎。因特网搜索引擎可以帮助用户
找到世界范围内涉及任意主题的文档。
现在Web上很多最流行的站点都是搜索引擎。很多Web用户将其作为起始点, 它
们会为用户提供宝贵的服务, 帮助用户找到他们感兴趣的信息。
Web爬虫为因特网搜索引擎提供倌息, 它们获取Web上的文档, 并允许搜索引擎
创建与本书后面的索引类似的索引, 用以说明哪些文档中有哪些词存在。搜索引擎
是Web机器人的主要来源-让我们来快速了解一下它们是如何工作的。
1. 大格局
Web发展的初期, 搜索引擎就是一些相当简单的数据库, 可以帮助用户在Web上
定位文档。现在, Web上有数十亿可供访问的页面, 搜索引擎已经成为因特网用户
查找信息不可缺少的工具。它们在不断地发展, 以应对Web庞大的规模, 因此, 现
在已经变得相当复杂了。
面对数十亿的Web页面, 和数百万要查找信息的用户, 搜索引擎要用复杂的爬虫
来获取这数十亿Web页面, 还要使用复杂的查询引擎来处理数百万用户产生的查
询负荷。
我们来考虑一下产品级Web爬虫的任务, 它要获取搜索索引所需的页面, 它要发出
数十亿条HTTP请求。如果每条请求都要花半秒钟的时间(对有些服务器来说可能
慢了, 对另一些服务器来说可能快了), (对十亿份文件来说)就要花费:
0.5秒X (100 0000 000) / (60秒/天) X (60分/小时) X (24小时/天)
如果请求是连续发出的, 结果差不多是5700天!很显然, 大型爬虫得更聪明一些,
要对请求进行并行处理, 并使用大扯机器来完成这项任务。但由于其规模庞大, 爬
行整个Web仍然是件十分艰巨的任务。
2. 现代搜索引擎结构
现在的搜索引擎都构建了一些名为“全文索引” 的复杂本地数据库, 装载了全世界
的Web页面, 以及这些页面所包含的内容。这些索引就像Web上所有文档的卡片
目录一样。臣习
搜索引擎爬虫会搜集Web页面, 把它们带回家, 并将其添加到全文索引中去。同
时, 搜索引擎用户会通过HotBot (http://www.hotbot.com)或Google (http://www.
google.com)这样的Web搜索网关对全文索引进行查询。Web页面总是在不断地
发生变化, 而且爬行一大块Web要花费很长的时间, 所以全文索引充其量也就是
Web的一个快照。
现代搜索引擎的高层结构如00 9-7所示。
3. 全文索引
全文索引就是一个数据库, 给它一个单词, 它可以立即提供包含那个单词的所有文
档。创建了索引之后, 就不需要对文档自身进行扫描了。
图9-7 产品级搜索引擎中包含了一些协作的爬虫和查询网关
图9-8显示了三份文档和相应的全文索引。全文索引列出了包含每个单词的文档。
图9-8 三份文档和一个全文索引
比如:
• 单词"a"位千文档A和B中,
• 单词"best 位千文档A和C中,
• 单词"drill"位千文档A和B中,
• 单词"routine"位于文档B和C中,
• 单词"the" 位于所有的三份文档A、B和C中。
4. 发布查询请求
用户向Web搜索引擎网关发布一条请求时, 会填写一个HTML表单, 他的浏览器
会用一个HTTP GET或POST请求将这个表单发送给网关。网关程序对搜索请求进
行解析, 并将WebUI查询转换成搜索全文索引所需的表达式。28
图9-9显示了一条对www.joes-hardware.com站点的简单用户查询。用户在搜索框
表单中输入drills, 然后浏览器就会将这个动作转换成一条在URL中包含请求参数
的GET请求。29Joe的五金商店的Web服务器收到这条请求, 并将其转发给其搜索
网关应用程序, 这个程序会将文档的结果列表返回给Web服务器,然后Web服务
器又会将这些结果转换成HTML页面提供给用户。
图9-9 搜索查询请求的实例
5. 对结果进行排序, 井提供查询结果
一旦搜索引擎通过其索引得到了查询结果, 网关应用程序会获取结果, 并将其拼成结果页面提供给终端用户。
很多Web页面都可能包含任意指定的单词,所以搜索引擎采用了一些很聪明的算
法, 尝试着对结果进行排名。比如, 在图9-8中, 单词best出现在很多文档中, 为
了将相关度最高的结果提供给用户, 搜索引擎要知道应该按照什么顺序来提供结果
列表中的文档。这被称为相关性排名(relevancy ranking) -这是对一系列搜索结
果的评分和排序处理。
为了更好地辅助这一进程, 在爬行Web的过程中都会进行数据统计。比如, 对指向
指定页面的链接进行计数有助千判断其流行程度, 还可以用此信息来衡量提供结果
的顺序。算法、爬行中获取的辅助信息以及搜索引擎所使用的其他技巧都是保守最森严的秘密。
6. 欺诈
在搜索请求得到的前几个结果中没有看到自己想要查找的内容时, 用户通常会感到
很沮丧, 因此,查找站点时搜索结果的顺序是很重要的。在搜索网管们认为能够最
好地描述其站点功能的单词时,会有众多因素激励着这些网管, 努力使其站点排在
靠近结果顶端的位置上, 尤其是那些依赖千用户找到它们, 并使用其服务的商业
站点。
这种对较好排列位置的期待引发了很多对搜索系统的博弈, 也在搜索引擎的实现者
和那些想方设法要将其站点列在突出位置的人之间引发了持久的拉锯战。很多网
管都列出了无数关键字(有些是亳不相关的), 使用一些假冒页面, 或者采用欺诈
(spoof)行为-甚至会用网关应用程序来生成一些在某些特定单词上可以更好地
欺骗搜索引擎相关性算法的假冒页面。
这么做的结果就是, 搜索引擎和机器人实现者们要不断地修改相关性算法, 以便更
有效地抓住这些欺诈者。
七. 更多信息
更多有关Web客户端的信息, 请参见下列资料。
• http://www.robotstxt.org/wc/robots.html
Web机器人页面一机器人开发者所需的资源,包括因特网机器人的登记注册。
• http://www.searchengineworld.com
搜索引擎世界-搜索引擎和机器人的相关资源。
• http://www.searchtools.com
Web站点和内部网络的搜索工具一搜索工具和机器人的相关资源。
• http://search.cpan.org/doc/lL YAZ/perl_ste/WWW /RobotRules. pm
RobotRules的Perl语言资源。
• http://www.conman.org/people/spc/robots2.html
拒绝机器人访问的扩展标准。
• Managing Gigabytes: Compressing and Indexing Documents and Images (《海量数据管理一文档和图像的压缩与索引》)
Witten, I.、Moffat, A. 和Bell, T. 编写, Morgan Kaufmann公司出版。