2

C＃WebClientを使用して、ログインの詳細をページに投稿し、すべての結果を読み取ります。

ロードしようとしているページには、フラッシュが含まれています（ブラウザーでは、これはHTMLに変換されます）。私はそれが検索エンジンによって拾われるのを避けるためにフラッシュだと思いますか？

私が興味を持っているフラッシュはテキスト（画像/ビデオではない）などであり、Firefoxで「選択ソースを表示」すると、実際にHTML内で見たいテキストが表示されます。

（興味深いことに、ページ全体のソースを表示すると、HTML内に表示したいテキストが表示されません。これは関連している可能性がありますか？）

現在、ログインの詳細を投稿し、HTMLをロードし直した後、フラッシュHTMLが表示されないページが表示されます（ページ全体のソースを表示したかのように）。

前もって感謝します、

ジム

PS：POSTが実際に機能していて、ログインが成功していることを指摘しておく必要があります。

4

2 に答える 2

9

Fiddler（または同様のツール）は、このような画面スクレイピングの問題を追跡するのに非常に役立ちます。通常のブラウザを使用し、フィドラーをアクティブにして、ログインおよびナビゲーションプロセスを実行するときに行われるすべての要求を確認して、必要なデータにアクセスします。その間に、サーバーが応答しているコードの動作が異なる1つ以上のことが表示される可能性があります。そのため、実際のクライアントとは異なるHTMLが表示されます。

以下のリスト（「スクレイピング101」と考えてください）は、探したいものです。以下のほとんどのものはおそらくあなたがすでに行っているものですが、完全を期すためにすべてを含めました。

効果的にこすり落とすには、次の1つ以上に対処する必要があります。

  1. クッキーおよび/または隠​​しフィールド。サイトの任意のページに表示されると、通常、セッションCookieや非表示のフォームフィールドが表示されます。これらは（通常のブラウザでは）後続のすべてのリクエストでサーバーに伝播されます。また、永続的なCookieを取得する可能性があります。多くのサイトでは、リクエストが適切なCookie（または「Cookieなしのセッション」を使用するサイトのフォームフィールド）なしで表示された場合、サイトはユーザーを「Cookieなし」のUI、ログインページ、または別の望ましくない場所（スクレーパーアプリの視点）。常に最初のリクエストで設定されたCookieをキャプチャし、後続のリクエストの1つがCookieを変更する場合を除いて（その場合は代わりにその新しいCookieを伝播する）、後続のリクエストでそれらをサーバーに忠実に送り返すようにしてください。
  2. 上記の特殊なケースである認証トークンは、フォーム認証Cookieまたは非表示フィールドです。ログイントークン（通常はCookie）をキャプチャして、返送していることを確認してください。
  3. POSTとGETは明らかですが、実際のブラウザと同じHTTPメソッドを使用していることを確認してください。
  4. フォームフィールド（特に非表示のフィールド）はすでに実行していると思いますが、表示されているフィールドだけでなく、実際のブラウザが実行するすべてのフォームフィールドを送信するようにしてください。フィールドが適切にHTMLエンコードされていることを確認してください。
  5. HTTPヘッダー。すでにこれをチェックしましたが、（Cookie以外の）ヘッダーが同一であることを確認するためだけにもう一度チェックするのが理にかなっている場合があります。私は常にまったく同じヘッダーから始めて、ヘッダーを1つずつ引き出し始め、リクエストが失敗したり、偽のデータを返したりする原因となるヘッダーのみを保持します。このアプローチにより、スクレイピングコードが簡素化されます。
  6. リダイレクトします。これらは、サーバーまたはクライアントスクリプトのいずれかから取得できます（たとえば、「ユーザーがフラッシュプラグインをロードしていない場合は、非フラッシュページにリダイレクトします」）。WebRequest：このContentType = "application / xhtml + xml、text / xml、text / html; charset =utf-8"に対してWebRequestを使用して郵便番号を見つける方法を参照してください。リダイレクションがスクリーンスクレイパーをつまずかせる方法のクレイジーな例については。スクレイピングに.NETを使用している場合は、リダイレクトに依存するスクレイピングにHttpWebRequest（WebClientではなく）を使用する必要があることに注意してください。デフォルトでは、WebClientは、コードがCookieとヘッダーを2番目に添付する方法を提供しないためです。 （リダイレクト後）リクエスト。詳細については、上記のスレッドを参照してください。
  7. サブリクエスト（フレーム、ajax、フラッシュなど） -多くの場合、ページ要素（メインのHTTPリクエストではない）は、スクレイプするデータをフェッチすることになります。どのHTTP応答に必要なテキストが含まれているかを調べ、ページ上の何が実際にそのコンテンツを要求しているかがわかるまで逆方向に作業することで、これを理解できます。いくつかのサイトは、サブリクエストで本当にクレイジーなことをします。たとえば、ajaxを介して圧縮または暗号化されたテキストをリクエストし、クライアント側のスクリプトを使用してそれを復号化します。この場合、クライアントスクリプトが実行していることをリバースエンジニアリングするなど、もう少し作業を行う必要があります。
  8. 順序付け-これは明らかです。ブラウザクライアントと同じ順序でHTTPリクエストを作成します。それはあなたがすべての要求（例えば画像）をする必要があるという意味ではありません。通常、必要なデータがHTMLになく、ajax / flash / etcにない限り、text/htmlコンテンツタイプを返すリクエストを行うだけで済みます。リクエスト。
于 2009-10-05T17:15:59.947 に答える
0

（興味深いことに、ページ全体のソースを表示すると、HTML内に表示したいテキストが表示されません。これは関連している可能性がありますか？）

これは通常、ページが読み込まれた後のjavascriptを介した一部のDOM操作が原因で不一致が発生することを意味します。javascriptをオフにして、どのように表示されるかを確認してください。

于 2009-10-05T17:25:50.597 に答える