HTMLパースとは何ですか？

Scrapeless Universal Scraping APIは、下流のパーサーがクエリ可能なドキュメントツリーに変換できる公開ページのHTMLを取得してレンダリングします。

HTMLパースは、HTMLソースを読み取り、構造化されたドキュメントツリーを構築するプロセスです。その結果は、要素ノード、テキストノード、属性、コメント、親子関係および兄弟関係を含むドキュメントオブジェクトモデル、またはDOMです。

その WHATWG HTML標準 は、text/htmlリソースのトークン化およびツリー構築の動作を定義します。これらのルールは、ソースマークアップと結果のDOMがどのように関連しているか、しかし常に同一ではない理由を説明します。

HTMLパースはどのように機能しますか？

HTMLパースはマークアップをトークン化し、DOMを作成するためにツリー構築ルールを適用します。

1. 文字を読み取ります。 パーサーはHTML入力をストリームとして消費します。
2. トークンを作成します。 開始タグ、終了タグ、テキスト、コメント、および文書型宣言はトークンになります。
3. ツリーを構築します。 挿入モードとオープン要素ルールが各トークンの配置を決定します。
4. 回復可能なマークアップを正しくします。 パーサーは要素を暗示したり、オープン要素を閉じたり、標準に従ってノードを移動したりします。
5. DOMを公開します。 コードは結果のノードをトラバースしたり、サポートされているセレクタAPIを使用してクエリしたりできます。

HTMLパースとレンダリング

パースはドキュメントツリーを作成し、レンダリングはレイアウトを計算し、視覚ページを描画します。

MDNのブラウザパイプラインガイド トークン化、ツリー構築、およびパースとブロッキングスクリプト間の相互作用について説明します。

インメモリ文字列の場合、 DOMParser.parseFromString() HTMLまたはXMLソースをドキュメントに変換するためのブラウザAPIの形状を示します。

HTMLパースがウェブスクレイピングにとって重要な理由は？

HTMLパースは、プレーンテキストとして生のマークアップを検索するよりも安全で正確な構造モデルをスクレイパーに提供します。

一般的なHTMLパースの間違い

ほとんどのパースの失敗は、間違った入力を使用したり、XMLルールを仮定したり、脆弱なレイアウトの詳細に抽出を結びつけたりすることから生じます。

• データが後で表示されるときに初期レスポンスをパースする。 JavaScriptがコンテンツを生成する際にレンダリングされたDOMまたは構造化されたネットワークレスポンスを検査します。
• HTMLを正しく形成されたXMLとして扱う。 HTMLには異なる修正ルールがあるため、text/html用のHTMLパーサーを使用してください。
• 広範な正規表現でマークアップを検索する。 ツリーをパースし、その後構造と安定した属性によってノードを選択します。
• すべてのページにすべてのモジュールがあると仮定する。 オプションの要素をnullableとしてモデル化し、抽出の前にページタイプを検証します。

トークン化中に何が起こるのか？

トークン化は入力文字ストリームを読み取り、スタートタグ、エンドタグ、文字データ、コメント、ドキュメントタイプなどの構造を認識します。トークナイザーは状態を保持し、同じ文字が通常のテキスト、属性値、コメント、生テキスト要素、またはスクリプトデータで異なる意味を持つ可能性があるからです。

文字参照はHTMLルールに従って解決され、属性はタグトークンに添付され、パースエラーはドキュメントを停止することなく処理されます。この動作は、HTMLパーサーが単純な文字列分割よりも好まれる理由の一つです。スクリプト内の小なり記号やテキスト内のアンパサンドは、文脈なしでは正しく解釈できません。

トークン化自体は最終的な要素階層を生成しません。トークンはツリー構築段階に供給され、ノードの所属や、形式が誤っているか省略されたマークアップがドキュメント構造にどのように影響するかを決定します。

ツリー構築はHTMLをどのように修正するのか？

ツリー構築は挿入モードとオープンエレメントのスタックを使用してDOMを作成します。アルゴリズムは、欠落している要素を暗示し、新しいトークンが前のネストを無効にするときに要素を閉じ、テーブルなどの特殊な文脈を処理できます。その結果、DOMにはソーステキストで明示的に書かれていなかったノードまたは関係を含めることができます。

テーブルマークアップは一般的な例です。無効な場所に配置されたコンテンツは、パースルールに従って移動できます。段落要素も、特定のブロックレベル要素が開始するときに暗黙的に閉じることがあります。抽出ロジックは、インデントからネストを推測するのではなく、パースされたツリーを検査するべきです。

異なるパーサーライブラリはHTML標準を実装することを目指していますが、異なるAPIや準拠レベルを公開する可能性があります。正確なツリー形状がパイプラインにとって重要な場合は、代表的な形式が不正なページを持つ実際のライブラリをテストしてください。

エンコーディングとコンテンツタイプはパースにどのように影響するのか？

パーサーはレスポンスバイトを文字に変換するために正しい文字エンコーディングが必要です。間違ったエンコーディングは、ツリー構築が始まる前に名前、価格、句読点、およびセレクタ関連の属性値を破損させる可能性があります。信頼できるレスポンスメタデータとパーサーの文書化されたエンコーディング検出動作を尊重してください。

コンテンツタイプも重要です。HTMLとXMLは異なるパースルールとエラーハンドリングを持っています。XMLは一般に、正しく形成された入力と名前空間を考慮した処理を要求しますが、HTMLは一般的なマークアップエラーに対して回復動作を定義します。text/htmlをXMLパーサーに供給すると、ブラウザが表示するページを拒否することがありますが、XMLをHTMLパーサーに供給すると名前空間や大文字小文字の意味が失われる可能性があります。

最終レスポンスのコンテンツタイプとURLをキャプチャとともに記録します。名義ページのURLは、リクエストコンテキストに基づいてJSON、ダウンロード、アクセスページ、または他の形式を返す可能性があります。サービスが実際に返したものを確認した後で、パーサーを選択してください。

スクリプトはパーサーとどのように相互作用するか？

ブラウザ内では、特定のスクリプト要素は、コードが取得されて実行されている間、HTMLパースを一時停止できる場合があります。そのコードは部分的に構築されたDOMを検査したり、追加のマークアップを書いたり、後の変更をスケジュールしたりできます。他のスクリプトはブロッキングなしで読み込むことができ、初期のパースが完了した後にページを更新することがあります。

スタンドアロンパーサーは、初期ツリーを構築するだけではアプリケーションライフサイクルを再現しません。必要なデータがスクリプトによって挿入される場合、抽出ワークフローはブラウザまたは同じ情報を含む構造化されたレスポンスを必要とします。正しい入力はレンダリングされたDOMかもしれませんが、レンダリング中に観察されたAPIレスポンスでもあるかもしれません。

対象コンテンツに結びついた完了条件を選択します。ドキュメントの読み込みは、クライアントアプリケーションがデータ要求を完了する前に発生することがありますが、継続的な分析トラフィックはネットワークアイドル条件を不適切にする可能性があります。必要なモジュールに関連する要素、レスポンス、またはアプリケーション状態は、より意味のあるものです。

HTMLパーサーを抽出のためにどのようにテストするか？

パーサーテストには、正しいマークアップ、省略されたタグ、無効なネスト、エンティティ、コメント、テーブル、スクリプト、非ASCIIテキスト、および空のドキュメントが含まれるべきです。結果のツリーを、例外なしにパースが戻るかどうかのみをテストするのではなく、抽出ルールによって要求される動作と比較してください。

抽出テストは解析されたツリーに対して動作し、レコードの境界、フィールドテキスト、属性、およびオプションのモジュールを検証する必要があります。ソースとDOMが異なるページを含めて、チームがルールがサーバーHTMLを期待しているのか、レンダリングされたHTMLを期待しているのかを把握できるようにします。

パーサまたはライブラリのバージョンが変更された場合は、代表的なコーパスを再実行してください。ツリーの修正、テキストの正規化、またはセレクタのサポートの小さな違いが抽出されたレコードを変更する可能性があります。変更のソースが追跡可能であるように、パースと抽出スタックをスキーマと共にバージョン管理してください。

結論

HTMLパースはマークアップをブラウザと抽出ツールがクエリできるDOMに変換します。信頼できる抽出は、正しい入力—ソースHTMLまたはレンダリングされたHTML—を選択し、その後、構造的セレクタとスキーマ検証を結果のツリーに使用することから始まります。