摘要：網絡爬蟲網絡爬蟲能夠在無需人類干預的情況下自動進行一系列事務處理的軟件程序。根據這些爬蟲自動探查站點的方式，網絡爬蟲也可稱作網絡蜘蛛螞蟻機器人等。遞歸地追蹤這些鏈接的爬蟲會沿著超鏈創建的網絡爬行，所以將其稱為爬蟲或蜘蛛。

網絡爬蟲(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互為"別名"。

大多數Web爬蟲都試圖通過將URL"規范化"為標準格式來消除上面那些顯而易見的別名。爬蟲首先可先將每個URL都轉化為規范化的格式，就可以消除大部分別名問題了。但如果不知道特定Web服務器的相關信息，爬蟲就沒什么好辦法來避免別名問題了。URL規范化可以消除一些基本的語法別名，但爬蟲還會遇到其他的、將URL轉換為標準形式也無法消除的URL別名。

通過下列步驟將每個URL都轉化為規范化的格式：

如果沒有指定端口的話，就向主機名中添加":80"。

將所有轉義符"%xx"都轉換成等價字符。

刪除"#"標簽。

特定Web服務器的相關信息：

爬蟲需要知道Web服務器是否是大小寫無關的才能避免別名問題。

爬蟲需要知道Web服務器上這個目錄下的索引頁面配置才能知道是否是別名。

即使爬蟲知道主機名和IP地址都指向同一臺計算機，它也還要知道Web服務器是否配置為進行虛擬主機操作，才能知道這個URL是不是別名。

文件系統中的符號連接會造成特定的潛在環路，因為它們會在目錄層次深度有限的情況下，造成深度無限的假象。符號連接環路通常是由無心錯誤造成的，但也可能會惡意地為爬蟲制造這樣的陷阱。

可能會有意創建一些復雜的循環來陷害那些無辜的、毫無戒備的爬蟲。尤其是，發布一個看起來像普通文件，實際上卻是網關應用程序的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/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信息。

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站點上的任意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"文件中有三種類型的行：空行、注釋行和規則行。規則行看起來就像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 文件時還需遵循其他一些規則。

隨著規范的發展，"robots.txt"文件中可能會包含除了User-Agent、Disallow和Allow之外的其他字段。爬蟲應該將所有它不理解的字段都忽略掉。

為了實現后向兼容，不能在中間斷行。

注釋可以出現在文件的任何地方；注釋包括可選的空格，以及后面的注釋符(#)、注釋符后面的注釋，直到行結束符為止。

0.0版的拒絕爬蟲訪問標準并不支持Allow行。有些爬蟲只實現了0.0版的規范，因此會忽略Allow行。在這種情況下，爬蟲的行為會比較保守，有些允許訪問的URL它也不去獲取。

如果一個爬蟲在每次訪問文件之前都要重新獲取"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的過程中都會進行數據統計。比如，對指向指定頁面的鏈接進行計數有助于判斷其流行程度，還可以用此信息來衡量提供結果的順序。算法、爬行中獲取的輔助信息以及搜索引擎所使用的其他技巧都是保守最森嚴的秘密。

在搜索請求得到的前幾個結果中沒有看到自己想要查找的內容時，用戶通常會感到很沮喪，因此，查找站點時搜索結果的順序是很重要的。在搜索管理員們認為能夠最好地描述其站點功能的單詞時，會有眾多因素激勵著這些管理員，努力使其站點排在靠近結果頂端的位置上，尤其是那些依賴于用戶找到它們，并使用其服務的商業站點。這種對較好排列位置的期待引發了很多對搜索系統的博弈，也在搜索引擎的實現者和那些想方設法要將其站點列在突出位置的人之間引發了持久的拉鋸戰。很多管理員都列出了無數關鍵字(有些是毫不相關的)，使用一些假冒頁面，或者采用欺詐行為——甚至會用網關應用程序來生成一些在某些特定單詞上可以更好地欺騙搜索引擎相關性算法的假冒頁面。這么做的結果就是，搜索引擎和爬蟲實現者們要不斷地修改相關性算法，以便更有效地抓住這些欺詐者。