6

インタビューのクイズの質問に答えていましたが、質問はスクリーンスクレイピングをどのように行うかについてでした. つまり、情報を直接照会するより構造化された方法 (Web サービスなど) がないと仮定して、Web ページからコンテンツを選択することです。

私の解決策は、XQuery式を使用することでした。必要なコンテンツが HTML 階層のかなり深いところにあったため、式はかなり長くなりました。id属性を持つ要素を見つける前に、かなりの方法で祖先を検索する必要がありました。たとえば、製品ディメンションの Amazon.com ページをスクレイピングすると、次のようになります。

//a[@id="productDetails"]
/following-sibling::table
//h2[contains(child::text(), "Product Details")]
/following-sibling::div
//li
/b[contains(child::text(), "Product Dimensions:")]
/following-sibling::text()

これはかなり厄介な表現ですが、Amazon が Web サービス API を提供するのはそのためです。とにかく、それはほんの一例です。質問は Amazon に関するものではなく、スクリーン スクレイピングに関するものです。

インタビュアーは私の解決策を気に入らなかった. Amazon によるページ デザインの変更により、XQuery 式の書き直しが必要になる可能性があるため、彼はそれが壊れやすいと考えました。適用対象のページ内のどこにも一致しない XQuery 式をデバッグするのは困難です。

私は彼の発言に反対しませんでしたが、彼の解決策が改善だとは思いませんでした. たとえば、Perl を使用すると、次のようになります。

$html =~ m{<li>\s*<b>\s*Product Dimensions:\s*</b>\s*(.*?)</li>}s;

私の反論は、これは Amazon が HTML コードを変更しても影響を受けやすいというものでした。HTML タグを大文字 ( <LI>) で綴ったり、CSS 属性を追加したり、ラベル「製品の寸法:」を「寸法:」に変更<b>し<span>たり、その他のさまざまな種類の変更を行ったりすることができます。私の言いたいことは、彼が私の XQuery ソリューションで指摘した弱点は、正規表現では解決できないということでした。

さらに、正規表現に十分なコンテキストを追加しない限り、正規表現は誤検知を検出する可能性があります。また、コメント、属性文字列、または CDATA セクション内にあるコンテンツと意図せず一致することもあります。

私の質問は、スクリーンスクレイピングを行うためにどのテクノロジーを使用していますか? なぜそのソリューションを選択したのですか？それを使用する説得力のある理由はありますか？それとも他のものを使用しないのですか？上に示したもの以外に 3 番目の選択肢はありますか?

PS: 議論のために、目的のコンテンツを取得するための Web サービス API やその他のより直接的な方法はないと仮定します。

4

8 に答える 8

4

正規表現を使用しますが、ほとんどのHTMLページが有効なXMLではないため、XQUERYが機能することはありません。

XQueryはわかりませんが、私にはXPATH式のように見えます。もしそうなら、それは非常に多くの「//」演算子が含まれているので少し高価に見えます。

于 2009-03-14T19:06:02.033 に答える
3

マネージャーが与えた理由から、正規表現を使用します。それに加えて、いくつかの表現を使用します（より移植性が高く、外部のプログラマーがフォローしやすいなど）。

あなたの反論は、彼の解決策が局所的な変化に関して脆弱であったのに対し、あなたの解決策は地球規模の変化に関して脆弱であるという点を見逃しています。彼を壊すものはおそらくあなたを壊しますが、その逆はありません。

最後に、彼のソリューションにスロップ/フレックスを組み込む方がはるかに簡単です（たとえば、入力の複数のマイナーなバリエーションを処理する必要がある場合）。

于 2009-03-14T19:01:19.567 に答える
2

JTidy または BeautifulSoup を試してみてください。確かに // XPATH experssion は破棄するのに非常にコストがかかります。

于 2009-04-22T16:06:00.720 に答える
1

スクリーンスクレイピングのための非脆性ソリューション？そのためのインタビュアーに幸運を祈ります。正規表現が多くのコンテキストを捨てるからといって、それらがそれほど脆弱ではないという意味ではありません。他の方法でも脆弱であるというだけです。脆弱性も欠点ではないかもしれません。ソースWebページで何かが変更された場合、ソリューションが巧妙な（そして予測できない）方法で補正しようとするよりも、ソリューションがアラームを発した方がよい場合がよくあります。あなたが指摘したように。これらのことは常にあなたの仮定に依存します：この場合、何が起こりそうな変化を構成するかに依存します。

私はHTMLの敏捷性パックがかなり好きです。XPathの表現力と組み合わされた非XHTML準拠のWebページの許容範囲を取得します。

于 2009-03-14T19:53:43.917 に答える
1

スクラップにはBeautifulSoupを使用しています。

于 2009-03-14T19:08:50.763 に答える
1

実際、CSS検索式はどちらよりも読みやすいと思います。ページを解析し、特定の要素を見つけるためのCSSディレクティブを記述できるようにする、選択した言語のライブラリが少なくとも1つ存在する可能性があります。近くに適切なクラスまたはIDフックがある場合、式は非常に簡単です。それ以外の場合は、適切と思われる要素を取得し、それらを繰り返し処理して、必要な要素を見つけます。

壊れやすいということに関しては、まあ、それらはすべて壊れやすいです。スクリーンスクレイピングは、定義上、そのページの作成者がレイアウトを大幅に変更しないことに依存しています。読みやすく、後で簡単に変更できるソリューションを選択してください。

于 2009-03-14T19:11:07.827 に答える
1

正規表現は非常に高速で、非 XML ドキュメントで機能します。これらは、XQuery に対する非常に優れた点です。ただし、あなたの最後の部分だけのように、XHTML へのコンバーターを使用すると、整理された、おそらくやや単純な XQuery のようになると思います。

//b[contains(child::text(), "Product Dimensions:")]/following-sibling::text()

非常に良い代替手段です。

よろしく、

ラファル・ルーシン

于 2010-01-23T19:50:39.393 に答える
1

HTML ページで作業するには、HTMLAgilityPack (およびいくつかの Linq コード) を使用することをお勧めします。これは、すべての要素を解析したり、XPath で直接検索したりするのに最適な方法です。私の意見では、正規表現よりも正確で、プログラミングが簡単です。以前は少し使いにくかったのですが、プロジェクトに追加するのは非常に簡単で、html を扱うためのデファクター スタンダードだと思います。http://htmlagilitypack.codeplex.com/

幸運を！

于 2012-12-30T05:17:04.107 に答える