记录 ---- 网络爬虫

网络爬虫

网络爬虫(web crawler)可以在无需人类干预的状况下自动进行一系列Web事务处理的软件程序。不少爬虫会从一个Web站点逛到另外一个Web站点，获取内容，跟踪超链，并对它们找到的数据进行处理。根据这些爬虫自动探查Web站点的方式，网络爬虫也可称做网络蜘蛛、蚂蚁、机器人等。

爬虫及爬行方式

Web爬虫会递归地对各类信息性Web站点进行遍历，获取第一个Web页面，而后获取那个页面指向的全部Web页面，而后是那些页面指向的全部Web页面，依此类推。递归地追踪这些Web连接的爬虫会沿着HTML超链建立的网络"爬行"，因此将其称为爬虫(crawler)或蜘蛛(spider)。因特网搜索引擎使用爬虫在Web上游荡，并把它们碰到的文档所有拉回来。而后对这些文档进行处理，造成一个可搜索的数据库，以便用户查找包含了特定单词的文档。网上有数万亿的Web页面须要查找和取回，这些搜索引擎必然是些最复杂的爬虫。

从根集开始

在把饥饿的爬虫放出去以前，须要给它一个起始点。爬虫开始访问的URL初始集合被称做根集(root set)。挑选根集时，应该从足够多不一样的站点中选择URL，这样，爬遍全部的连接才能最终到达大部分你感兴趣的Web页面。根集中并不须要有不少页面，就能够涵盖一大片Web结构，一般，一个好的根集会包括一些大的流行Web站点，好比，一个新建立页面的列表和一个不常常被连接的无名页面列表。不少大规模的爬虫产品，好比因特网搜索引擎使用的那些爬虫，都为用户提供了向根集中提交新页面或无名页面的方式。这个根集会随时间推移而增加，是全部新爬虫的种子列表。

连接的提取以及相对连接的标准化

爬虫在Web上移动时，会不停地对HTML页面进行解析。它要对所解析的每一个页面上的URL连接进行分析，并将这些连接添加到须要爬行的页面列表中去。随着爬虫的前进，当其发现须要探查的新连接时，这个列表经常会迅速地扩张。爬虫要经过简单的HTML解析，将这些连接提取出来，并将相对URL转换为绝对形式。

避免环路的出现

爬虫在Web上爬行时，要特别当心不要陷入循环，或环路(cycle)之中。爬虫必须知道它们到过何处，以免环路的出现。环路会形成爬虫陷阱，这些陷阱会暂停或减缓爬虫的爬行进程。

循环与复制

至少出于下列三个缘由，环路对爬虫来讲是有害的：

• 它们会使爬虫陷入可能会将其困住的循环之中。循环会使未经良好设计的爬虫不停地兜圈子，把全部时间都耗费在不停地获取相同的页面上。爬虫会消耗掉不少网络带宽，可能彻底没法获取任何其余页面了。
• 爬虫不断地获取相同的页面时，另外一端的Web服务器也在遭受着打击。若是爬虫与服务器链接良好，它就会击垮Web站点，阻止全部真实用户访问这个站点。这种拒绝服务是能够做为法律诉讼理由的。
• 即便循环自身不是什么问题，爬虫也是在获取大量重复的页面[一般被称为"dups"(重复)，以便与"loops"(循环)押韵]。爬虫应用程序会被重复的内容所充斥，这样应用程序就会变得毫无用处。返回数百份彻底相同页面的因特网搜索引擎就是一个这样的例子。

记录曾经到过哪些地方

记录曾经到过哪些地方并不老是一件容易的事。因特网上有数十亿个不一样的Web页面，其中还不包括那些由动态网关产生的内容。若是要爬行世界范围内的一大块Web内容，就要作好访问数十亿URL的准备。记录下哪些URL已经访问过了是件很具挑战的事情。因为URL的数量巨大，因此，要使用复杂的数据结构以便快速断定哪些URL是曾经访问过的。数据结构在访问速度和内存使用方面都应该是很是高效的。数亿URL须要具有快速搜索结构，因此速度是很重要的。穷举搜索URL列表是根本不可能的。爬虫至少要用到搜索树或散列表，以快速断定某个URL是否被访问过。数亿URL还会占用大量的空间。

大规模Web爬虫对其访问过的地址进行管理时使用的一些有用的技术：

• 树和散列表：复杂的爬虫可能会用搜索树或散列表来记录已访问的URL。这些是加速URL查找的软件数据结构。
• 有损的存在位图：为了减少空间，一些大型爬虫会使用有损数据结构，好比存在位数组(presence bit array)。用一个散列函数将每一个URL都转换成一个定长的数字，这个数字在数组中有个相关的"存在位"。爬行过一个URL时，就将相应的"存在位"置位。若是存在位已经置位了，爬虫就认为已经爬行过那个URL了。
• 检查点：必定要将已访问URL列表保存到硬盘上，以防爬虫程序崩溃。
• 分布式：随着Web的扩展，在一台计算机上经过单个爬虫来完成爬行就变得不太现实了。那台计算机可能没有足够的内存、磁盘空间、计算能力，或网络带宽来完成爬行任务。有些大型Web爬虫会使用爬虫"集群"，每一个独立的计算机是一个爬虫，以汇接方式工做。为每一个爬虫分配一个特定的URL"片"，由其负责爬行。这些爬虫配合工做，爬行整个Web。爬虫个体之间可能须要相互通讯，来回传送URL，以覆盖出故障的对等实体的爬行范围，或协调其工做。

别名与爬虫环路

因为URL"别名"的存在，即便使用了正确的数据结构，有时也很难分辨出之前是否访问过某个页面。若是两个URL看起来不同，但实际指向的是同一资源，就称这两个URL互为"别名"。

规范化URL

大多数Web爬虫都试图经过将URL"规范化"为标准格式来消除上面那些显而易见的别名。爬虫首先可先将每一个URL都转化为规范化的格式，就能够消除大部分别名问题了。但若是不知道特定Web服务器的相关信息，爬虫就没什么好办法来避免别名问题了。URL规范化能够消除一些基本的语法别名，但爬虫还会遇到其余的、将URL转换为标准形式也没法消除的URL别名。

经过下列步骤将每一个URL都转化为规范化的格式：

• 若是没有指定端口的话，就向主机名中添加":80"。
• 将全部转义符"%xx"都转换成等价字符。
• 删除"#"标签。

特定Web服务器的相关信息：

• 爬虫须要知道Web服务器是不是大小写无关的才能避免别名问题。
• 爬虫须要知道Web服务器上这个目录下的索引页面配置才能知道是不是别名。
• 即便爬虫知道主机名和IP地址都指向同一台计算机，它也还要知道Web服务器是否配置为进行虚拟主机操做，才能知道这个URL是否是别名。

文件系统链接环路

文件系统中的符号链接会形成特定的潜在环路，由于它们会在目录层次深度有限的状况下，形成深度无限的假象。符号链接环路一般是由无意错误形成的，但也可能会恶意地为爬虫制造这样的陷阱。

动态虚拟Web空间

可能会有意建立一些复杂的循环来陷害那些无辜的、毫无戒备的爬虫。尤为是，发布一个看起来像普通文件，实际上倒是网关应用程序的URL是很容易的。这个应用程序能够在传输中构造出包含了到同一服务器上虚构URL连接的HTML。请求这些虚构的URL时，服务器就会捏造出一个带有新的虚构URL的新HTML页面来。即便这个Web服务器实际上并不包含任何文件，它也能够经过无限虚拟的Web空间将爬虫带入"梦境"。更糟的是，每次的URL和HTML看起来都有很大的不一样，爬虫很难检测到环路。更常见的状况是，可能会在无心中经过符号链接或动态内容构造出爬虫陷阱。好比，一个基于CGI的日历程序，它会生成一个月历和一个指向下个月的连接。真正的用户是不会不停地请求下个月的连接的，但不了解其内容的动态特性的爬虫可能会不断向这些资源发出无穷的请求。

避免循环和重复

没有什么简单明了的方式能够避免全部的环路。实际上，通过良好设计的爬虫中要包含一组试探方式，以免环路的出现。总的说来，爬虫的自动化程度越高(人为的监管越少)，越可能陷入麻烦之中。爬虫的实现者须要作一些取舍——这些试探方式有助于避免问题的出现，但你可能会终止扫描那些看起来可疑的有效内容，所以这种方式也是"有损失"的。爬行Web这样规模庞大的数据集时，好的爬虫探测法老是会不断改进其工做的。随着新的资源类型不断加入Web，它会随着时间的推移构建出一些新的规则，并采纳这些规则。好的规则老是在不断发展之中的。当受到错误爬虫影响的资源(服务器、网络带宽等)处于可管理状态，或者处于执行爬行工做的人的控制之下(好比在内部站点上)时，不少较小的、更具个性的爬虫就会绕开这些问题。这些爬虫更多的是依赖人类的监视来防止这些问题的 发生。

爬虫会遇到的各类危险的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。重复并不都是当即出现的。有些环路周期可能为2或其余间隔。有些爬虫会查找具备几种不一样周期的重复模式。
• 内容指纹：一些更复杂的Web爬虫会使用指纹这种更直接的方式来检测重复。使用内容指纹的爬虫会获取页面内容中的字节，并计算出一个校验和(checksum)。这个校验和是页面内容的压缩表示形式。若是爬虫获取了一个页面，而此页面的校验和它曾经见过，它就不会再去爬行这个页面的连接了——若是爬虫之前见过页面的内容，它就已经爬行过页面上的连接了。必须对校验和函数进行选择，以求两个不一样页面拥有相同校验和的概率很是低。MD5这样的报文摘要函数就常被用于指纹计算。有些Web服务器会在传输过程当中对页面进行动态的修改，因此有时爬虫会在校验和的计算中忽略Web页面内容中的某些部分，好比那些嵌入的连接。并且，不管定制了什么页面内容的动态服务器端包含(好比添加日期、访问计数等)均可能会阻碍重复检测。
• 人工监视：Web就是一片荒野。勇敢的爬虫最终总会陷入一个采用任何技术都无能为力的困境。设计全部产品级爬虫时都要有诊断和日志功能，这样人类才能很方便地监视爬虫的进展，若是发生了什么不寻常的事情就能够很快收到警告。在某些状况下，愤怒的网民会给你发送一些无礼的邮件来提示你出了问题。

爬虫的HTTP

爬虫和全部其余HTTP客户端程序并无什么区别。它们也要遵照HTTP规范中的规则。发出HTTP请求并将本身广播成"HTTP/1.1"客户端的爬虫也要使用正确的HTTP请求首部。不少爬虫都试图只实现请求它们所查找内容所需的最小HTTP集。这会引起一些问题；但短时间内这种行为不会发生什么改变。结果就是，不少爬虫发出的都是"HTTP/1.0"请求，由于这个协议的要求不多。

识别请求首部

尽管爬虫倾向于只支持最小的HTTP集，但大部分爬虫确实实现并发送了一些识别首部——最值得一提的就是User-Agent首部。建议爬虫实现者们发送一些基本的首部信息，以通知各站点爬虫的能力、爬虫的标识符，以及它是从何处起源的。

在追踪错误爬虫的全部者，以及向服务器提供爬虫所能处理的内容类型时，这些信息都是颇有用的。鼓励爬虫实现者们使用的基本识别首部包括以下内容：

• User-Agent：将发起请求的爬虫名字告知服务器。
• From：提供爬虫的用户/管理员的E-mail地址。
• Accept：告知服务器能够发送哪些媒体类型。这有助于确保爬虫只接收它感兴趣的内容(文本、图片等)。
• Referer：提供包含了当前请求URL的文档的URL。

虚拟主机

爬虫实现者要支持Host首部。随着虚拟主机的流行，请求中不包含Host首部的话，可能会使爬虫将错误的内容与一个特定的URL关联起来。所以，"HTTP/1.1"要求使用Host首部。在默认状况下，大多数服务器都被配置为提供一个特定的站点。所以，不包含Host首部的爬虫向提供两个站点的服务器发起请求时。

条件请求

尽可能减小爬虫所要获取内容的数量一般是颇有意义的。对因特网搜索引擎爬虫来讲，须要下载的潜在页面有数十亿，因此，只在内容发生变化时才从新获取内容是颇有意义的。有些爬虫实现了条件HTTP请求，它们会对时间戳或实体标签进行比较，看看它们最近获取的版本是否已经升级了。这与HTTP缓存查看已获取资源的本地副本是否有效的方法很是类似。

对响应的处理

不少爬虫的兴趣主要在于用简单的GET方法来获取所请求的内容，因此，通常不会在处理响应的方式上花费太多时间。可是，使用了某些HTTP特性(好比条件请求)的爬虫，以及那些想要更好地探索服务器，并与服务器进行交互的爬虫则要可以对各类不一样类型的HTTP响应进行处理。

• 状态码：爬虫至少应该可以处理一些常见的，以及预期的状态码。全部爬虫都应该理解"200 OK"和"404 Not Found"这样的状态码。它们还应该可以根据响应的通常类别对它并不十分理解的状态码进行处理。
• 实体：除了HTTP首部所嵌的信息以外，爬虫也会在实体中查找信息。HTML元标签(好比元标签http-equiv)，就是内容编写者用于嵌入资源附加信息的一种方式。服务器可能会为它所处理的内容提供一些首部，标签http-equiv为内容编写者提供了一种覆盖这些首部的方式(meta http-equiv="Refresh" content="1;URL=index.html")。这个标签会指示接收者处理这个文档时，要看成其HTTP响应首部中有一个值为"1, URL=index.html"的"Refresh HTTP"首部。有些服务器实际上会在发送HTML页面以前先对其内容进行解析，并将http-equiv指令做为首部包含进去；有些服务器则不会。爬虫实现者可能会去扫描HTML文档的HEAD组件，以查找http-equiv信息。

User-Agent导向

Web管理员应该记住，会有不少的爬虫来访问它们的站点，所以要作好接收爬虫请求的准备。不少站点会为不一样的用户代理进行内容优化，并尝试着对浏览器类型进行检测，以确保可以支持各类站点特性。这样的话，当实际的HTTP客户端根本不是浏览器，而是爬虫的时候，站点为爬虫提供的就会是出错页面而不是页面内容了。在某些搜索引擎上执行文本搜索，搜索短语"your browser does not support frames"(你的浏览器不支持框架)，会生成一个包含那条短语的出错页面列表。站点管理员应该设计一个处理爬虫请求的策略。好比，它们能够为全部其余特性不太丰富的浏览器和爬虫开发一些页面，而不是将其内容限定在特定浏览器所支持的范围。至少，管理员应该知道爬虫是会访问其站点的，不该该在爬虫访问时感到猝不及防。

行为不当的爬虫

不守规矩的爬虫会形成不少严重问题：

• 失控爬虫：爬虫发起HTTP请求的速度要比在Web上冲浪的人类快得多，它们一般都运行在具备快速网络链路的高速计算机上。若是爬虫存在编程逻辑错误，或者陷入了环路之中，就可能会向Web服务器发出大量的负载——极可能会使服务器过载，并拒绝为任何其余人提供服务。全部的爬虫编写者都必须特别当心地设计一些保护措施，以免失控的爬虫带来的危害。
• 失效的 URL：有些爬虫会去访问URL列表。这些列表可能很老了。若是一个Web站点对其内容进行了大量的修改，爬虫可能会对大量不存在的URL发起请求。这会激怒某些Web站点的管理员，他们不喜欢他们的错误日志中充满了对不存在文档的访问请求，也不但愿提供出错页面的开销下降其Web服务器的处理能力。
• 很长的错误 URL：因为环路和编程错误的存在，爬虫可能会向Web站点请求一些很大的、无心义的URL。若是URL足够长的话，就会下降Web服务器的性能，使Web服务器的访问日志杂乱不堪，甚至会使一些比较脆弱的Web服务器崩溃。
• 爱打听的爬虫：有些爬虫可能会获得一些指向私有数据的URL，这样，经过因特网搜索引擎和其余应用程序就能够很方便地访问这些数据了。若是数据的全部者没有主动宣传这些Web页面，那么在最好的状况下，他只是会认为爬虫的发布行为惹人讨厌，而在最坏的状况下，则会认为这种行为是对隐私的侵犯。一般，发生这种状况是因为爬虫所跟踪的、指向"私有"内容的超链已经存在了(也就是说，这些内容并不像其全部者认为的那么隐密，或者其全部者忘记删除先前存在的超链了)。偶尔也会由于爬虫很是热衷于寻找某站点上的文档而出现这种状况，极可能就是在没有显式超链的状况下去获取某个目录的内容形成的。从Web上获取大量数据的爬虫的实现者们应该清楚，他们的爬虫极可能会在某些地方得到敏感的数据——站点的实现者不但愿经过因特网可以访问到这些数据。这些敏感数据可能包含密码文件。很显然，一旦被指出，就应该有某种机制能够将这些数据丢弃(并从全部搜索索引或归档文件中将其删除)，这是很是重要的。如今已知一些恶意使用搜索引擎和归档的用户会利用大型Web爬虫来查找内容——有些搜索引擎， 实际上会对它们爬行过的页面进行归档，这样，即便内容被删除了，在一段时间内仍是能够找到并访问它。
• 动态网关访问：爬虫并不老是知道它们访问的是什么内容。爬虫可能会获取一个内容来自网关应用程序的URL。在这种状况下，获取的数据可能会有特殊的目的，计算的开销可能很高。不少Web站点管理员并不喜欢那些去请求网关文档的幼稚爬虫。

拒绝爬虫访问

爬虫社团可以理解爬虫访问Web站点时可能引起的问题。1994 年，人们提出了一项简单的自愿约束技术，能够将爬虫阻挡在不适合它的地方以外，并为网站管理员提供了一种可以更好地控制爬虫行为的机制。这个标准被称为"拒绝爬虫访问标准"，但一般只是根据存储访问控制信息的文件而将其称为"robots.txt"。"robots.txt"的思想很简单。全部Web服务器均可以在服务器的文档根目录中提供一个可选的、名为"robots.txt"的文件。这个文件包含的信息说明了爬虫能够访问服务器的哪些部分。若是爬虫遵循这个自愿约束标准，它会在访问那个站点的全部其余资源以前，从Web站点请求"robots.txt"文件。

拒绝爬虫访问标准

拒绝爬虫访问标准是一个临时标准。不一样的厂商实现了这个标准的不一样子集。可是，具有一些对爬虫访问Web站点的管理能力，即便并不完美，也总比一点儿都没有要好，并且大部分主要的生产厂商和搜索引擎爬虫都支持这个拒绝访问标准。如今大多数爬虫采用的都是标准v0.0或v1.0。版本v2.0要复杂得多，没有获得普遍的应用。

Web站点和robots.txt文件

若是一个Web站点有"robots.txt"文件，那么在访问这个Web站点上的任意URL以前，爬虫都必须获取它并对其进行处理。由主机名和端口号定义的整个Web站点上仅有一个"robots.txt"资源。若是这个站点是虚拟主机，每一个虚拟的docroot均可以有一个不一样的robots.txt文件，像全部其余文件同样。一般不能在Web站点上单独的子目录中安装"本地robots.txt文件"。管理员要负责建立一个聚合型"robots.txt"文件，用以描述Web站点上全部内容的拒绝访问规则。

• 获取robots.txt：爬虫会用HTTP的GET方法来获取"robots.txt"资源，就像获取Web服务器上全部其余资源同样。若是有"robots.txt"文件的话，服务器会将其放在一个"text/plain"主体中返回。若是服务器以"404 Not Found"HTTP状态码进行响应，爬虫就能够认为这个服务器上没有爬虫访问限制，它能够请求任意的文件。爬虫应该在From首部和User-Agent首部中传输标识信息，以帮助站点管理员对爬虫的访问进行跟踪，并在站点管理员要查询，或投诉的爬虫事件中提供一些联系信息。

• 响应码：不少Web站点都没有"robots.txt"资源，但爬虫并不知道这一点。它必须尝试着从每一个站点上获取"robots.txt"资源。爬虫会根据对"robots.txt"检索的结果采起不一样的行动。

  • 若是服务器以一个成功状态(HTTP状态码2XX)为响应，爬虫就必须对内容进行解析，并使用排斥规则从那个站点上获取内容。
  • 若是服务器响应说明资源并不存在(HTTP状态码404)，爬虫就能够认为服务器没有激活任何排斥规则，对此站点的访问不受"robots.txt"的限制。
  • 若是服务器响应说明有访问限制(HTTP状态码401或403)，爬虫就应该认为对此站点的访问是彻底受限的。
  • 若是请求尝试的结果是临时故障(HTTP状态码503)，爬虫就应该推迟对此站点的访问，直到能够获取该资源为止。
  • 若是服务器响应说明是重定向(HTTP状态码3XX)，爬虫就应该跟着重定向，直到找到资源为止。

robots.txt文件的格式

"robots.txt"文件采用了很是简单的，面向行的语法。"robots.txt"文件中有三种类型的行：空行、注释行和规则行。规则行看起来就像HTTP首部同样，用于模式匹配。"robots.txt"文件中的行能够从逻辑上划分红"记录"。每条记录都为一组特定的爬虫描述了一组排斥规则。经过这种方式，能够为不一样的爬虫使用不一样的排斥规则。每条记录中都包含了一组规则行，由一个空行或文件结束符终止。记录以一个或多个User-Agent行开始，说明哪些爬虫会受此记录的影响，后面跟着一些Disallow和Allow行，用来讲明这些爬虫能够访问哪些URL。

此例显示了一个"robots.txt"文件，这个文件容许爬虫Slurp和Webcrawler访问除了private子目录下那些文件以外全部的文件。这个文件还会阻止全部其余爬虫访问那个站点上的任何内容。

# 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:

• User-Agent行：每一个爬虫记录都以一个或多个下列形式的User-Agent行开始。在爬虫"HTTP GET"请求的User-Agent首部中发送(由爬虫实现者选择的)爬虫名。若是爬虫没法找到与其名字相匹配的User-Agent行，并且也没法找到通配的"User-Agent:*"行，就是没有记录与之匹配，访问不受限。

爬虫处理"robots.txt"文件时，它所遵循的记录必须符合下列规则之一：

• 第一个robot-name是爬虫名的大小写无关的子字符串；
• 第一个robot-name为“*”。

• Disallow和Allow行：Disallow和Allow行紧跟在爬虫排斥记录的User-Agent行以后。用来讲明显式禁止或显式容许特定爬虫使用哪些URL路径。爬虫那个必须将指望访问的URL按序与排斥记录中全部的Disallow和Allow规则进行匹配。使用找到的第一个匹配项。若是没有找到匹配项，就说明容许使用这个URL。要使Allow/Disallow行与一个URL相匹配，规则路径就必须是URL路径大小写相关的前缀。
• Disallow/Allow 前缀匹配：前缀匹配一般都能很好地工做，但有几种状况下它的表达力却不够强。若是但愿不管使用什么路径前缀，都不容许爬行一些特别的子目录，那"robots.txt"是无能为力的。

Disallow/Allow前缀匹配的一些细节：

• Disallow和Allow规则要求大小写相关的前缀匹配。(与User-Agent行不一样)这里的"*"(星号)没什么特殊的含义，但空字符串能够起到通配符的效果。
• 在进行比较以前，要将规则路径或URL路径中全部"被转义"的字符(%XX)都反转为字节(除了正斜杠%2F以外，它必须严格匹配）。
• 若是规则路径为空字符串，就与全部内容都匹配。

其余有关robots.txt的知识

<p>解析 robots.txt 文件时还需遵循其余一些规则。</p>

• 随着规范的发展，"robots.txt"文件中可能会包含除了User-Agent、Disallow和Allow以外的其余字段。爬虫应该将全部它不理解的字段都忽略掉。
• 为了实现后向兼容，不能在中间断行。
• 注释能够出如今文件的任何地方；注释包括可选的空格，以及后面的注释符(#)、注释符后面的注释，直到行结束符为止。
• 0.0版的拒绝爬虫访问标准并不支持Allow行。有些爬虫只实现了0.0版的规范，所以会忽略Allow行。在这种状况下，爬虫的行为会比较保守，有些容许访问的URL它也不去获取。

缓存和robots.txt的过时

若是一个爬虫在每次访问文件以前都要从新获取"robots.txt"文件，Web服务器上的负载就会加倍，爬虫的效率也会下降。爬虫使用的替代方法是，它会周期性地获取"robots.txt"文件，并将获得的文件缓存起来。爬虫会使用这个robots.txt文件的缓存副本，直到其过时为止。原始服务器和爬虫都会使用标准的HTTP存控制机制来控制"robots.txt"文件的缓存。爬虫应该留意HTTP响应中的Cache-Control和Expires首部。如今不少产品级爬虫都不是"HTTP/1.1"的客户端；管理员应该意识到这些爬虫不必定可以理解那些为"robots.txt"资源提供的缓存指令。若是没有提供Cache-Control指令，规范草案容许将其缓存7天。但实际上，这个时间一般太长了。不了解"robots.txt"文件的Web服务器管理员一般会在响应爬虫的访问时建立一个新的文件，但若是将缺少信息的"robots.txt"文件缓存一周，新建立的"robots.txt"文件就没什么效果了，站点管理员会责怪爬虫管理员没有遵照拒绝爬虫访问标准。

搜索引擎

获得最普遍使用的Web爬虫都是因特网搜索引擎。因特网搜索引擎能够帮助用户找到世界范围内涉及任意主题的文档。如今Web上不少最流行的站点都是搜索引擎。不少Web用户将其做为起始点，它们会为用户提供宝贵的服务，帮助用户找到他们感兴趣的信息。Web爬虫为因特网搜索引擎提供信息，它们获取Web上的文档，并容许搜索引擎建立索引，用以说明哪些文档中有哪些词存在。搜索引擎是Web爬虫的主要来源。

大格局

Web发展的初期，搜索引擎就是一些至关简单的数据库，能够帮助用户在Web上定位文档。如今，Web上有数十亿可供访问的页面，搜索引擎已经成为因特网用户查找信息不可缺乏的工具。它们在不断地发展，以应对Web庞大的规模，所以，如今已经变得至关复杂了。

面对数十亿的Web页面，和数百万要查找信息的用户，搜索引擎要用复杂的爬虫来获取这数十亿Web页面，还要使用复杂的查询引擎来处理数百万用户产生的查询负荷。产品级Web爬虫的任务，要获取搜索索引所需的页面，它要发出数十亿条HTTP请求。若是每条请求都要花半秒钟的时间(对有些服务器来讲可能慢了，对另外一些服务器来讲可能快了)。若是请求是连续发出的，结果差很少是5700天！很显然，大型爬虫得更聪明一些，要对请求进行并行处理，并使用大量服务器来完成这项任务。但因为其规模庞大，爬行整个Web仍然是件十分艰巨的任务。

现代搜索引擎结构

如今的搜索引擎都构建了一些名为"全文索引"的复杂本地数据库，装载了全世界的Web页面，以及这些页面所包含的内容。这些索引就像Web上全部文档的卡片目录同样。搜索引擎爬虫会搜集Web页面，把它们带回家，并将其添加到全文索引中去。同时，搜索引擎用户会经过HotBot或Google这样的Web搜索网关对全文索引进行查询。Web页面老是在不断地发生变化，并且爬行一大块Web要花费很长的时间，因此全文索引充其量也就是Web的一个快照。

全文索引

全文索引就是一个数据库，给它一个单词，它能够当即提供包含那个单词的全部文档。建立了索引以后，就不须要对文档自身进行扫描了。

发布查询请求

用户向Web搜索引擎网关发布一条请求时，会填写一个HTML表单，他的浏览器会用一个HTTP GET或POST请求将这个表单发送给网关。网关程序对搜索请求进行解析，并将Web UI查询转换成搜索全文索引所需的表达式。

对结果进行排序，并提供查询结果

旦搜索引擎经过其索引获得了查询结果，网关应用程序会获取结果，并将其拼成结果页面提供给终端用户。不少Web页面均可能包含任意指定的单词，因此搜索引擎采用了一些很聪明的算法，尝试着对结果进行排名。为了将相关度最高的结果提供给用户，搜索引擎要知道应该按照什么顺序来提供结果列表中的文档。这被称为相关性排名(relevancy ranking)——这是对一系列搜索结果的评分和排序处理。为了更好地辅助这一进程，在爬行Web的过程当中都会进行数据统计。好比，对指向指定页面的连接进行计数有助于判断其流行程度，还能够用此信息来衡量提供结果的顺序。算法、爬行中获取的辅助信息以及搜索引擎所使用的其余技巧都是保守最森严的秘密。

欺诈

在搜索请求获得的前几个结果中没有看到本身想要查找的内容时，用户一般会感到很沮丧，所以，查找站点时搜索结果的顺序是很重要的。在搜索管理员们认为可以最好地描述其站点功能的单词时，会有众多因素激励着这些管理员，努力使其站点排在靠近结果顶端的位置上，尤为是那些依赖于用户找到它们，并使用其服务的商业站点。这种对较好排列位置的期待引起了不少对搜索系统的博弈，也在搜索引擎的实现者和那些千方百计要将其站点列在突出位置的人之间引起了持久的拉锯战。不少管理员都列出了无数关键字(有些是绝不相关的)，使用一些假冒页面，或者采用欺诈行为——甚至会用网关应用程序来生成一些在某些特定单词上能够更好地欺骗搜索引擎相关性算法的假冒页面。这么作的结果就是，搜索引擎和爬虫实现者们要不断地修改相关性算法，以便更有效地抓住这些欺诈者。