スクレイピング時のページネーションの処理方法
Scrapeless Agent Browser は、ページネーションされたページをナビゲートし、JavaScript 駆動の結果リストと対話できるクラウドブラウザセッションを提供します。
スクレイピング時にページネーションをどのように処理すべきか?
ページネーションは、ソースの継続メカニズムを特定し、安定した ID を持つレコードを抽出し、現在の結果が受理されてからのみ前進し、文書化されたまたは観測された終了状態で停止することで処理します。継続が壊れていても無制限クロールが起きないよう、処理全体に独立した上限を設けます。
難しいのは進捗を証明することです。ページラベルが変わってもレコードが同じままのことがあります。インフィニットスクロールリストは、伸長するのではなく古いノードを置き換えることがあります。成功レスポンスにアクセスメッセージが含まれる場合もあります。正しいコレクターは、クリックやリクエストを新しい受理ページとみなすのではなく、意味のあるコンテンツや状態を検査します。
要約
- 観測された継続動作に従う。 ページ URL を構築する前に、次リンクやリクエスト状態を発見する。
- 進捗測定にはレコードの ID を使う。 要素数やスクロール高さは補助的なシグナルにとどめる。
- ソースの終了と実行上限を区別する。 ページ上限は、完了の証明ではなく、上限付きコレクションを生むだけである。
- ソースの許可とワークロード上限を明示的に保つ。 ブラウザアクセスは収集の認可範囲を拡大しない。
ソースはどのページネーションパターンを使っているか?
ソースの実際の状態遷移がページネーションパターンを決めます。承認されたページを確認し、ユーザーが前進したときに何が起こるかを観察します。次リンクは新しいドキュメントへナビゲートすることがあります。番号付きコントロールはクエリパラメータを変更することがあります。「さらに読み込む」ボタンはレコードを追加することがあります。スクロールのセントネルが、可視ボタンなしに別のリクエストをトリガーすることもあります。
アクセスが許可され、その意味が理解できる場合は、構造化レスポンスを確認します。ブラウザインターフェースはページ番号を表示していても、基盤となるリクエストは不透明なカーソルを使っているかもしれません。サポートされているインターフェースと許可境界を使用してください。発見可能なエンドポイントだからといって、自動的に公開コレクション API になるわけではありません。
| パターン | 前進アクション | 進捗の証拠 | 終了の可能な証拠 |
|---|---|---|---|
| 次リンク | 現在の次のターゲットをたどる | 新しいレコードまたは継続状態が期待どおり存在すること | 有効な次ターゲットが存在しないことの確認 |
| 番号付きページ | 観測されたサポート済みページナビゲーションを使う | 安定したレコードキーを保ったままウィンドウが変化すること | ソースが定義した最終ページ |
| Load more | 有効なコントロールを起動する | 新たに受理された ID | 明示的な枯渇状態 |
| インフィニットスクロール | 該当するコンテナまたはセントネルを動かす | 新しい ID またはリクエスト継続 | ソースによる終了シグナルが確認できること |
次リンクはどうすれば安全にたどれるか?
次リンク型コレクターは、現在ページの継続ターゲットを読み取り、ページ URL に対して相対参照を解決し、フォローする前に遷移先を検証します。 HTML のリンク関係モデル には next 関係が含まれますが、サイトは独自のマークアップを通じてページネーションを表現することもあります。
そのシグナルが意図されたコントロールを識別している場合は、生成されたクラス名よりもセマンティックな属性や安定したページ構造を優先します。ターゲットが関連カテゴリや広告ではなく、同じコレクションを前進させることを確認します。選択したフィルタと並び順のコンテキストを保ったままにします。
訪問済みのページ状態を追跡してループを検出します。繰り返し現れる URL は、次リンクの循環を示すことがありますが、一つの URL で多くの状態を扱うアプリケーションも存在します。そのような場合は、関連するカーソル、ソースページ状態、または受理されたレコードキーのフィンガープリントを記録します。URL のみを用いたガードでは、正当なステートフルリストを誤って停止させてしまいます。
資格情報を送信する前に遷移先オリジンを検証します。スクレイピングしたリンクは信用できない入力です。ページがそのリンクを「next」と呼んでいるからといって、コレクターが認可ヘッダーやセッション情報を無関係なホストに転送してはなりません。
番号付きページ URL はいつ使えるか?
番号付きページ URL は、ソースがその URL パターンを公開し、サポートしている場合に使用します。範囲を構築する前に、最初の遷移と最終ページシグナルを確認します。すべてのコレクションが page クエリパラメータを使っている、または表示されているページ番号が単純な算術オフセットに対応している、とは決めつけないでください。
変化するコレクションは、番号付きウォークを複雑にします。挿入や削除によって結果ウィンドウがずれ、重複や欠落が発生する可能性があります。安定した ID により重複出力は除外できますが、ウィンドウ間でスキップされたレコードを回復することはできません。インターフェースが許すならソースのソート順を固定し、コレクションの観測範囲を報告してください。
The 制限されたクエリで一意の順序付けが必要になることは 根本的な問題を示しています。人気順のような可視のソート順は、収集を進めている間に変化し得ます。時系列ソートであっても、同じ時刻を持つレコードに対しては同点解消ポリシーが必要です。
ロードモアリストとインフィニットスクロールリストはどう違うのか?
ロードモアリストは明示的なアクションを表に出しますが、インフィニットスクロールリストは関連するビューポート条件が満たされたときに読み込みをトリガーします。どちらも、アクションの後にはソース固有の進行を待つ必要があります。クリックが完了したことやスクロールイベントが発火したこと自体は、追加のレコードが到着したことを確立するものではありません。
The Intersection Observer メカニズム は、可視性の変化がどのように非同期処理をトリガーし得るかを説明します。一部のサイトは、ドキュメントビューポートではなく、入れ子になったスクロールコンテナ内部のセントネルを監視しています。ドキュメントをスクロールしても、そのセントネルには影響しない場合があります。
仮想化リストは、表示ウィンドウが移動するにつれて DOM 要素を再利用できます。要素数やページ高さは、新しいレコードが可視になっても安定したままの場合があります。各ウィンドウが観測されるたびに安定したキーを収集し、その実装に合った終了シグナルや継続状態を使用してください。
無効化されたボタンも、読み込み中にはあいまいです。一時的な読み込み状態と、ソースによって定義された枯渇状態を区別してください。実行に許された観測ウィンドウの中で進行状況を確立できない場合、ソースが終了したと主張するのではなく、未解決の結果として停止します。
境界付きネクストリンク例とはどのようなものか?
境界付きの例は、完全な収集を主張することなくトラバーサルを示せます。次の Python プログラムはパブリックな Books to Scrape demonstration catalogを利用し、観測された next リンクをたどり、期待されるホストを検証し、最大 2 ページまでしか受け入れません。Python 標準ライブラリを使用し、Scrapeless は呼び出しません。
このコードは本記事の例として実行されました。この特定のデモ用マークアップにおいて、タイトルを持つアンカーから書籍詳細リンクを発見しますが、そのセレクタ規則は汎用的なカタログパーサではありません。以下の出力はその取得結果であり、ページ上限ステータスはあえて部分的なトラバーサルであることを示しています。
from html.parser import HTMLParser
from urllib.parse import urljoin, urlparse
from urllib.request import Request, urlopen
class CatalogPage(HTMLParser):
def __init__(self):
super().__init__()
self.in_next = False
self.next_url = None
self.records = []
def handle_starttag(self, tag, attrs):
attrs = dict(attrs)
if tag == 'li' and 'next' in attrs.get('class', '').split():
self.in_next = True
if tag == 'a' and self.in_next:
self.next_url = attrs.get('href')
if tag == 'a' and 'title' in attrs:
self.records.append((attrs.get('href'), attrs['title']))
def handle_endtag(self, tag):
if tag == 'li':
self.in_next = False
url = 'https://books.toscrape.com/catalogue/page-1.html'
seen_pages, seen_items = set(), set()
reason = 'page cap'
for _ in range(2):
if urlparse(url).hostname != 'books.toscrape.com':
raise ValueError('Unexpected continuation host')
if url in seen_pages:
raise ValueError('Repeated page URL')
seen_pages.add(url)
with urlopen(Request(url, headers={'User-Agent': 'Mozilla/5.0'}),
timeout=20) as response:
if response.geturl() != url:
raise ValueError('Unexpected redirect')
document = response.read().decode('utf-8')
parser = CatalogPage()
parser.feed(document)
if not parser.records:
raise ValueError('Expected book records are absent')
for href, title in parser.records:
seen_items.add(urljoin(url, href))
print('Accepted page:', url, 'records:', len(parser.records))
if not parser.next_url:
reason = 'source end'
break
url = urljoin(url, parser.next_url)
print('Unique books:', len(seen_items), '| Stop:', reason)
取得された出力:
Accepted page: https://books.toscrape.com/catalogue/page-1.html records: 20
Accepted page: https://books.toscrape.com/catalogue/page-2.html records: 20
Unique books: 40 | Stop: page cap
プログラムは、進む前に現在のページを受け入れ、ページ URL の繰り返しを検出し、一意のアイテム URL を保存します。本番ワークフローでは、インメモリのセットを、キーと進行境界がその出力契約に一致する宛先に置き換えるべきです。また、ソース固有の証拠を用いて、ソースが空である場合と抽出失敗の場合とを区別すべきです。
どこでブラウザが必要になるのか?
ページネーションに JavaScript 実行、インタラクティブなコントロール、または認可されたセッション状態が必要な場合、ブラウザは有用です。 Scrapeless Agent Browser は、その制御されたブラウザ環境を提供します。 Agent Browser connection configuration はそのセットアップを説明しており、コレクター側でセレクタ、進行確認、ストレージを定義します。
The Scrapeless pagination walkthrough は一般的なページ制御の形状を網羅しています。これらの形状を探索カテゴリとして用い、そのうえで現在のターゲットを検証してください。スクロール高さのヒューリスティックは、通常の伸長していくドキュメントにおいて有用な証拠になり得ますが、普遍的な終了条件として扱うべきではありません。
ブラウザはアクセス制限を取り除いたり、収集を完全なものにしたりはしません。ページがアクセスチャレンジや権限エラーを示している場合、そのコンテンツをレコードとして受け入れるのをやめ、アクセス結果を記録してください。ソースが要求する場所では、ページチェーン全体で認可されたセッション状態を一貫させておきます。
完了をどう記録し、どのように責任ある運用を行うべきか?
実行が終了した理由、収集コンテキスト、受け入れたレコードの境界を記録してください。ソース枯渇、ページ上限、レコード上限、経過時間上限、未解決の進行は、それぞれ異なる状態です。中断によってウィンドウが暗黙のうちに飛ばされないように、永続的なチェックポイントを進める前に、受け入れた出力を永続化してください。
クロールを実行する前に、ソースの利用規約と適用される収集ルールを確認してください。 Robots Exclusion Protocol はクローラー向けの指示を記述しており、それらをアクセス認可とはっきり区別しています。robots ルールを尊重することはソース取り扱いの一部ですが、それだけでデータの収集や再利用の許可が確定するわけではありません。
ソースごとのワークロードは控えめにし、ソースポリシーによって制限された範囲内に保ってください。ウィンドウ同士が独立しており、かつワークロードが許可されている場合にのみ並列化は適切です。カーソルチェーンは通常、逐次的な探索を必要とします。意図された許容量を回避するために、制限された 1 つのワークロードを複数の身元に分散させてはなりません。
Use Scrapeless pricing を使ってブラウザ収集コストを計画し、そのうえで、受け入れた一意レコードと未解決パーティションを監視してください。ページ数が多いことは、その追加ページがレコードを繰り返したり無関係なコンテンツを含んでいたりする場合、より良いデータセットの証拠にはなりません。
結論
観測されたソースの挙動からページネーションの分岐を選択し、安定した識別子で進行を検証し、明示的な終了理由を保持してください。コレクターは、どのページや状態を受け入れたのか、そしてその結果の範囲を完全または部分的とみなす理由を説明できるべきです。
コレクションレイヤーを実践に移す
ソースに合致する Scrapeless の収集機能を選び、そのうえで上記の検証および運用上の判断を適用してください。
今日登録して入手 $5 in free credit — クレジットカード不要.
$5のクレジットを受け取る →FAQ
公開されたページネーションデータの収集は常に許可されていますか?
いいえ。公開されているという事実だけでは、許可、利用規約、プライバシー上の義務、または再利用の権利は確定しません。収集を行う前に、許可された取得元と目的を明確に定義してください。
ページネーションのワークフローには常にプロキシが必要ですか?
いいえ。必要性は取得元と承認されたデプロイ方法によって異なります。プロキシによってアクセス許可が拡張されたり、取得元の負荷ポリシーを尊重する必要性がなくなったりすることはありません。
レコードの代わりにアクセスページが表示された場合はどうなりますか?
影響を受けた状態をアクセス結果としてマークし、データセット内容として受け入れることを中止してください。収集作業を続ける前に、認可されたセッションと取得元ポリシーを確認してください。
サイトのマークアップが変更された場合はどうなりますか?
現在のレコード構造と継続構造を再確認し、その取得元固有のセレクタと受け入れ条件を更新してください。セレクタがアイテムを1つも返さないことは、その取得元が空であることの証明にはなりません。
ページネーションはAIエージェントなしで実行できますか?
はい。制限付きのPythonサンプルはAIエージェントなしで直接実行できます。ブラウザ依存のワークフローも、明示的な状態管理と進捗チェックを備えた通常の自動化コードで実行できます。
ページチェーンは同時に実行できますか?
許可された取得元の負荷範囲内で、独立してアクセス可能なウィンドウだけを並行収集の対象とすべきです。次トークン方式のチェーンは通常、直前のレスポンスに依存します。