XPathとは何ですか？

XPathが見るドキュメントツリー

XPathは文書のツリー表現を評価します。 XPath言語仕様 データモデルのためのロケーションパス、式、および関数を定義します。パーサーまたはブラウザが、式が実行されるツリーを提供します。

ソースマークアップと解析されたツリーの違いは重要です。ブラウザは不正なHTMLを修復でき、ページスクリプトは要素を追加できます。HTTPパーサーは初期のレスポンスを見るかもしれませんが、ブラウザ評価者は現在のドキュメントを見ることができます。したがって、同じ式は異なる入力を持つことができ、式が間違っているわけではありません。

実際の抽出環境で使用されるツリーを検査します。必要な要素が存在すること、そしてメインレコードがナビゲーションや推奨事項と区別できることを確認します。もし式が何も返さない場合は、入力に期待される内容が含まれているかどうかを尋ねることから始めてください。

XPathはそのツリーにコンテンツをロードしません。もし商品価格がJavaScriptの実行後にのみ到着する場合、初期のマークアップを選択してもそれを作成することはできません。適切なドキュメントを提供する責任があるのは取得またはレンダリングの段階です。

パスステップ、軸、および述語

XPathパスはステップを通じてノードを特定し、述語は選択を絞ります。お馴染みのスラッシュ表記は関係を説明しますが、文脈とグルーピングが正確な結果を決定します。

絶対パスはドキュメントルートから始まります。相対パスは提供されたコンテキストノードから始まります。たとえば、 .//a 現在のコンテキストにおける子孫アンカー要素を典型的なHTMLツリーの下で説明します。これは構造的な例であり、特定の本番ウェブサイトに対して検証されたセレクターではありません。

軸は、子、子孫、親、または次の兄弟といった関係に名前を付けます。述語は、属性または別の条件をテストすることができます。式 .//a[@href] 適切なHTMLドキュメント内でhref属性を持つ子孫アンカーに狭めます。

位置は注意を要します。 (.//p)[1] 現在のコンテキストの下でグループ化された子孫結果の最初の段落を選択しますが、 .//p[1] 異なるステップレベルの意味を持っています。括弧はクエリのロジックの一部であり、単なるフォーマットではありません。

データが必要とする関係のみを選択してください。すべてのラッパー要素に基づくパスは、無害なレイアウトコンテナが挿入されると壊れる可能性があります。ソースが意味を提供する場所でその意味にレコードを参照してください。

相対XPathとレコード境界

相対XPathは、評価者がそのレコードをコンテキストとして使用する場合に、既知のレコード内で抽出を維持します。これは、繰り返し現れるエンティティを含むページで価値があります。

許可されたカタログページには商品カードがあります。まず各カードを特定し、次にその文脈内でカードのタイトル、宛先リンク、および価格を抽出します。外側のループはエンティティを定義し、内側の式はそのフィールドを定義します。

カードループ内のドキュメント全体の式は、別のカードから値を誤って返す可能性があります。グローバルな子孫検索で始まる式は慎重に確認する必要があります。現在のノードの下に留まることを意図している場合は、明示的にコンテキスト相対的な形式を使用してください。

欠落したフィールドは正しいレコードに添付されたままになります。価格のないカードは、抽出がカードごとにスコープされている場合、後のタイトル-価格ペアをすべて移動させることはありません。これにより、ページ全体のリストを独立して収集し、それらを位置によって結合する際の一般的な問題を回避できます。

The DOMツリーとXPath評価モデル これらの操作のためのブラウザレベルのコンテキストを提供します。アプリケーションは、フィールドがレコードを受け入れるためにオプション、あいまい、または必須であるかどうかを決定する必要があります。

テキスト、属性、および返される値

XPathの選択とテキスト抽出は関連していますが、異なる操作です。評価者は、式と要求された結果タイプに応じて、ノードまたは変換された値を返すことができます。

属性選択はリンク値を特定できますが、要素選択はアプリケーションがコンテンツを読み取れるノードを特定します。テキストノードの式は、要素の完全な子孫テキストを読み取るのとは異なる動作をする場合があります。ネストされたスパンや他のマークアップがその違いを明確にします。

インライン要素を含むラベルについては、即時テキストノードのみを読み取ると、表示される文言の一部が省略される場合があります。フィールド契約が生のノード、組み合わせたテキスト、または正規化された文字列を必要とするかを判断してください。ホワイトスペースのクリーンアップや変換が意味を消す可能性がある場合は、ソーステキストを保持してください。

ブラウザ Document.evaluate 結果の処理 明示的な結果タイプをサポートします。単一ノードの結果は、アプリケーションが一致をカウントしない限り、予期しない多重性を隠すことがあります。イテレータまたはスナップショットは、そのタイプに適切な処理が必要です。

変換は慎重に行ってください。文字列の結果は一部のフィールドに便利ですが、選択がないと空の値に変わることがあります。欠如が重要な場合は、変換する前に選択を検証してください。

名前空間とXPathランタイムの互換性

XPathの互換性は、評価者および文書の種類によって異なります。ブラウザネイティブのXPathは一般的にXPath 1.0の動作に従います。他のエンジンは、後の言語バージョンや拡張機能をサポートしている場合があります。

ランタイム間で式を転送する際は、それらのサポートされる関数と返り値の処理を確認することなく行わないでください。後のバージョンの関数を使用した式は、あるエンジンでは有効であっても、別のエンジンでは利用できない場合があります。専門のスクレイパーインターフェースで動作するクエリは、同じ構文がブラウザで機能することの証明にはなりません。

名前空間は、特にXMLや名前空間付きコンテンツにおいて、別の区別を導入します。プレフィックスがない名前のテストは、すべての名前空間における同じローカル名に対する普遍的な一致ではありません。クエリプレフィックスを意図された名前空間URIに関連付けるために、名前空間リゾルバが必要になる場合があります。

広範なローカル名テストは診断に役立つ場合がありますが、無関係な語彙に一致することもあります。文書が必要とする場合は、明示的な名前空間処理を優先してください。パーサーモードも記録してください：HTMLとして解析する場合とXMLとして解析する場合では、異なる命名およびツリーの挙動が生じる可能性があります。

実際のランタイムで代表的なクエリを検証します。ライブラリやパーサーの変更がフィールドの意味を静かに変更しないように、式と抽出契約を一緒に保存します。

XPathとCSSセレクター

XPathとCSSセレクターは通常の要素選択で重複しますが、構文と評価器の動作は異なります。ランタイムでレコード関係を明確に表現する言語を選択してください。

CSSは決して先祖関連の条件を表現できないと主張することを避けるべきです。モダンなリレーショナルセレクターは、そのような関係の一部を記述することができます。また、普遍的な速度ランキングを避けてください。パフォーマンスは、評価者、式、およびワークロードによって異なります。

The XPath と CSS セレクタの比較 実装コンテキストを提供します。古い例からの表現またはカテゴリー的な主張を採用する前に、ランタイムの動作と現在の標準を再確認してください。

動的ページに対する保守可能なXPath

メンテナブルなXPathは、安定したレコード契約と観察可能なドキュメントに依存しています。意味のある属性を使用し、位置に関する仮定を制限し、欠落している場合と複数のマッチを両方検証してください。

ブラウザ生成の絶対パスは、現在、プレゼンテーション階層全体をエンコードしながらノードを識別できます。新しいラッパーが挿入されると、パスが一致しなくなる可能性があります。意味のあるセクションにアンカーを持つ短い表現は、意図したフィールドをより適切に表現できますが、それでもソースの検査が必要です。

関連するバリアント全体で表現を確認します。割引商品には複数の価格要素がある場合があります; 在庫がない商品は購入コントロールを省略することがあります。これらのバリアントは、単一の満足なページへの予期しない例外ではなく、フィールド設計の一部として扱います。

レンダリングが必要な場合、 スクレイプレスエージェントブラウザ 実行層を提供します、記述されたその中で。 ブラウザセッションのドキュメントXPathは結果のツリーをクエリします。ページが認証されているか、データがビジネス契約を満たしているかを判断することはできません。

レビュー スクレイプレスプライシング ブラウザで作業するためのタスクが必要です。クエリのメンテナンスと拒否されたページのレビューは運営計画に含めてください。選択の質はアプリケーションの責任となります。

結論

XPathは、コンテキスト、述語、およびランタイムの動作に依存する精度を持つドキュメントクエリ言語です。既知のレコード内で相対選択を使用し、値を受け入れる前に多重性を確認し、名前空間を慎重に扱います。

実際のツリーから始め、それをコピーしたパスではなくします。各式がフィールドの意味を説明するようにし、代表的なページのバリエーションを通じてそれを検証します。その結果は、ソースが変更されたときに説明できるクエリになります。

参考文献

• エージェントブラウザのドキュメント実行
• Scrapeless Agent Browser
• XPathとCSSセレクタの比較