スパイダー・ミドルウェア¶

スパイダー・ミドルウェアは、Scrapyのスパイダー処理メカニズムへのフックのフレームワークであり、カスタム機能をプラグインして、処理のためにスパイダーに送信されるレスポンスを処理し、スパイダーから生成されたリクエストとアイテムを処理できます。

スパイダー・ミドルウェアをアクティブにする¶

スパイダー・ミドルウェア・コンポーネントをアクティブにするには、それを SPIDER_MIDDLEWARES 設定に追加します。これは、キーがミドルウェア・クラス・パスであり、値がミドルウェアの順序値である辞書です。

以下に例があります:

SPIDER_MIDDLEWARES = {
    'myproject.middlewares.CustomSpiderMiddleware': 543,
}

SPIDER_MIDDLEWARES 設定は、Scrapyで定義された SPIDER_MIDDLEWARES_BASE 設定とマージされ(オーバーライドされることはありません)、有効なミドルウェアの最終ソート・リストを取得するために順序値の昇順にソートされます。最初がエンジンに近い方でスパイダーに近い方が最後です。つまり、各ミドルウェアの process_spider_input() メソッドは、ミドルウェアの昇順(100、200、300、…)で呼び出され、各ミドルウェアの process_spider_output() メソッドは、降順に呼び出されます。

ミドルウェアに割り当てる順序を決定するには、 SPIDER_MIDDLEWARES_BASE 設定を参照し、ミドルウェアを挿入する場所に応じて値を選択します。各ミドルウェアは異なるアクションを実行し、ミドルウェアは適用される以前の(または後続の)ミドルウェアに依存する可能性があるため、順序は重要です。

組み込みミドルウェア( SPIDER_MIDDLEWARES_BASE で定義され、デフォルトで有効になっているミドルウェア)を無効にする場合は、プロジェクトの SPIDER_MIDDLEWARES 設定で定義し、その値として None を割り当てる必要があります。たとえば、オフサイト・ミドルウェアを無効にする場合は次の通りです:

SPIDER_MIDDLEWARES = {
    'myproject.middlewares.CustomSpiderMiddleware': 543,
    'scrapy.spidermiddlewares.offsite.OffsiteMiddleware': None,
}

最後に、特定の設定で一部のミドルウェアを有効にする必要がある場合があることに注意してください。詳細については、各ミドルウェアのドキュメントを参照してください。

あなた自身のスパイダー・ミドルウェアを書く¶

各スパイダー・ミドルウェアは、以下で定義される1つ以上のメソッドを定義するPythonクラスです。

メインのエントリーポイントは from_crawler クラス・メソッドで、これは Crawler インスタンスを受け取ります。 Crawler オブジェクトは、たとえば設定へのアクセスを提供します。

class scrapy.spidermiddlewares.SpiderMiddleware¶

process_spider_input(response, spider)¶

このメソッドは、処理のためにスパイダー・ミドルウェアを通過してスパイダーに送信される各レスポンスに対して呼び出されます。

process_spider_input() は None を返すか、例外を発生させます。

None を返す場合、Scrapyはこのレスポンスの処理を続行し、最後にレスポンスがスパイダーに渡されて処理されるまで、他のすべてのミドルウェアを実行します。

例外が発生した場合、Scrapyは他のスパイダーミドルウェアの process_spider_input() を呼び出さず、リクエストがある場合はリクエストのerrbackを呼び出し、そうでない場合は process_spider_exception() チェーンを開始します。errbackの出力は、 process_spider_output() が処理するために別の方向に戻される(chain back)か、または、例外がを発生した場合は process_spider_exception() に戻り(chain back)ます。

パラメータ

response (Response object) -- 処理中のレスポンス
spider (Spider object) -- このレスポンスを意図したスパイダー

process_spider_output(response, result, spider)¶

このメソッドは、レスポンスを処理した後、Spiderから返された結果で呼び出されます。

process_spider_output() は Request オブジェクトと item object の反復可能オブジェクト(iterable)を返さなければなりません。

パラメータ

response (Response object) -- スパイダーからこの出力を生成したレスポンス
result (an iterable of Request objects and item object) -- スパイダーによって返された結果
spider (Spider object) -- 結果が処理されているスパイダー

process_spider_exception(response, exception, spider)¶

このメソッドは、スパイダーまたは、(以前のスパイダー・ミドルウェアの) process_spider_output() メソッドが例外を発生させたときに呼び出されます。

process_spider_exception() は None または Request オブジェクトと、アイテム・オブジェクトの反復可能オブジェクト(iterable)を返す必要があります。

None が返された場合、Scrapyはこの例外の処理を続行し、処理するミドルウェア・コンポーネントが無くなってエンジンに到達するまで、続くミドルウェア・コンポーネントで process_spider_exception() を実行します。

反復可能オブジェクト(iterable)を返す場合、 process_spider_output() パイプラインは次のスパイダー・ミドルウェアから開始され、他の process_spider_exception() は呼び出されません。

パラメータ

response (Response object) -- 例外が発生したときに処理されているレスポンス
exception (Exception object) -- 発生した例外
spider (Spider object) -- 例外を発生させたスパイダー

process_start_requests(start_requests, spider)¶

このメソッドは、スパイダーの開始リクエストで呼び出され、レスポンスが関連付けられておらず、リクエストのみ(アイテムではなく)を返す必要があることを除いて、 process_spider_output() メソッドと同様に機能します。

( start_requests パラメーターで)反復可能オブジェクト(iterable)を受け取り、別の Request オブジェクトの反復可能オブジェクト(iterable)を返さなければなりません。

注釈

スパイダー・ミドルウェアでこのメソッドを実装する場合、(入力に従って)常に反復可能オブジェクトを返す必要があり、start_requests イテレータを消費しないでください。 Scrapyエンジンは、リクエスト開始を処理する能力がある間はリクエスト開始求を呼ぶように設計されているため、リクエスト開始イテレータは、スパイダーを停止するための他の条件(時間制限やアイテム/ページ数など)がある場合、事実上無限になります。

パラメータ

start_requests (an iterable of Request) -- リクエストの開始
spider (Spider object) -- 開始したリクエストが属するスパイダー

from_crawler(cls, crawler)¶

存在する場合、このクラスメソッドは Crawler からミドルウェア・インスタンスを作成するために呼び出されます。ミドルウェアの新しいインスタンスを返す必要があります。クローラー・オブジェクトは、設定や信号などのすべてのScrapyコアコンポーネントへのアクセスを提供します。それはミドルウェアがそれらにアクセスし、その機能をScrapyにフックする方法です。

パラメータ: crawler (Crawler object) -- このミドルウェアを使用するクローラー

組み込みのスパイダー・ミドルウェア・リファレンス¶

この文書では、Scrapyに付属するすべてのスパイダー・ミドルウェア・コンポーネントについて説明します。それらの使用方法と独自のスパイダー・ミドルウェアの作成方法については、スパイダーミドルウェア使用ガイドを参照してください。

デフォルトで有効になっているコンポーネント(およびその順序)のリストについては、 SPIDER_MIDDLEWARES_BASE 設定を参照してください。

DepthMiddleware¶

class scrapy.spidermiddlewares.depth.DepthMiddleware[ソース]¶

DepthMiddlewareは、スクレイピングされるサイト内の各リクエストの深さを追跡するために使用されます。以前に値が設定された事がない場合は、request.meta['depth'] = 0 を設定し(通常は最初のリクエストのみ)、それ以外の場合は1インクリメントします。

スクレイピングする最大深度を制限したり、深度に基づいてリクエストの優先度を制御したりすることができます。

DepthMiddleware は次の設定で設定できます(詳細については設定ドキュメントを参照してください):

DEPTH_LIMIT - 任意のサイトでクロールできる最大深度。ゼロの場合、制限は課されません。

DEPTH_STATS_VERBOSE - 各深さのレベルでリクエスト数を収集するかどうか。

DEPTH_PRIORITY - 深さに基づいてリクエストに優先順位を付けるかどうか。

HttpErrorMiddleware¶

class scrapy.spidermiddlewares.httperror.HttpErrorMiddleware[ソース]¶: 失敗した(誤った)HTTPレスポンスをフィルター処理して、スパイダーがそれらに対処する必要がないようにします。これにより、(ほとんどの場合)オーバーヘッドが発生し、より多くのリソースが消費され、スパイダー・ロジックがより複雑になります。

HTTP standard によると、成功したレスポンスとは、ステータスコードが200〜300の範囲です。

それでもその範囲外のレスポンス・コードを処理したい場合は、 handle_httpstatus_list スパイダー属性または HTTPERROR_ALLOWED_CODES 設定を使用して、スパイダーが処理できるレスポンス・コードを指定できます。

たとえば、スパイダーに404 レスポンスを処理させたい場合、以下を行うことができます:

class MySpider(CrawlSpider):
    handle_httpstatus_list = [404]

Request.meta の handle_httpstatus_list キーを使用して、リクエストごとに許可するレスポンス・コードを指定することもできます。また、メタキー handle_httpstatus_all を True に設定すると、リクエストに対する任意のレスポンス・コードを許可し、 False で handle_httpstatus_all キーの効果を無効にすることができます。

ただし、自分が何をしているのか本当にわかっていない限り、200以外の応答を処理することは通常良くない考えです。

詳細情報は HTTP Status Code Definitions を参照ください。

HttpErrorMiddleware 設定¶

HTTPERROR_ALLOWED_CODES¶

デフォルト: []

このリストに含まれる、200以外のステータ・スコードを持つすべてのレスポンスを渡します。

HTTPERROR_ALLOW_ALL¶

デフォルト: False

ステータスコードに関係なく、すべてのレスポンスを渡します。

OffsiteMiddleware¶

class scrapy.spidermiddlewares.offsite.OffsiteMiddleware[ソース]¶

スパイダーが対象とするドメインから外れているURLのリクエストを除外します。

このミドルウェアは、スパイダーの allowed_domains 属性にない全てのホスト名のリクエストを除外します。なお、リスト内のドメインのすべてのサブドメインも許可されます。例えば、ルール www.example.org は bob.www.example.org も許可しますが、 www2.example.com も example.com も許可しません。

スパイダーがカバーするドメインに属していないドメインへのリクエストをスパイダーが返すと、このミドルウェアは、以下に似たデバッグ・メッセージを記録します:

DEBUG: Filtered offsite request to 'www.othersite.com': <GET http://www.othersite.com/some/page.html>

ログが過剰なノイズでいっぱいになるのを避けるため、フィルターされた新しいドメインごとにこれらのメッセージの1つのみを出力します。そのため、たとえば、 www.othersite.com への別のリクエストがフィルタリングされた場合、ログメッセージは出力されません。しかし、 someothersite.com へのリクエストがフィルターされると、メッセージが出力されます(ただし、フィルターされる最初のリクエストのみ)。

スパイダーが allowed_domains 属性を定義していない場合、または属性が空の場合、オフサイト・ミドルウェアはすべてのリクエストを許可します。

リクエストに dont_filter 属性が設定されている場合、そのドメインが許可されたドメインにリストされていなくても、オフサイト・ミドルウェアはリクエストを許可します。

RefererMiddleware¶

class scrapy.spidermiddlewares.referer.RefererMiddleware[ソース]¶: リクエストを生成したレスポンスのURLに基づいて、リクエスト Referer ヘッダーを生成します。

RefererMiddleware 設定¶

REFERER_ENABLED¶

デフォルト: True

リファラー・ミドルウェアを有効にするかどうか。

REFERRER_POLICY¶

デフォルト: 'scrapy.spidermiddlewares.referer.DefaultReferrerPolicy'

リクエストの "Referer" ヘッダーを設定するときに適用する Referrer Policy

注釈

Request.meta の特別な "referrer_policy" キーを使用して、 REFERRER_POLICY 設定と同じ許容値を使用して、リクエストごとにリファラー・ポリシーを設定することもできます。

REFERRER_POLICYが受け入れる値¶

scrapy.spidermiddlewares.referer.ReferrerPolicy サブクラスへのパス - カスタム・ポリシーまたは組み込みポリシーのいずれか(以下のクラスを参照)
または、標準のW3C定義の文字列値のいずれか
または特別な "scrapy-default" 。

文字列値	クラス名(文字列)
`"scrapy-default"` (デフォルト)	`scrapy.spidermiddlewares.referer.DefaultReferrerPolicy`
"no-referrer"	`scrapy.spidermiddlewares.referer.NoReferrerPolicy`
"no-referrer-when-downgrade"	`scrapy.spidermiddlewares.referer.NoReferrerWhenDowngradePolicy`
"same-origin"	`scrapy.spidermiddlewares.referer.SameOriginPolicy`
"origin"	`scrapy.spidermiddlewares.referer.OriginPolicy`
"strict-origin"	`scrapy.spidermiddlewares.referer.StrictOriginPolicy`
"origin-when-cross-origin"	`scrapy.spidermiddlewares.referer.OriginWhenCrossOriginPolicy`
"strict-origin-when-cross-origin"	`scrapy.spidermiddlewares.referer.StrictOriginWhenCrossOriginPolicy`
"unsafe-url"	`scrapy.spidermiddlewares.referer.UnsafeUrlPolicy`

class scrapy.spidermiddlewares.referer.DefaultReferrerPolicy[ソース]¶: "no-referrer-when-downgrade" の変形(variant)。さらに、親リクエストが file:// または s3:// スキームを使用している場合、 "Referer" は送信されません。

警告

" no-referrer-when-downgrade " のように、ブラウザのW3C推奨値である、Scrapyのデフォルトのリファラー・ポリシーは、ドメインが異なっていても、任意の http(s):// から空でない "Referer" ヘッダーをすべての https:// に送信します。

クロス・ドメイン・リクエストのリファラー情報を削除する場合は、 "same-origin" の方が適している場合があります。

class scrapy.spidermiddlewares.referer.NoReferrerPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-no-referrer

最も単純なポリシーは「no-referrer」です。これは、特定のリクエスト・クライアントからのリクエストとともにリファラー情報を任意のオリジン(origin)に送信しないことを指定します。ヘッダーは完全に省略されます。

class scrapy.spidermiddlewares.referer.NoReferrerWhenDowngradePolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-no-referrer-when-downgrade

"no-referrer-when-downgrade" ポリシーは、TLSで保護された環境設定オブジェクトから潜在的に信頼できるURLへのリクエスト、およびTLSで保護されていないクライアントからのリクエストとともに完全なURLを送信します。

一方、TLSで保護されたクライアントから潜在的に信頼できないURLへの要求には、リファラー情報は含まれません。 Referer HTTPヘッダーは送信されません。

ポリシーが指定されていない場合、これはユーザー・エージェントのデフォルトの振る舞いです。

注釈

"no-referrer-when-downgrade" ポリシーはW3C推奨のデフォルトであり、主要なWebブラウザーで使用されます。

ただし、それはScrapyのデフォルトのリファラー・ポリシーではありません( DefaultReferrerPolicy を参照)。

class scrapy.spidermiddlewares.referer.SameOriginPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-same-origin

"same-origin"ポリシー(同一オリジン・ポリシー)は、特定のリクエスト・クライアントから同一オリジン・リクエストを行うときに、リファラーとして使用するために取り除かれた完全なURLがリファラー情報として送信されることを指定します。

一方、クロス・オリジンリ・クエストにはリファラー情報は含まれません。リファラーHTTPヘッダーは送信されません。

class scrapy.spidermiddlewares.referer.OriginPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-origin

オリジン・ポリシーは、特定のリクエスト・クライアントから同一オリジン・リクエストとクロス・オリジン・リクエストの両方を行うときに、リクエスト・クライアントのオリジンのASCIIシリアル化のみがリファラー情報として送信されることを指定します。

class scrapy.spidermiddlewares.referer.StrictOriginPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-strict-origin

strict-originポリシーは、リクエストを行うときにリクエスト・クライアントの発信元のASCIIシリアル化を送信します。-TLSで保護された環境設定オブジェクトから潜在的に信頼できるURLへ、そして、TLSで保護されていない環境設定オブジェクトから任意のオリジンへ。

一方、TLSで保護されたリクエスト・クライアントから潜在的に信頼できないURLへのリクエストには、リファラー情報は含まれません。

class scrapy.spidermiddlewares.referer.OriginWhenCrossOriginPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-origin-when-cross-origin

origin-when-cross-originポリシーは、リファラーとして使用するために分割(strip)された完全なURLが、特定のリクエスト・クライアントから同一オリジン・リクエストを行うときにリファラー情報として送信され、リクエスト・クライアントは、特定の要求クライアントからクロス・オリジン・リクエストを行うときに、リファラー情報として送信されます。

class scrapy.spidermiddlewares.referer.StrictOriginWhenCrossOriginPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-strict-origin-when-cross-origin

strict-origin-when-cross-originポリシーは、リファラーとして使用するために取り除かれた完全なURLが、特定のリクエスト・クライアントから同一オリジン・リクエストを行うときにリファラー情報として送信されることを指定します。クロス・オリジン・リクエストを行うときのリクエスト・クライアントのオリジン:

TLSで保護された環境設定オブジェクトから潜在的に信頼できるURLへ、そして、
TLSで保護されていない環境設定オブジェクトから任意のオリジン(origin)へ。

一方、TLSで保護されたクライアントから信頼できない可能性のあるURLへの要求には、リファラー情報は含まれません。 Referer HTTPヘッダーは送信されません。

class scrapy.spidermiddlewares.referer.UnsafeUrlPolicy[ソース]¶

https://www.w3.org/TR/referrer-policy/#referrer-policy-unsafe-url

unsafe-urlポリシーは、リファラーとして使用するために分割(strip)された完全なURLが、特定のリクエスト・クライアントからのクロス・オリジン・リクエストと同一オリジン・リクエストの両方とともに送信されることを指定します。

注：ポリシーの名前に頼ってはいけません。安全ではありません。このポリシーは、TLSで保護されたリソースから安全でないオリジンにオリジンとパスをリークします。機密性の高いドキュメントに対してこのようなポリシーを設定した場合の影響を慎重に検討してください。

警告

"unsafe-url" ポリシーは 推奨されません 。

UrlLengthMiddleware¶

class scrapy.spidermiddlewares.urllength.UrlLengthMiddleware[ソース]¶

URLLENGTH_LIMITより長いURLを持つリクエストを除外します

UrlLengthMiddleware は次の設定で構成(configure)できます(詳細については設定ドキュメントをご覧ください):

URLLENGTH_LIMIT - クロールするURLの最大長。