ダウンローダー・ミドルウェア¶
ダウンローダー・ミドルウェアは、Scrapyのリクエスト/レスポンス処理へのフックのフレームワークです。Scrapyのリクエストとレスポンスをグローバルに変更するための軽量で低レベルのシステムです。
ダウンローダーミドルウェアをアクティブにする¶
ダウンローダー・ミドルウェア・コンポーネントを有効にするには、それを DOWNLOADER_MIDDLEWARES
設定に追加します。これは、キーがミドルウェア・クラス・パスであり、値がミドルウェアの順序である辞書です。
ここに例があります:
DOWNLOADER_MIDDLEWARES = {
'myproject.middlewares.CustomDownloaderMiddleware': 543,
}
DOWNLOADER_MIDDLEWARES
設定は、Scrapyで定義された DOWNLOADER_MIDDLEWARES_BASE
設定とマージされ(オーバーライドされることはありません)、有効なミドルウェアの最終ソートリストを取得するために順序でソートされます。1つはエンジンに近く、最後はダウンローダーに近いものです。つまり、各ミドルウェアの process_request()
メソッドは、ミドルウェアの昇順(100、200、300…)で呼び出され、各ミドルウェアの process_response()
メソッドは、降順で呼び出されます。
ミドルウェアに割り当てる順序を決定するには、 DOWNLOADER_MIDDLEWARES_BASE
設定を参照し、ミドルウェアを挿入する場所に応じて値を選択します。各ミドルウェアは異なるアクションを実行し、ミドルウェアは適用される以前の(または後続の)ミドルウェアに依存する可能性があるため、順序は重要です。
組み込みのミドルウェア( DOWNLOADER_MIDDLEWARES_BASE
で定義され、デフォルトで有効になっているミドルウェア)を無効にするには、プロジェクトの DOWNLOADER_MIDDLEWARES
設定で定義し、その値として None
を割り当てる必要があります。たとえば、ユーザーエージェントミドルウェアを無効にする場合、以下の通りです:
DOWNLOADER_MIDDLEWARES = {
'myproject.middlewares.CustomDownloaderMiddleware': 543,
'scrapy.downloadermiddlewares.useragent.UserAgentMiddleware': None,
}
最後に、特定の設定で一部のミドルウェアを有効にする必要がある場合があることに注意してください。詳細については、各ミドルウェアのドキュメントを参照してください。
あなた自身のダウンローダー・ミドルウェアを書く¶
各ダウンローダー・ミドルウェアは、以下で定義される1つ以上のメソッドを定義するPythonクラスです。
メインのエントリー・ポイントは from_crawler
クラス・メソッドで、これは Crawler
インスタンスを受け取ります。 Crawler
オブジェクトは、たとえば 設定 へのアクセスを提供します。
- class scrapy.downloadermiddlewares.DownloaderMiddleware¶
注釈
どのダウンローダー・ミドルウェア・メソッドも遅延オブジェクト(deferred)を返す場合があります。
- process_request(request, spider)¶
このメソッドは、ダウンロード・ミドルウェアを通過するリクエストごとに呼び出されます。
process_request()
の結果は次のいずれかでなければなりません:None
を返す、Response
オブジェクトを返す、Request
オブジェクトを返す、IgnoreRequest
例外を起こす。None
を返した場合、Scrapyはこのリクエストの処理を続け、最終的に適切なダウンローダー・ハンドラーが実行されたリクエスト(およびダウンロードされたレスポンス)が呼ばれるまで、他のすべてのミドルウェアを実行します。Response
オブジェクトを返す場合、Scrapyは他の 任意のprocess_request()
メソッドまたはprocess_exception()
メソッド、または適切なダウンロード関数の呼び出しを考慮しません。そのレスポンスオブジェクトそのものを返します。なお、インストールされたミドルウェアのprocess_response()
メソッドは、すべてのレスポンスで常に呼び出されます。Request
オブジェクトを返す場合、Scrapyはprocess_requestメソッドの呼び出しを停止し、返されたリクエストを再スケジュールします。 新しく返されたリクエストが実行されると、ダウンロードされたレスポンスで適切なミドルウェア・チェーンが呼び出されます。IgnoreRequest
例外が発生した場合、インストールされたダウンローダー・ミドルウェアのprocess_exception()
メソッドが呼び出されます。それらのいずれもが例外を処理しない場合、リクエストのerrback関数(Request.errback
)が呼び出されます。発生した例外を処理するコードがない場合、無視され、(他の例外とは異なり)ログに記録されません。
- process_response(request, response, spider)¶
process_response()
は次のいずれかの結果でなければなりません:Response
オブジェクトを返す、Request
オブジェクトを返す、IgnoreRequest
例外を起こす。Response
が返された場合(指定されたレスポンスと同じか、まったく新しいレスポンスである可能性があります)、そのレスポンスは次のチェーン内のミドルウェアのprocess_response()
で引き続き処理されます。Request
オブジェクトを返す場合、ミドルウェア・チェーンは停止し、返されたリクエストは将来ダウンロードされるように再スケジュールされます。これは、リクエストがprocess_request()
から返される場合と同じ動作です。IgnoreRequest
例外が発生した場合、リクエストのerrback関数(Request.errback
)が呼び出されます。発生した例外を処理するコードがない場合、無視され、(他の例外とは異なり)ログに記録されません。
- process_exception(request, exception, spider)¶
Scrapyは、ダウンロード・ハンドラーまたは、(ダウンローダー・ミドルウェアから)
process_request()
が例外(IgnoreRequest
例外を含む)を発生させると、process_exception()
を呼び出しますprocess_exception()
は、None
またはResponse
オブジェクトまたはRequest
オブジェクトを返す必要があります。None
を返す場合、Scrapyはこの例外の処理を続け、ミドルウェアが無くなりデフォルトの例外処理が開始されるまで、順にインストールされた他のミドルウェアのprocess_exception()
メソッドを実行します。Response
オブジェクトを返す場合、インストールされたミドルウェアのprocess_response()
メソッド・チェーンが開始され、Scrapyは他のミドルウェアのprocess_exception()
メソッドを呼び出すことはありません。Request
オブジェクトを返す場合、返されたリクエストは将来ダウンロードされるように再スケジュールされます。これは、レスポンスを返すのと同様に、ミドルウェアのprocess_exception()
メソッドの実行を停止します。
組み込みダウンローダー・ミドルウェア・リファレンス¶
この文書では、Scrapyに付属するすべてのダウンローダー・ミドルウェア・コンポーネントについて説明します。それらの使用方法と独自のダウンローダ・ミドルウェアの作成方法については、ダウンローダミドルウェア使用ガイド を参照してください。
デフォルトで有効になっているコンポーネント(およびその順序)のリストについては、 DOWNLOADER_MIDDLEWARES_BASE
設定を参照してください。
CookiesMiddleware¶
- class scrapy.downloadermiddlewares.cookies.CookiesMiddleware[ソース]¶
このミドルウェアにより、セッションを使用するサイトなど、クッキーを必要とするサイトを操作できます。Webサーバーが送信したクッキーを追跡し、Webブラウザーが行うように、その後の(スパイダーからの)リクエストでそれらを送り返します。
注意
UTF8でエンコードされていないバイト・シーケンスが
Request
に渡されると、CookiesMiddleware
は警告をログに取ります。 ログ取り動作をカスタマイズするには、 高度なカスタマイズ を参照してください。注意
Cookie
ヘッダーを介して設定されたCookieは、 CookiesMiddleware では考慮されません。リクエストにCookieを設定する必要がある場合は、Request.cookies
パラメータを使用します。これは現在改善に取り組んでいる既知の制限です。
次の設定を使用して、クッキー・ミドルウェアを構成(configure)できます:
スパイダーごとの複数のクッキー・セッション¶
cookiejar
リクエスト・メタ・キーを使用することにより、スパイダーごとに複数のクッキー・セッションの保持をサポートします。デフォルトでは、単一のcookie jar(セッション)を使用しますが、異なるものを使用するために識別子を渡すことができます。
例えば:
for i, url in enumerate(urls):
yield scrapy.Request(url, meta={'cookiejar': i},
callback=self.parse_page)
cookiejar
メタ・キーは "sticky" ではないことに注意してください(訳注:つまりvolatile)。 後続のリクエストでそれを渡し続ける必要があります:
def parse_page(self, response):
# do some processing
return scrapy.Request("http://www.example.com/otherpage",
meta={'cookiejar': response.meta['cookiejar']},
callback=self.parse_other_page)
COOKIES_ENABLED¶
デフォルト: True
クッキー・ミドルウェアを有効にするかどうか。 無効にすると、クッキーはWebサーバーに送信されません。
Request.
meta['dont_merge_cookies']
が True
と評価される場合、 COOKIES_ENABLED
設定にかかわらず、リクエス・トクッキーは Webサーバーに 送信されません 。そして Response
で受信されたクッキーは、既存のクッキーとは マージされません 。
詳細については、 Request
の cookies
パラメーターを参照してください。
COOKIES_DEBUG¶
デフォルト: False
有効にすると、Scrapyはリクエストで送信されたすべてのクッキー( Cookie
ヘッダー)およびレスポンスで受信されたすべてのクッキー( Set-Cookie
ヘッダー)をログに記録します。
COOKIES_DEBUG
が有効になっているログの例を次に示します:
2011-04-06 14:35:10-0300 [scrapy.core.engine] INFO: Spider opened
2011-04-06 14:35:10-0300 [scrapy.downloadermiddlewares.cookies] DEBUG: Sending cookies to: <GET http://www.diningcity.com/netherlands/index.html>
Cookie: clientlanguage_nl=en_EN
2011-04-06 14:35:14-0300 [scrapy.downloadermiddlewares.cookies] DEBUG: Received cookies from: <200 http://www.diningcity.com/netherlands/index.html>
Set-Cookie: JSESSIONID=B~FA4DC0C496C8762AE4F1A620EAB34F38; Path=/
Set-Cookie: ip_isocode=US
Set-Cookie: clientlanguage_nl=en_EN; Expires=Thu, 07-Apr-2011 21:21:34 GMT; Path=/
2011-04-06 14:49:50-0300 [scrapy.core.engine] DEBUG: Crawled (200) <GET http://www.diningcity.com/netherlands/index.html> (referer: None)
[...]
DefaultHeadersMiddleware¶
- class scrapy.downloadermiddlewares.defaultheaders.DefaultHeadersMiddleware[ソース]¶
このミドルウェアは、
DEFAULT_REQUEST_HEADERS
設定で指定されたすべてのデフォルト・リクエスト・ヘッダーを設定します。
DownloadTimeoutMiddleware¶
- class scrapy.downloadermiddlewares.downloadtimeout.DownloadTimeoutMiddleware[ソース]¶
このミドルウェアは、
DOWNLOAD_TIMEOUT
設定またはdownload_timeout
スパイダー属性で指定されたリクエストのダウンロード・タイムアウトを設定します。
注釈
download_timeout
リクエスト・メタ・キーを使用して、リクエストごとにダウンロード・タイムアウトを設定することもできます。これは、DownloadTimeoutMiddlewareが無効になっている場合でもサポートされます。
HttpAuthMiddleware¶
- class scrapy.downloadermiddlewares.httpauth.HttpAuthMiddleware[ソース]¶
このミドルウェアは、 Basic access authentication (別名BASIC認証)を使用して、特定のスパイダーから生成されたすべてのリクエストを認証します。
特定のスパイダーからのBASIC認証を有効にするには、それらのスパイダーの
http_user
とhttp_pass
属性を設定します。例:
from scrapy.spiders import CrawlSpider class SomeIntranetSiteSpider(CrawlSpider): http_user = 'someuser' http_pass = 'somepass' name = 'intranet.example.com' # .. rest of the spider code omitted ...
HttpCacheMiddleware¶
- class scrapy.downloadermiddlewares.httpcache.HttpCacheMiddleware[ソース]¶
このミドルウェアは、すべてのHTTPリクエストおよびレスポンスに低レベルのキャッシュを提供します。 キャッシュ・ストレージ・バックエンドおよびキャッシュ・ポリシーと組み合わせる必要があります。
Scrapyには3つのHTTPキャッシュ・ストレージ・バックエンドが付属しています:
HTTPCACHE_STORAGE
設定でHTTPキャッシュ・ストレージ・バックエンドを変更できます。また、 独自のストレージ・バックエンドの実装 もできます。Scrapyには2つのHTTPキャッシュ・ポリシーが付属しています:
HTTPCACHE_POLICY
設定でHTTPキャッシュ・ポリシーを変更できます。または、独自のポリシーを実装することもできます。dont_cache
メタ・キーがTrue
に等しいことを使用して、すべてのポリシーで応答をキャッシュしないようにすることもできます。
ダミー・ポリシー(デフォルト)¶
RFC2616ポリシー¶
- class scrapy.extensions.httpcache.RFC2616Policy[ソース]¶
このポリシーは、RFC2616準拠のHTTPキャッシュ、つまりHTTP Cache-Control認識を提供します。これは、新たな生成物に狙いを定め、変更されていないデータのダウンロードを回避するために連続実行で使用されます(帯域幅を節約し、クロールを高速化するため)。
実装されているもの:
no-store
キャッシュ制御ディレクティブが設定されている場合、レスポンス/リクエストを保存しようとしないでください。no-cache
キャッシュ制御ディレクティブが新しいレスポンスに対しても設定されている場合、キャッシュからレスポンスを提供しませんmax-age
キャッシュ制御ディレクティブから鮮度寿命を計算しますExpires
レスポンス・ヘッダーから鮮度寿命を計算しますLast-Modified
レスポンス・ヘッダーから鮮度の有効期間を計算します(Firefoxで使用されるヒューリスティック)Age
レスポンス・ヘッダーから現在の年齢を計算するDate
ヘッダーから現在の年齢を計算Last-Modified
レスポンス・ヘッダーに基づいて古いレスポンスを再検証しますETag
レスポンス・ヘッダーに基づいて古いレスポンスを再検証します受信したレスポンスがない場合に
Date
ヘッダーを設定しますリクエストで
max-stale
キャッシュ制御ディレクティブをサポート
これにより、スパイダーを完全なRFC2616キャッシュ・ポリシーで構成できますが、HTTP仕様に準拠したまま、リクエストごとの再検証を回避できます。
例:
Cache-Control: max-stale=600
をリクエスト・ヘッダーに追加して、600秒以内ならば有効期限を超えたレスポンスを受け入れます。RFC2616, 14.9.3 も参照下さい。
実装されてないもの:
Pragma: no-cache
サポート https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1Vary
ヘッダー・サポート https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6更新または削除後の無効化 https://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.10
…その他いろいろ…
ファイルシステム・ストレージ・バックエンド(デフォルト)¶
- class scrapy.extensions.httpcache.FilesystemCacheStorage[ソース]¶
ファイルシステム・ストレージ・バックエンドは、HTTPキャッシュ・ミドルウェアで使用できます。
各リクエスト/レスポンスのペアは、次のファイルを含む異なるディレクトリに保存されます:
request_body
- 生のリクエスト・ボディそのものrequest_headers
- リクエスト・ヘッダ(生HTTP書式)response_body
- 生のレスポンス・ボディそのものresponse_headers
- リクエスト・ヘッダ(生HTTP書式)meta
- Pythonrepr()
形式の、このキャッシュ・リソースのメタ・データ(grepに優しい形式)pickled_meta
- `` meta`` と同じメタデータですが、より効率的な逆シリアル化のために直列化(pickled)されています
ディレクトリ名はリクエストのフィンガー・プリントから作成され(
scrapy.utils.request.fingerprint
参照)、1つのレベルのサブ・ディレクトリを使用して、同じディレクトリに多くのファイルを作成しないようにします(多くのファイルシステムでは非効率的です)。ディレクトリの例以下です:/path/to/cache/dir/example.com/72/72811f648e718090f041317756c03adb0ada46c7
DBMストレージ・バックエンド¶
- class scrapy.extensions.httpcache.DbmCacheStorage[ソース]¶
DBM ストレージ・バックエンドは、HTTPキャッシュ・ミドルウェアでも使用できます。
デフォルトでは
dbm
を使用しますが、HTTPCACHE_DBM_MODULE
設定で変更できます。
あなた自身のストレージ・バックエンドを書く¶
以下に説明するメソッドを定義するPythonクラスを作成することにより、キャッシュス・トレージ・バックエンドを実装できます。
- class scrapy.extensions.httpcache.CacheStorage¶
- open_spider(spider)¶
このメソッドは、クロールのためにスパイダーがオープンされた後に呼び出されます。
open_spider
シグナルを処理します。- パラメータ
spider (
Spider
object) -- オープンされたスパイダー
- close_spider(spider)¶
このメソッドは、スパイダーがクローズさられた後に呼び出されます。
close_spider
シグナルを処理します。- パラメータ
spider (
Spider
object) -- クローズされたスパイダー
- retrieve_response(spider, request)¶
キャッシュに存在する場合はレスポンスを返し、そうでない場合は
None
を返します。
ストレージ・バックエンドを使用するには、以下の設定をします:
HTTPCACHE_STORAGE
をあなたのカスタム・ストレージ・クラスのPythonインポート・パスに設定します。
HTTPCache middleware 設定¶
HttpCacheMiddleware
は次の設定で構成(configure)できます:
HTTPCACHE_EXPIRATION_SECS¶
デフォルト: 0
キャッシュされたリクエストの有効期限(秒単位)。
この時間より古いキャッシュされたリクエストは再ダウンロードされます。ゼロの場合、キャッシュされたリクエストは期限切れになりません。
HTTPCACHE_DIR¶
デフォルト: 'httpcache'
(低レベル)HTTPキャッシュを保存するために使用するディレクトリ。空の場合、HTTPキャッシュは無効になります。相対パスが指定されている場合、プロジェクト・データ・ディレクトリからの相対パスが使用されます。詳細については、 Scrapyプロジェクトのデフォルト構造 を参照してください。
HTTPCACHE_STORAGE¶
デフォルト: 'scrapy.extensions.httpcache.FilesystemCacheStorage'
キャッシュ・ストレージ・バックエンドを実装するクラス。
HTTPCACHE_ALWAYS_STORE¶
デフォルト: False
有効にすると、ページを無条件にキャッシュします。
スパイダーは、たとえば Cache-Control:max-stale
で将来使用するために、すべてのレスポンスをキャッシュで利用可能にしたい場合があります。 DummyPolicyはすべてのレスポンスをキャッシュしますが、それらを再検証することはありません。また、より微妙なポリシーが望ましい場合があります。
この設定は、レスポンスの Cache-Control:no-store
ディレクティブを引き続き尊重します。不要な場合は、キャッシュ・ミドルウェアにフィードするレスポンスのCache-Controlヘッダーから no-store
をフィルターします。
HTTPCACHE_IGNORE_RESPONSE_CACHE_CONTROLS¶
デフォルト: []
無視されるレスポンスのキャッシュ制御ディレクティブのリスト。
サイトは "no-store"、"no-cache"、"must-revalidate"などを設定することがよくありますが、これらのディレクティブを尊重するとスパイダーが生成できる取引(traffic)をろうばいさせます。この設定により、クロールされるサイトにとって重要ではないことがわかっているCache-Controlディレクティブを選択的に無視できます。
スパイダーは、実際に必要な場合を除き、リクエストでCache-Controlディレクティブを発行しないため、リクエストのディレクティブはフィルタリングされません。
HttpCompressionMiddleware¶
- class scrapy.downloadermiddlewares.httpcompression.HttpCompressionMiddleware[ソース]¶
このミドルウェアにより、圧縮(gzip、deflate)取引(traffic)をWebサイトから送受信できます。
このミドルウェアは、 brotlipy または zstandard がインストールされている場合、それぞれに、 brotli-compressed と共に zstd-compressed レスポンスのデコードもサポートします。
HttpProxyMiddleware¶
- class scrapy.downloadermiddlewares.httpproxy.HttpProxyMiddleware[ソース]¶
このミドルウェアは、
Request
オブジェクトにproxy
メタ値を設定することにより、リクエストに使用するHTTPプロキシを設定します。Python標準ライブラリモジュール
urllib.request
と同様に、以下の環境変数に従います:http_proxy
https_proxy
no_proxy
リクエストごとにメタ・キー
proxy
をhttp://some_proxy_server:port
またはhttp://username:password@some_proxy_server:port
のような値に設定することもできます。この値はhttp_proxy
/https_proxy
環境変数よりも優先され、またno_proxy
環境変数も無視することに注意してください。
RedirectMiddleware¶
- class scrapy.downloadermiddlewares.redirect.RedirectMiddleware[ソース]¶
このミドルウェアは、レスポンス・ステータスに基づいてリクエストのリダイレクトを処理します。
(リダイレクト中に)リクエストが通過するURLは Request.meta
の redirect_urls
キーで見つけることができます。
redirect_urls
の各リダイレクトの理由は、 Request.meta
の redirect_reasons
キーにあります。例: [301, 302, 307, 'meta refresh']
理由の形式は、対応するリダイレクトを処理したミドルウェアによって異なります。 たとえば、 RedirectMiddleware
はトリガーとなったレスポンス・ステータ・スコードを整数で示しますが、 MetaRefreshMiddleware
は常に 'meta refresh'
文字列を理由として使用します。
RedirectMiddleware
は次の設定で設定できます(詳細については設定ドキュメントを参照してください):
Request.meta
の dont_redirect
キーがTrueに設定されている場合、リクエストはこのミドルウェアによって無視されます。
スパイダーでいくつかのリダイレクト・ステータス・コードを処理したい場合、これらを handle_httpstatus_list
スパイダー属性で指定できます。
たとえば、リダイレクト・ミドルウェアで、301と302レスポンスを無視する(およびそれらをスパイダーに渡す)場合は、以下のようにします:
class MySpider(CrawlSpider):
handle_httpstatus_list = [301, 302]
Request.meta
の handle_httpstatus_list
キーは、リクエストごとに許可するレスポンス・コードを指定するためにも使用できます。リクエストに対するレスポンス・コードを許可したい場合、メタ・キー handle_httpstatus_all
を True
に設定することもできます。
MetaRefreshMiddleware¶
- class scrapy.downloadermiddlewares.redirect.MetaRefreshMiddleware[ソース]¶
このミドルウェアは、メタ・リフレッシュhtmlタグに基づいてリクエストのリダイレクトを処理します。
MetaRefreshMiddleware
は次の設定で設定できます(詳細については設定ドキュメントを参照してください):
このミドルウェアは、 RedirectMiddleware
で説明されているように、 :REDIRECT_MAX_TIMES
設定と dont_redirect
リクエスト・メタ・キーと redirect_urls
リクエスト・メタ・キーと redirect_reasons
リクエスト・メタ・キーに従います。
MetaRefreshMiddleware 設定¶
METAREFRESH_IGNORE_TAGS¶
デフォルト: []
これらのタグ内のメタ・タグは無視されます。
バージョン 2.0 で変更: METAREFRESH_IGNORE_TAGS
のデフォルト値は ['script', 'noscript']
kから []
に変更されました。
METAREFRESH_MAXDELAY¶
デフォルト: 100
リダイレクト後の最大メタリフレッシュ遅延(秒単位)。一部のサイトでは、セッションの期限切れページへのリダイレクトにメタ・リフレッシュを使用しているため、自動リダイレクトを最大遅延に制限しています。
RetryMiddleware¶
- class scrapy.downloadermiddlewares.retry.RetryMiddleware[ソース]¶
接続タイムアウトやHTTP 500エラーなどの一時的な問題が原因である可能性のある失敗した要求を再試行するミドルウェア。
スパイダーがすべての通常の(失敗していない)ページのクロールを完了すると、失敗したページはスクレイピング・プロセスで収集され、最後に再スケジュールされます。
RetryMiddleware
は次の設定で設定できます(詳細については設定ドキュメントを参照):
Request.meta
の dont_retry
キーがTrueに設定されている場合、リクエストはこのミドルウェアによって無視されます。
スパイダー・コールバックからのリクエストを再試行するには、 get_retry_request()
関数を使用できます:
- scrapy.downloadermiddlewares.retry.get_retry_request(request: scrapy.http.request.Request, *, spider: scrapy.spiders.Spider, reason: Union[str, Exception] = 'unspecified', max_retry_times: Optional[int] = None, priority_adjust: Optional[int] = None, logger: logging.Logger = <Logger scrapy.downloadermiddlewares.retry (WARNING)>, stats_base_key: str = 'retry')[ソース]¶
新しい
Request
オブジェクトを返し、指定されたリクエストを再試行します。指定されたリクエストの再試行をやり尽くした場合はNone
を返します。たとえば、
Spider
コールバックは以下のように使用できます:def parse(self, response): if not response.text: new_request_or_none = get_retry_request( response.request, spider=self, reason='empty', ) return new_request_or_none
spider は、再試行リクエストを求めている
Spider
インスタンスです。 これは、 settings や stats にアクセスし、追加のロギング・コンテキストを提供するために使用されます(logging.debug()
を参照)。reason は、リクエストを再試行する必要がある理由を示す文字列または
Exception
オブジェクトです。再試行統計(訳注:retry stats)に名前を付けるために使用されます。max_retry_times は、 request を再試行できる最大回数を決定する数値です。 指定されていない場合または
None
の場合、数値はリクエストのmax_retry_times
メタ・キーから読み取られます。max_retry_times
メタ・キーが定義されていないかNone
の場合、数値はRETRY_TIMES
設定から読み取られます。priority_adjust は、 request に関連して新しいリクエストの優先度がどのように変化するかを決定する数値です。 指定しない場合、数値は
RETRY_PRIORITY_ADJUST
設定から読み取られます。logger は、メッセージをログに記録するときに使用されるlogging.Logger オブジェクトです
stats_base_key は、再試行関連のジョブ統計のベース・キーとして使用される文字列です
RetryMiddleware 設定¶
RETRY_TIMES¶
デフォルト: 2
(最初のダウンロードに加えて)再試行する最大回数。
再試行の最大回数は、 Request.meta
の max_retry_times
属性を使用してリクエストごとに指定することもできます。初期化されると、 max_retry_times
メタ・キーは RETRY_TIMES
設定よりも優先されます。
RETRY_HTTP_CODES¶
デフォルト: [500, 502, 503, 504, 522, 524, 408, 429]
再試行するHTTPレスポンス・コード。その他のエラー(DNSルックアップの問題、接続の切断など)は常に再試行されます。
場合によっては、400を RETRY_HTTP_CODES
に追加することもできます。これは、サーバーの過負荷を示すために使用される一般的なコードだからです。HTTPの仕様ではそうなっているため、デフォルトでは含まれていません。
RETRY_PRIORITY_ADJUST¶
デフォルト: -1
元のリクエストに対して再試行リクエストの優先度を調整します:
正の優先度調整は、より高い優先度を意味します。
負の優先度調整(デフォルト)は、優先度が低いことを意味します。
RobotsTxtMiddleware¶
- class scrapy.downloadermiddlewares.robotstxt.RobotsTxtMiddleware[ソース]¶
このミドルウェアは、robots.txt除外標準で禁止されているリクエストを除外します。
Scrapyがrobots.txtを尊重するようにするには、ミドルウェアが有効になっており、かつ、
ROBOTSTXT_OBEY
設定が有効になっていることを確認してください。ROBOTSTXT_USER_AGENT
設定を使用して、robots.txt ファイルでの照合に使用するユーザー・エージェント文字列を指定できます。None
の場合、リクエストで送信しているUser-AgentヘッダーまたはUSER_AGENT
設定(この順序で)は、robots.txt ファイルで使用するユーザー・エージェントを決定するために使用されます。このミドルウェアは robots.txt パーサと組み合わせる必要があります。
Scrapyには、次の robots.txt パーサがサポートされています:
robots.txt パーサは、
ROBOTSTXT_PARSER
設定で変更できます。または、 新しいパーサ のサポートを実装することもできます。
Request.meta
の dont_obey_robotstxt
キーがTrueに設定されている場合、 ROBOTSTXT_OBEY
が有効になっていても、このミドルウェアは要求を無視します。
パーサはいくつかの側面で異なります:
実装言語
サポートされている仕様
ワイルドカードマッチングのサポート
長さベースのルール( length based rule )の使い方: 特に
Allow
とDisallow
ディレクティブは、パスの長さに基づく最も具体的なルールが、より具体的でない(短い)ルールよりも優先されます
さまざまなパーサの性能比較については the following link で入手できます。
Protegoパーサ¶
Protego に基づく:
Pythonによる実装
GoogleのRobots.txt仕様( Google's Robots.txt Specification )に準拠しています。
ワイルドカード・マッチングのサポート
長さベースのルールの使用
Scrapyはデフォルトでこのパーサを使います
RobotFileParser¶
RobotFileParser
に基づく:
Python組み込みの robots.txt パーサです
Martijn Kosterの1996年のドラフト仕様 に準拠しています
ワイルドカードマッチングのサポートはありません
長さベースのルールを使用しません
Protegoよりも高速で、1.8.0より前のバージョンのScrapyと下位互換性があります。
このパーサーを使用するには、以下を設定します:
ROBOTSTXT_PARSER
設定にscrapy.robotstxt.PythonRobotParser
をセット
Reppyパーサ¶
Reppy に基づいています:
Robots Exclusion Protocol Parser for C++ (ロボット除外プロトコル・パーサ)のPythonラッパーです。
Martijn Kosterの1996年のドラフト仕様 に準拠しています
ワイルドカード・マッチングのサポート
長さベースのルールの使用
ネイティブ実装で、Protegoよりも高速です。
このパーサーを使用するには:
pip install reppy
を実行して Reppy をインストールしますROBOTSTXT_PARSER
設定にscrapy.robotstxt.ReppyRobotParser
をセットします
Robotexclusionrulesparser¶
Robotexclusionrulesparser に基づいています:
Pythonによる実装
Martijn Kosterの1996年のドラフト仕様 に準拠しています
ワイルドカード・マッチングのサポート
長さベースのルールを使用しません
このパーサーを使用するには:
pip install robotexclusionrulesparser
を実行して、 Robotexclusionrulesparser をインストールしますROBOTSTXT_PARSER
設定にscrapy.robotstxt.RerpRobotParser
をセットします
新しいパーサのサポートの実装¶
抽象基本クラス RobotParser
をサブクラス化し、以下に説明するメソッドを実装することにより、新しい robots.txt パーサーのサポートを実装できます。
- class scrapy.robotstxt.RobotParser[ソース]¶
- abstract allowed(url, user_agent)[ソース]¶
user_agent
がurl
をクロールできる場合はTrue``を返し、そうでない場合は ``False
を返します。
- abstract classmethod from_crawler(crawler, robotstxt_body)[ソース]¶
robots.txt ファイルのコンテンツをbyte型データとして解析します。 これはクラス・メソッドである必要があります。パーサ・バックエンドの新しいインスタンスを返す必要があります。
- パラメータ
crawler (
Crawler
instance) -- リクエストを行ったクローラーrobotstxt_body (bytes) -- robots.txt ファイルの内容。
DownloaderStats¶
- class scrapy.downloadermiddlewares.stats.DownloaderStats[ソース]¶
通過するすべてのリクエストとレスポンスと例外の統計を保存するミドルウェア。
このミドルウェアを使用するには、
DOWNLOADER_STATS
設定を有効にする必要があります。
UserAgentMiddleware¶
AjaxCrawlMiddleware¶
- class scrapy.downloadermiddlewares.ajaxcrawl.AjaxCrawlMiddleware[ソース]¶
メタ・フラグメントHTMLタグに基づいて「AJAXクロール可能な」ページ・バリアントを検出するミドルウェア。 詳細については、 https://developers.google.com/search/docs/ajax-crawling/docs/getting-started をご覧ください。
注釈
Scrapyは、このミドルウェアがなくても、「 'http://example.com/!#foo=bar'」などのURLの「AJAXクロール可能な」ページを検出します。AjaxCrawlMiddlewareは、URLに
'!#'
が含まれていない場合に必要です。これは多くの場合、 'index' または 'main' のWebサイトページの場合です。