大規模なアーティストデータベースを備えたかなり大きな音楽ウェブサイトを持っています。私は他の音楽サイトが私たちのサイトのデータをかき集めていることに気づきました(私はダミーのアーティスト名をあちこちに入力してから、それらをgoogle検索します)。
画面の削れを防ぐにはどうすればよいですか?可能ですか?
大規模なアーティストデータベースを備えたかなり大きな音楽ウェブサイトを持っています。私は他の音楽サイトが私たちのサイトのデータをかき集めていることに気づきました(私はダミーのアーティスト名をあちこちに入力してから、それらをgoogle検索します)。
画面の削れを防ぐにはどうすればよいですか?可能ですか?
回答:
注:この回答の完全版はStack Overflowの長さ制限を超えているため、GitHubにアクセスして拡張バージョンを読み、さらにヒントや詳細を読む必要があります。
スクレイピング(Webscraping、Screenscraping、Webデータマイニング、Webハーベスト、またはWebデータ抽出とも呼ばれます)を妨げるには、これらのスクレイパーの動作を理解し、ひいてはスクレイパーがうまく機能しない原因を知ることが役立ちます。
スクレーパーにはさまざまな種類があり、それぞれ動作が異なります。
以下のようなクモ、Googleのボットのようなウェブサイトやコピー機HTtrack再帰的なデータを取得するために、他のページへのリンクをたどります。これらは、特定のデータを取得するためのターゲットを絞ったスクレイピングに使用されることがあり、多くの場合、HTMLパーサーと組み合わせて、各ページから必要なデータを抽出します。
シェルスクリプト:時々、スクレイピングに一般的なUnixツールが使用されます:WgetまたはCurlでページをダウンロードし、Grep(正規表現)でデータを抽出します。
Jsoup、Scrapyなどに基づくHTMLパーサー。シェルスクリプトの正規表現ベースのものと同様に、これらはHTMLのパターンに基づいてページからデータを抽出することで機能し、通常はその他すべてを無視します。
例:Webサイトに検索機能がある場合、そのようなスクレイパーは検索リクエストを送信し、結果ページのHTMLからすべての結果リンクとそのタイトルを取得して、特に検索結果リンクとタイトルのみを取得する場合があります。 。これらは最も一般的です。
スクリーンスクレイパー。SeleniumまたはPhantomJS。実際のブラウザーでWebサイトを開き、JavaScript、AJAXなどを実行してから、通常は次のようにWebページから目的のテキストを取得します。
ページが読み込まれ、JavaScriptが実行された後、ブラウザからHTMLを取得し、HTMLパーサーを使用して目的のデータを抽出します。これらは最も一般的であり、HTMLパーサー/スクレイパーを壊すための多くの方法もここで機能します。
レンダリングされたページのスクリーンショットを撮り、OCRを使用してスクリーンショットから目的のテキストを抽出します。これらはまれであり、あなたのデータを本当に望んでいる専用のスクレーパーだけがこれを設定します。
ScrapingHubやKimonoなどのWebscrapingサービス。実際、あなたのサイトをこすり、他の人が使用できるようにコンテンツを引き出す方法を理解するのが仕事の人がいます。
当然のことながら、専門のスクレイピングサービスは阻止するのが最も困難ですが、サイトをスクレイピングする方法を理解するのが困難で時間のかかる場合は、これら(およびそうするためにお金を払う人)がWebサイトをスクレイピングすることに煩わされない場合があります。
フレーム付きの他のサイトのページにあなたのウェブサイトを埋め込み、モバイルアプリにあなたのサイトを埋め込みます。
技術的にスクレイピングではありませんが、モバイルアプリ(AndroidおよびiOS)はWebサイトを埋め込んだり、カスタムCSSやJavaScriptを挿入したりして、ページの外観を完全に変えることができます。
人間によるコピー-貼り付け:他の場所で使用するために、人々はあなたのコンテンツをコピーして貼り付けます。
これらの異なる種類のスクレーパーの間には多くの重複があり、多くのスクレーパーが異なる技術と方法を使用していても、同様に動作します。
これらのヒントは、主に私自身のアイデア、スクレイパーを作成しているときに遭遇したさまざまな困難、およびインターウェブ周辺の情報とアイデアのビットです。
あなたが何をするにせよ、断固としたスクレイパーはスクレイピングの方法をまだ理解できるので、あなたはそれを完全に防ぐことはできません。ただし、いくつかのことを行うことで、大量のスクレイピングを停止できます。
ログを定期的に確認し、同じIPアドレスからの多くの同様のアクションなど、自動アクセス(スクレイパー)を示す異常なアクティビティが発生した場合は、アクセスをブロックまたは制限できます。
具体的には、いくつかのアイデア:
レート制限:
ユーザー(およびスクレイパー)が特定の時間内に限られた数のアクションを実行できるようにします。たとえば、特定のIPアドレスまたはユーザーからの1秒あたり数回の検索のみを許可します。これはスクレーパーを遅くし、それらを無効にします。アクションが実際のユーザーよりも速くまたは速く完了した場合は、キャプチャを表示することもできます。
異常なアクティビティを検出:
特定のIPアドレスからの多くの類似したリクエスト、過度の数のページを閲覧したり、異常な数の検索を実行したりするなど、異常なアクティビティが見られる場合は、アクセスを禁止するか、後続のリクエストのキャプチャを表示できます。
IPアドレスによる監視とレート制限だけではなく、他のインジケーターも使用してください。
ブロックまたはレート制限を行う場合は、IPアドレスごとに行うのではなく、他のインジケーターや方法を使用して、特定のユーザーやスクレイパーを特定できます。特定のユーザー/スクレーパーを特定するのに役立ついくつかのインジケーターは次のとおりです。
ユーザーがフォームに入力する速度と、ボタンのどこをクリックするか。
画面サイズ/解像度、タイムゾーン、インストールされているフォントなど、JavaScriptを使用して多くの情報を収集できます。これを使用してユーザーを識別できます。
HTTPヘッダーとその順序、特にUser-Agent。
例として、1つのIPアドレスから多くのリクエストを受け取った場合、すべて同じユーザーエージェント、画面サイズ(JavaScriptで決定)、およびユーザー(この場合はスクレイパー)は常に同じ方法でボタンをクリックします。定期的に、それはおそらくスクリーンスクレーパーです。また、同様のリクエストを一時的にブロックすることもできます(たとえば、その特定のIPアドレスから送信されるそのユーザーエージェントと画面サイズのすべてのリクエストをブロックする)。これにより、そのIPアドレスの実際のユーザーに迷惑をかけません。共有インターネット接続の場合。
分散したスクレイピング(ボットネットまたはプロキシのネットワークを使用するスクレイパー)を示す、異なるIPアドレスからのリクエストであっても、同様のリクエストを識別できるため、これをさらに進めることもできます。それ以外は同一のリクエストが多数ありますが、それらが異なるIPアドレスからのものである場合は、ブロックできます。この場合も、実際のユーザーを誤ってブロックしないように注意してください。
これは、JavaScriptを実行するスクリーンスクレイパーに対して有効です。スクリーンスクレイパーから多くの情報を取得できるためです。
Security Stack Exchangeに関する関連質問:
同じ外部IPアドレスを持つユーザーを一意に識別する方法は?詳細については、
IPアドレスが頻繁に変更されるのに、なぜ人々はIPアドレス禁止を使用するのですか?これらのメソッドの制限については、
アクセスを一時的にブロックする代わりに、キャプチャを使用します:
レート制限を実装する簡単な方法は、一定時間アクセスを一時的にブロックすることですが、キャプチャを使用する方が良い場合があります。さらに下のキャプチャのセクションを参照してください。
サイトで実現可能な場合は、コンテンツを表示するためにアカウントの作成が必要です。これはスクレーパーにとって良い抑止力ですが、実際のユーザーにとっても良い抑止力です。
スクリプトが多数のアカウントを作成しないようにするには、次のことを行う必要があります。
登録にはメールアドレスが必要です。アカウントをアクティブにするために開く必要があるリンクを送信して、そのメールアドレスを確認します。メールアドレスごとに1つのアカウントのみを許可します。
登録/アカウント作成中にキャプチャを解決する必要があります。
コンテンツを表示するためにアカウントの作成を要求すると、ユーザーと検索エンジンが離れてしまいます。記事を表示するためにアカウントを作成する必要がある場合、ユーザーは別の場所に移動します。
スクレイパーは、Amazon WebサービスやGAEなどのWebホスティングサービス、またはVPSから実行される場合があります。このようなクラウドホスティングサービスで使用されるIPアドレスから送信されたリクエストに対して、ウェブサイトへのアクセスを制限します(またはキャプチャを表示します)。
同様に、スクレイパーがこのようなプロキシサーバーを使用して多くのリクエストが検出されないようにするため、プロキシまたはVPNプロバイダーが使用するIPアドレスからのアクセスを制限することもできます。
プロキシサーバーやVPNからのアクセスをブロックすると、実際のユーザーに悪影響を及ぼすことに注意してください。
アクセスをブロックまたは制限する場合は、スクレイパーにブロックの原因を伝えないようにして、スクレイパーの修正方法についての手掛かりを与える必要があります。したがって、次のようなテキストでエラーページを表示するのは悪い考えです。
IPアドレスからのリクエストが多すぎます。しばらくしてからもう一度お試しください。
エラー、ユーザーエージェントヘッダーがありません!
代わりに、原因をスクレイパーに知らせないわかりやすいエラーメッセージを表示します。このようなものははるかに優れています:
helpdesk@example.com
問題が解決しない場合は、からサポートにお問い合わせください。これは、実際のユーザーにとって、このようなエラーページが表示された場合でも、はるかにユーザーフレンドリーです。また、実際のユーザーにエラーメッセージが表示される場合に備えて、ハードブロックの代わりにキャプチャを表示して、正当なユーザーに連絡されないようにする必要があります。
キャプチャ(「コンピュータと人間を区別するための完全に自動化されたテスト」)は、スクレイパーの停止に対して非常に効果的です。残念ながら、それらはユーザーを苛立たせるのにも非常に効果的です。
そのため、スクレイパーの可能性が疑われ、スクレイパーではなく実際のユーザーである場合にアクセスをブロックせずにスクレイピングを停止したい場合に役立ちます。スクレイパーが疑われる場合は、コンテンツへのアクセスを許可する前にキャプチャを表示することを検討してください。
キャプチャを使用する際の注意事項:
自分でロールバックするのではなく、GoogleのreCaptchaなどを使用してください。自分でキャプチャを実装するよりもはるかに簡単です。自分で思いつく可能性のあるぼやけて歪んだテキストソリューションよりもユーザーフレンドリーです(ユーザーは多くの場合、ボックスにチェックを入れるだけで済みます) )、そしてまた、あなたのサイトから提供される単純な画像よりもスクリプト作成者が解決することははるかに困難です
HTMLマークアップにキャプチャのソリューションを含めないでください。ページ自体にキャプチャのソリューションが含まれているWebサイトを実際に見たことがあります(かなりよく非表示になっています)。このようなことをしないでください。この場合も、reCaptchaなどのサービスを使用すれば、このような問題は発生しません(適切に使用すれば)。
キャプチャは一括で解決できます。実際の低コストの人間がキャプチャを一括で解決するキャプチャ解決サービスがあります。繰り返しになりますが、reCaptchaには保護機能があるため(ユーザーがキャプチャを解決するために比較的短い時間など)、reCaptchaを使用することをお勧めします。この種のサービスは、データが本当に価値がない限り使用されることはほとんどありません。
テキストを画像をサーバー側にレンダリングし、それを表示するように提供できます。これは、単純なスクレイパーがテキストを抽出するのを妨げます。
ただし、これはスクリーンリーダー、検索エンジン、パフォーマンス、およびその他のほとんどすべてに悪影響を及ぼします。また、一部の場所では違法であり(たとえば、障害を持つアメリカ人法など)、一部のOCRで簡単に回避できるため、これを行わないでください。
CSSスプライトでも同様のことができますが、同じ問題があります。
可能であれば、スクリプト/ボットがすべてのデータセットを取得する方法を提供しないでください。例として、たくさんの個別の記事があるニュースサイトがあるとします。これらの記事は、オンサイト検索で検索することによってのみアクセス可能にすることができます。また、サイト上のすべての記事とそのURLのリストがない場合、これらの記事は検索を使用することによってのみアクセスできます。特徴。つまり、サイトからすべての記事を取得したいスクリプトは、記事に表示される可能性のあるすべてのフレーズを検索してそれらをすべて見つける必要があります。これは、時間がかかり、恐ろしく非効率的であり、うまくいけば、スクレーパーはあきらめます。
これは次の場合は効果がありません。
example.com/article.php?articleId=12345
。これ(および同様のもの)を使用すると、スクレイパーがすべてのを繰り返し処理し、articleId
すべての記事をそのように要求できます。APIを意図せずに公開しないようにしてください。たとえば、Adobe FlashまたはJavaアプレット(God forbid!)内からAJAXまたはネットワークリクエストを使用してデータをロードしている場合、ページからネットワークリクエストを見て、それらのリクエストの送信先を把握するのは簡単です。次にリバースエンジニアリングを行い、それらのエンドポイントをスクレイパープログラムで使用します。説明したように、エンドポイントを難読化し、他のユーザーが使用しにくいようにします。
HTMLパーサーは、HTMLの識別可能なパターンに基づいてページからコンテンツを抽出することで機能するため、これらのパターンを意図的に変更してこれらのスクレイパーを壊したり、ねじ込んだりすることさえできます。これらのヒントのほとんどは、スパイダーやスクリーンスクレイパーなどの他のスクレイパーにも適用されます。
HTMLを直接処理するスクレーパーは、HTMLページの特定の識別可能な部分からコンテンツを抽出することで処理します。例:ウェブサイトのすべてのページにdiv
のidがarticle-content
あり、記事のテキストが含まれている場合、サイトのすべての記事のページにアクセスしてarticle-content
divのコンテンツテキストを抽出するスクリプトを書くのは簡単です。各記事のページで、スクレイパーはあなたのサイトからのすべての記事を他の場所で再利用できるフォーマットで持っています。
HTMLとページの構造を頻繁に変更すると、そのようなスクレイパーは機能しなくなります。
HTML内の要素のIDとクラスを頻繁に、おそらくは自動的に変更することもできます。したがって、がのようにdiv.article-content
なりdiv.a4c36dda13eaf0
、毎週変わる場合、スクレーパーは最初は正常に動作しますが、1週間後に壊れます。ID /クラスの長さも必ず変更してください。変更しない場合、スクレイパーがdiv.[any-14-characters]
目的のdivを見つけるために代わりに使用します。他の同様の穴にも注意してください。
マークアップから目的のコンテンツを見つける方法がない場合、スクレイパーはHTMLの構造化方法からそれを行います。したがって、すべての記事ページが類似している場合div
、aのdiv
後にh1
続くすべての内部が記事のコンテンツである場合、スクレイパーはそれに基づいて記事のコンテンツを取得します。繰り返しになりますが、これを壊すために、HTMLに余分なマークアップを定期的にランダムに追加/削除することができます。余分なdiv
sまたはspan
s を追加します。最新のサーバー側のHTML処理では、これは難しくありません。
注意事項:
実装、保守、デバッグが面倒で難しくなります。
キャッシュを妨げます。特にHTML要素のIDまたはクラスを変更する場合は、CSSおよびJavaScriptファイルで対応する変更が必要になります。つまり、変更するたびに、ブラウザーでそれらを再ダウンロードする必要があります。これにより、リピーターのページ読み込み時間が長くなり、サーバーの読み込みが増加します。週に一度だけ交換すれば大した問題にはなりません。
賢いスクレーパーは、実際のコンテンツがどこにあるかなどを推測することで、コンテンツを取得できます。ページ上のテキストの大きな単一のブロックが実際の記事である可能性が高いことを知ることによって。これにより、ページから目的のデータを見つけて抽出することができます。Boilerpipeはまさにこれを行います。
基本的に、スクリプトが類似するすべてのページで実際に必要なコンテンツを見つけるのが容易でないことを確認してください。
これをPHPに実装する方法の詳細については、XPathに依存するクローラーがページコンテンツを取得しないようにする方法も参照してください。
これは、前のヒントと似ています。ユーザーの場所/国(IPアドレスで決定)に基づいて異なるHTMLを提供する場合、ユーザーに配信されるスクレイパーが破損する可能性があります。たとえば、誰かがサイトからデータをスクレイピングするモバイルアプリを作成している場合、最初は正常に動作しますが、実際にユーザーに配布されると中断します。ユーザーが別の国にいるため、異なるHTMLを取得する可能性があるためです。埋め込みスクレーパーは、消費するようには設計されていません。
例:Webサイトに検索機能example.com/search?query=somesearchquery
があり、次のHTMLを返します。
<div class="search-result">
<h3 class="search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
<p class="search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
<a class"search-result-link" href="/stories/story-link">Read more</a>
</div>
(And so on, lots more identically structured divs with search results)
ご想像のとおり、これは簡単にスクレイピングできます。スクレイパーが実行する必要があるのは、クエリで検索URLをヒットし、返されたHTMLから目的のデータを抽出することだけです。上記のようにHTMLを定期的に変更することに加えて、古いIDとクラスを含む古いマークアップを残し、CSSで非表示にして、偽のデータで埋めることで、スクレイパーを汚染することもできます。検索結果ページを変更する方法は次のとおりです。
<div class="the-real-search-result">
<h3 class="the-real-search-result-title">Stack Overflow has become the world's most popular programming Q & A website</h3>
<p class="the-real-search-result-excerpt">The website Stack Overflow has now become the most popular programming Q & A website, with 10 million questions and many users, which...</p>
<a class"the-real-search-result-link" href="/stories/story-link">Read more</a>
</div>
<div class="search-result" style="display:none">
<h3 class="search-result-title">Visit Example.com now, for all the latest Stack Overflow related news !</h3>
<p class="search-result-excerpt">Example.com is so awesome, visit now !</p>
<a class"search-result-link" href="http://example.com/">Visit Now !</a>
</div>
(More real search results follow)
つまり、クラスまたはIDに基づいてHTMLからデータを抽出するために作成されたスクレイパーは、見かけ上は機能し続けますが、CSSで非表示にされているため、偽のデータまたは広告さえも得られます。
前の例に加えて、目に見えないハニーポットアイテムをHTMLに追加して、スクレイパーをキャッチできます。前述の検索結果ページに追加できる例:
<div class="search-result" style="display:none">
<h3 class="search-result-title">This search result is here to prevent scraping</h3>
<p class="search-result-excerpt">If you're a human and see this, please ignore it. If you're a scraper, please click the link below :-)
Note that clicking the link below will block access to this site for 24 hours.</p>
<a class"search-result-link" href="/scrapertrap/scrapertrap.php">I'm a scraper !</a>
</div>
(The actual, real, search results follow.)
すべての検索結果を取得するために作成されたスクレーパーは、ページ上の他の実際の検索結果と同様にこれを取得し、リンクにアクセスして目的のコンテンツを探します。実際の人間は(CSSで非表示になっているため)そもそもそれを見ることはなく、リンクにアクセスすることもありません。/scrapertrap/
robots.txtで許可されていないため、Googleのような本物の望ましいスパイダーもリンクにアクセスしません。
あなたは作ることができscrapertrap.php
、それを訪問したか、そのIPからのすべての後続の要求のためのキャプチャを強制するIPアドレスのブロックアクセスのような何かを。
/scrapertrap/
検索エンジンボットがハニーポットに陥らないように、robots.txtファイルでハニーポット()を禁止することを忘れないでください。
これを、HTMLを頻繁に変更する以前のヒントと組み合わせることができます。
スクレイパーは最終的にそれを回避することを学ぶので、これも頻繁に変更してください。ハニーポットのURLとテキストを変更します。また、非表示に使用されるインラインCSSの変更を検討し、代わりにID属性と外部CSSを使用します。スクレーパーはstyle
、コンテンツを非表示にするために使用されるCSSの属性を持つものを回避することを学ぶためです。また、時々それを有効にしてみてください。スクレイパーは最初は機能しますが、しばらくすると壊れます。これは前のヒントにも当てはまります。
悪意のあるユーザーは、ハニーポットへのリンクを共有したり、そのリンクを画像(フォーラムなど)のどこかに埋め込んだりして、実際のユーザーのアクセスを妨害する可能性があります。URLを頻繁に変更し、禁止期間を比較的短くします。
明らかにスクレイパーであるものを検出した場合、偽の役に立たないデータを提供できます。これにより、スクレイパーがWebサイトから取得したデータが破損します。また、このような偽のデータと実際のデータを区別できないようにして、スクレイパーがねじ込まれていることを知らないようにする必要もあります。
例として、あなたはニュースWebサイトを持っています。アクセスをブロックする代わりにスクレイパーを検出すると、ランダムに生成された偽の記事を提供します。これにより、スクレイパーが取得するデータが汚染されます。偽のデータを本物と見分けがつかないようにすると、スクレイパーが望むもの、つまり実際の本物のデータを取得することが難しくなります。
多くの場合、遅延して書かれたスクレイパーは、要求とともにユーザーエージェントヘッダーを送信しませんが、すべてのブラウザーと検索エンジンスパイダーは送信します。
ユーザーエージェントヘッダーが存在しないリクエストを受け取った場合、キャプチャを表示したり、アクセスをブロックまたは制限したりできます。(または、上記のように偽のデータまたはその他の何かを提供します。)
なりすましはささいなことですが、不適切に記述されたスクレイパーに対する対策として、実装する価値があります。
場合によっては、スクレイパーは実際のブラウザや検索エンジンスパイダーが使用しないユーザーエージェントを使用します。
特定のユーザーエージェント文字列がサイトのスクレイパーで使用されていて、実際のブラウザや正規のスパイダーでは使用されていない場合は、ブラックリストに追加することもできます。
実際のブラウザは、(ほとんどの場合)画像やCSSなどのアセットをリクエストしてダウンロードします。HTMLパーサーとスクレイパーは、実際のページとそのコンテンツのみに関心があるため、必要ありません。
アセットへのリクエストをログに記録することができ、HTMLのみに対するリクエストが多数ある場合は、スクレイパーである可能性があります。
検索エンジンボット、従来のモバイルデバイス、スクリーンリーダー、および誤って構成されたデバイスもアセットを要求しない場合があることに注意してください。
Webサイトを表示するために、Cookieの有効化を要求できます。これは、経験の浅い初心者のスクレイパーライターを阻止しますが、スクレイパーがCookieを送信するのは簡単です。それらを使用して必要とする場合は、それらを使用してユーザーアクションとスクレイパーアクションを追跡し、IPごとではなくユーザーごとにキャプチャを制限したり、ブロックしたり、表示したりすることができます。
例:ユーザーが検索を実行するときに、一意の識別Cookieを設定します。結果ページが表示されたら、そのCookieを確認します。ユーザーがすべての検索結果(Cookieから確認できる)を開いた場合、それはおそらくスクレイパーです。
スクレイパーもCookieをリクエストとともに送信し、必要に応じて破棄できるため、Cookieを使用しても効果がない場合があります。また、サイトがCookieでのみ機能する場合は、Cookieが無効になっている実際のユーザーのアクセスを禁止します。
JavaScriptを使用してCookieを設定および取得する場合、JavaScriptを実行しないスクレイパーは、リクエストでCookieを取得および送信できないため、ブロックすることに注意してください。
JavaScriptとAJAXを使用して、ページ自体が読み込まれた後にコンテンツを読み込むことができます。これにより、JavaScriptを実行しないHTMLパーサーからコンテンツにアクセスできなくなります。これは、スクレイパーを書く初心者や経験の浅いプログラマにとって、しばしば効果的な抑止力になります。
次のことに注意してください。
JavaScriptを使用して実際のコンテンツをロードすると、ユーザーエクスペリエンスとパフォーマンスが低下します
検索エンジンもJavaScriptを実行しない可能性があるため、コンテンツをインデックスに登録できません。これは、検索結果ページでは問題にならない可能性がありますが、記事ページなどの他の問題では発生する可能性があります。
AjaxとJavaScriptを使用してデータをロードする場合は、転送されるデータを難読化してください。例として、サーバーでデータをエンコードし(base64のような単純なものまたはより複雑なものを使用)、Ajax経由でフェッチした後、デコードしてクライアントに表示できます。これは、ネットワークトラフィックを検査している誰かがページの動作やデータの読み込みをすぐには理解できないことを意味します。また、デスクランブルアルゴリズムをリバースエンジニアリングする必要があるため、エンドポイントからリクエストデータを直接リクエストすることは困難です。
データのロードにAjaxを使用する場合、最初にページをロードせずにエンドポイントを使用するのを難しくする必要があります。たとえば、JavaScriptまたはHTMLに埋め込むことができるパラメーターとしてセッションキーを要求するなどです。
難読化されたデータを最初のHTMLページに直接埋め込み、JavaScriptを使用して解読して表示することもできます。これにより、余分なネットワークリクエストを回避できます。これを行うと、JavaScriptを実行しないHTMLのみのパーサーを使用してデータを抽出することが非常に難しくなります。スクレイパーを作成するパーサーはJavaScriptをリバースエンジニアリングする必要があるためです(これも難読化する必要があります)。
難読化方法を定期的に変更して、それを理解したスクレイパーを壊したい場合があります。
ただし、このようなことにはいくつかの欠点があります。
実装、保守、デバッグが面倒で難しくなります。
実際にJavaScriptを実行してデータを抽出するスクレイパーやスクリーンスクレイパーに対しては効果がありません。(ただし、ほとんどの単純なHTMLパーサーはJavaScriptを実行しません)
JavaScriptが無効になっていると、実際のユーザーにとってサイトが機能しなくなります。
パフォーマンスとページの読み込み時間が低下します。
削らないように人々に言ってください、そしてそれを尊重する人もいます
弁護士を探す
データを利用可能にし、APIを提供します。
データを簡単に利用できるようにし、帰属とサイトへのリンクを要求することができます。多分それのために$$$を充電します。
CloudflareやDistill Networksによるアンチスクレイピング(ここでの仕組みの詳細)など、商用のスクレイピング保護サービスもあります。これらは、これらの機能を提供します。
実際のユーザーの使いやすさとスクレーパープルーフ性の間のバランスを見つけてください。あなたが行うすべてのことは、何らかの形でユーザーエクスペリエンスに悪影響を及ぼし、妥協点を見つけます。
モバイルサイトとアプリを忘れないでください。モバイルアプリがある場合は、それもスクリーンスクラップでき、ネットワークトラフィックを検査して、使用するRESTエンドポイントを特定できます。
スクレイパーは他のスクレイパーをスクレイピングすることができます:あなたのコンテンツからスクレイピングされたコンテンツを含むWebサイトが1つある場合、他のスクレイパーはそのスクレイパーのWebサイトからスクレイピングできます。
WikipediaのWebスクレイピングに関する記事。関連するテクノロジーやさまざまなタイプのWebスクレイパーの詳細。
スクリプト作成者が1秒間に数百回Webサイトを非難するのを阻止します。非常によく似た問題に関するQ&A-ボットがWebサイトをチェックし、セールが始まったらすぐに購入します。多くの関連情報、特に。キャプチャとレート制限について。
A real browser will (almost always) request and download assets such as images and CSS
アクセシビリティリーダーにも当てはまりますか?CAPTCHAは壊れているので、少なくとも専門サービスはおそらくそれによって妨げられていません。Cookieの使用には、EUでの通知/同意が必要です。Find a balance between usability for real users and scraper-proofness
また、プログラミングの時間/複雑さと経済的利益のバランスもとります。
あなたが設定したと思いますrobots.txt
。
他の人が述べたように、スクレーパーは活動のほぼすべての側面を偽造する可能性があり、悪意のある人からの要求を特定することはおそらく非常に困難です。
私は検討します:
/jail.html
。robots.txt
(したがって、敬意を表するスパイダーがアクセスすることはありません)。display: none
)で非表示にします。/jail.html
。これは、あなたを著しく無視しているスクレーパーからのリクエストをすばやく特定するのに役立ちます。 robots.txt
。
また、あなたのようにしたいかもしれない/jail.html
偽のデータを持つ(通常のページと同じ、正確なマークアップを持っている全体の全体のウェブサイトを、しかし/jail/album/63ajdka
、/jail/track/3aads8
など)。このようにして、完全にブロックする機会が得られるまで、不良スクレイパーは「異常な入力」について警告を受けません。
スーエム。
真剣に:あなたがお金を持っているなら、インターネットの周りで彼らの道を知っている良い、素晴らしい、若い弁護士に相談してください。あなたは本当にここで何かをすることができるでしょう。サイトのベースに応じて、あなたの国の弁護士に中止と消滅または同等のものを書いてもらうことができます。あなたは少なくともこの野郎を怖がらせることができるかもしれません。
ダミー値の挿入を文書化します。はっきりと(しかしあいまいに)指し示すダミー値を挿入します。これは電話帳会社ではよくあることだと思いますが、ここドイツでは、模倣品が1対1でコピーした偽のエントリで逮捕された例がいくつかあります。
これはSEO、妥当性や他のものの下にドラッグし、あなたのHTMLコードをめちゃくちゃにあなたを運転しまう場合は、同一ページの要求ごとにわずかに異なるHTML構造を使用してテンプレートシステムは、すでに役立つかもしれないにも関わらず(恥だろう多くのことを反対コンテンツを取得するために常にHTML構造とクラス/ ID名に依存するスクレーパー)
このような場合は、著作権法が適しています。お金を稼ぐために他の人の正直な仕事を引きはがすことは、あなたが戦うことができるべきものです。
これを完全に防ぐためにできることは本当にありません。スクレイパーは、ユーザーエージェントを偽造したり、複数のIPアドレスを使用したりして、通常のユーザーとして表示される可能性があります。あなたができる唯一のことは、ページがロードされるときにテキストを利用できないようにすることです-画像でそれを作るか、フラッシュするか、JavaScriptでそれをロードしてください。ただし、最初の2つは悪いアイデアであり、JavaScriptが一部の通常のユーザーに対して有効になっていない場合、最後の1つはアクセシビリティの問題になります。
彼らがあなたのサイトを絶対に非難し、あなたのすべてのページをくぐり抜けているなら、あなたはある種のレート制限をすることができます。
しかし、いくつかの希望があります。スクレイパーは、一貫した形式のサイトのデータに依存しています。あなたがそれをどういうわけかランダム化できれば、それは彼らのスクレーパーを壊すかもしれません。ロードごとにページ要素のIDやクラス名を変更するなどです。しかし、それは多くの作業であり、その価値があるかどうかはわかりません。そしてそれでも、彼らはおそらく十分な献身でそれを回避することができました。
データにアクセスするためのXML APIを提供します。使い方は簡単です。人々があなたのデータを必要とするなら、彼らはそれを手に入れるでしょう、あなたはすべてを尽くすこともできます。
このようにして、機能のサブセットを効果的な方法で提供することができ、少なくともスクレイパーがHTTPリクエストと大量の帯域幅を混乱させないようにします。
次に、データにAPIを使用してもらいたい人を説得するだけです。;)
さて、すべての投稿が言うように、あなたがそれを検索エンジンに優しくしたいなら、ボットは確実にこすることができます。
ただし、いくつかのことを行うことができ、60〜70%のスクレイピングボットに影響を与える可能性があります。
以下のようなチェッカースクリプトを作成します。
特定のIPアドレスのアクセスが非常に速い場合は、数回(5〜10回)のアクセス後に、そのIPアドレス+ブラウザ情報をファイルまたはデータベースに入れます。
(これはバックグラウンドプロセスであり、常に実行されているか、数分後にスケジュールされます。)これらの疑わしいIPアドレスをチェックし続ける別のスクリプトを作成します。
ケース1.ユーザーエージェントがGoogle、Bing、Yahooなどの既知の検索エンジンの場合(グーグルすることでユーザーエージェントの詳細を確認できます)。次に、http://www.iplists.com/を表示する必要があります。このリストとパターンを照合してみてください。そして、それが偽のユーザーエージェントのように思われる場合は、次の訪問時にキャプチャを入力するように依頼してください。(ボットのIPアドレスについてもう少し調査する必要があります。これは達成可能であることを知っています。また、IPアドレスのwhoisを試すこともできます。これは役立つ場合があります。)
ケース2.検索ボットのユーザーエージェントがない場合:次回の訪問時にキャプチャを入力するよう要求するだけです。
遅い答え-そしてこの答えはおそらくあなたが聞きたいものではありません...
私自身はすでに、多数(数十)のさまざまな特殊なデータマイニングスクレイパーを作成しています。(私が「オープンデータ」の哲学を気に入っているからです)。
ここにすでに他の回答の多くのアドバイスがあります- 今私は悪魔の擁護者の役割を果たし、それらの有効性を拡張および/または修正します。
最初:
いくつかの技術的な障壁を使おうとすることは、引き起こされるトラブルの価値がありません:
プレーンHMTL-最も簡単な方法は、明確に定義された構造とCSSクラスを使用して、プレーンHTMLページを解析することです。たとえば、Firebugで要素を検査し、スクレーパーで適切なXpathやCSSパスを使用するだけで十分です。
HTML構造を動的に生成できます。また、CSSクラス名(およびCSS自体も)を動的に生成できます(たとえば、ランダムなクラス名を使用することにより)。
通常のユーザーはあなたを憎むので、すべての応答の構造を変更することはできません。また、スクレーパーではなくメンテナンス(メンテナンス)のトラブルが増えます。XPathまたはCSSパスは、既知のコンテンツからのスクレイピングスクリプトによって自動的に決定できます。
Ajax-最初は少し難しくなりますが、スクレイピングプロセスは何倍もスピードアップします:)-なぜですか?
リクエストとレスポンスを分析するとき、自分のプロキシサーバー(perlで記述)をセットアップするだけで、Firefoxがそれを使用しています。もちろん、それは私自身のプロキシであるため、完全に非表示になっています。ターゲットサーバーは、それを通常のブラウザとして認識します。(したがって、X-Forwarded-forなどのヘッダーはありません)。プロキシログに基づいて、ほとんどの場合、ajaxリクエストの「ロジック」を決定することができます。たとえば、ほとんどのhtmlスクレイピングをスキップして、適切に構造化されたajax応答(主にJSON形式)を使用できます。
つまり、ajaxはあまり役に立ちません...
さらに複雑なのは、多くの パックされたJavaScript関数を使用するページです。
ここでは、2つの基本的な方法を使用できます。
このようなスクレイピングは遅いです(スクレイピングは通常のブラウザと同じように行われます)が、
ユーザエージェントベースのフィルタリングは、まったく助けていません。深刻なデータマイナーはスクレイパーでそれを正しいものに設定します。
ログインが必要 -役に立ちません。それを打つ最も簡単な方法(ログインプロトコルを分析および/またはスクリプト化せずに)は、Mozillaを使用し、Mozreplベースのスクレイパーを実行した後、通常のユーザーとしてサイトにログインするだけです...
覚えておいてください、ログインが必要です匿名ボットのために役立ちますが、あなたのデータをこすりたく誰かに対して助けていません。彼は自分のサイトに通常のユーザーとして登録するだけです。
フレームの使用もあまり効果的ではありません。これは多くのライブムービーサービスで使用されており、打ち負かすことはそれほど難しくありません。フレームは、分析するために必要なHTML / JavaScriptページの1つにすぎません...データに問題がある場合-データマイナーが必要な分析を行います。
IPベースの制限はまったく効果的ではありません-パブリックプロキシサーバーが多すぎます。また、TORもここにあります... :)これは、スクレイピングの速度を低下させません(本当にデータを必要とするユーザーにとって)。
画像に隠されたスクレイピングデータは非常に難しいです。(たとえば、単にデータをサーバー側の画像に変換する)。"tesseract"(OCR)を採用することは何度も役立ちますが、正直なところ、データはスクレイパーにとってトラブルに値するものでなければなりません。(多くの場合、それは価値がありません)。
反対に、ユーザーはこれを嫌います。私自身(スクレイピングを行わない場合でも)は、ページのコンテンツをクリップボードにコピーできないWebサイトが嫌いです(情報が画像に含まれているため、または(愚かなもの)は、カスタムJavascriptイベントを右クリックして結合しようとしているためです。 )
最も難しいのは、Javaアプレットまたはフラッシュを使用するサイトであり、アプレットは安全なhttpsリクエスト自体を内部で使用します。しかし、よく考えてみてください-あなたのiPhoneユーザーはどれほど幸せになるでしょう...;)。したがって、現在それらを使用しているサイトはほとんどありません。私自身、ブラウザのすべてのFlashコンテンツを(通常のブラウジングセッションで)ブロックし、Flashに依存するサイトは使用しません。
あなたのマイルストーンは...かもしれないので、この方法を試すことができます-覚えておいてください-あなたはおそらくあなたのユーザーの一部を失うでしょう。また、一部のSWFファイルはコンパイルできません。;)
Captcha(reCaptchaのような良いもの)は大いに役立ちますが、ユーザーはあなたを嫌います...-音楽アーティストに関する情報を表示するすべてのページで、いくつかのキャプチャを解決する必要があるときに、ユーザーがどのようにあなたを愛するか想像してみてください。
おそらく続行する必要はありません-あなたはすでに絵に入りました。
今あなたがすべきこと:
覚えておいてください:データを非表示にすることは、反対側で通常のユーザーに(友好的な方法で)公開したい場合、ほとんど不可能です。
そう、
いくつかの技術的障壁を使用する前に、よく考えてください。
データマイナーをブロックするのではなく、Webサイトのユーザビリティにさらに努力を加えてください。ユーザーはあなたを愛するでしょう。技術的な障壁に費やされた時間(&エネルギー)は通常価値がありません-より良いウェブサイトを作るために時間を費やす方が良いです...
また、データ泥棒は通常の泥棒とは異なります。
安価な住宅用警報器を購入して、「この家は警察につながっています」という警告を追加すると、多くの泥棒が侵入しようとはしません。彼が間違った動きをしたから-そして彼は刑務所に行く...
だから、あなたはわずか数ドルを投資しますが、泥棒は投資し、多くのリスクを負います。
しかし、データ泥棒にはそのようなリスクはありません。正反対-間違った動きをした場合(たとえば、技術的な障壁の結果としてBUGを導入した場合)、ユーザーを失うことになります。スクレイピングボットが初めて機能しない場合、何も起こりません。データマイナーは別のアプローチを試すか、スクリプトをデバッグします。
この場合、あなたはもっと多くを投資する必要があります-そしてスクレーパーははるかに少ない投資をします。
時間とエネルギーを投資したい場所を考えてください...
PS:英語は私の母国語ではありません-私の壊れた英語を許してください...
技術的な観点から:一度にクエリが多すぎる場合のGoogleの動作をモデル化します。それはそれの多くを停止する必要があります。
法的観点から:公開しているデータは独自のものではないようです。あなたが著作権で保護されていない名前や統計、その他の情報を公開していることを意味します。
この場合、スクレイパーはアーティスト名などの情報を再配布しても著作権を侵害していません。ただし、サイトに著作権で保護されている要素(レイアウトなど)が含まれているため、サイトをメモリに読み込むときに著作権を侵害している可能性があります。
FacebookとPower.comについて読んで、Facebookが画面のスクレイピングを停止するために使用した引数を確認することをお勧めします。あなたが誰かがあなたのウェブサイトをこすることを止めようとすることを試みることができる多くの法的な方法があります。彼らは遠くまで届き、想像力に富むことができます。時々裁判所は議論を買う。時々彼らはしません。
ただし、名前や基本的な統計情報のように著作権で保護されていないパブリックドメイン情報を公開している場合は、自由な発言とオープンデータの名前でそれを許可する必要があります。つまり、Webのすべてです。
初心者のスクレーパーに対して機能する可能性があるもの:
一般的に役立つこと:
役立つが、ユーザーがあなたを嫌うもの:
私は多くのWebスクレイピング を行っており、私が気になることに基づいて、ブログでWebスクレイパーを停止するためのいくつかの手法をまとめました。
これは、ユーザーとスクレイパーの間のトレードオフです。IPを制限したり、CAPTCHAを使用したり、ログインを要求したりすると、スクレイパーにとって困難になります。しかし、これはあなたの本物のユーザーを追い払うこともできます。
最善のオプションは、残念ながらかなり手作業です。IPアドレスのスクレイピングおよび禁止を示していると思われるトラフィックパターンを探します。
あなたが公開サイトについて話しているので、サイト検索エンジンをフレンドリーにすることは、サイトをスクレイピングフレンドリーにすることにもなります。検索エンジンがサイトをクロールしてスクレイピングできる場合、悪意のあるスクレイパーも同様にできます。歩くのにいい線です。
もちろん可能です。100%成功させるには、サイトをオフラインにします。
実際には、スクレイピングを少し難しくするいくつかのことを実行できます。Googleは、ユーザーが検索結果をこするロボットではないことを確認するためにブラウザチェックを行います(ただし、これは他のほとんどすべてと同様に、なりすましの可能性があります)。
あなたのサイトへの最初の接続とその後のクリックとの間に数秒を必要とするようなことをすることができます。理想的な時間とはどういうものなのか、正確にどうするのかはわかりませんが、それは別の考えです。
他にも多くの経験を持つ人がいると思いますが、それらのアイデアが少なくともある程度役立つことを願っています。
画面のスクレイピングを防止するためにできることはいくつかあります。一部はあまり効果的ではありませんが、その他(CAPTCHA)は効果的ですが、ユーザビリティを妨げます。検索エンジンのインデックスなど、正当なサイトスクレイパーを妨害する可能性があることにも注意してください。
ただし、スクレイピングを望まない場合は、検索エンジンでインデックスを作成しないようにする必要があると思います。
ここにあなたが試すことができるいくつかのものがあります:
これを行う必要がある場合は、最後の3つを組み合わせて使用することになります。これにより、正当なユーザーの不便が最小限に抑えられます。ただし、この方法で全員をブロックすることはできず、誰かがそれを回避する方法を見つけたら、彼らはそれを永久に削ることができることを受け入れる必要があります。それから、私が推測するとおり、それらのIPアドレスをブロックしてみてください。
方法1(小規模サイトのみ):
暗号化/エンコードされたデータを提供します。
私はpython(urllib、requests、beautifulSoupなど...)を使用してWebを記録し、暗号化方式が存在しないためにどのプログラミング言語でも復号化できない暗号化/エンコードされたデータを提供する多くのWebサイトを見つけました。
PHPのWebサイトで、出力を暗号化して最小化することでこれを実現しました(警告:これは大規模なサイトには適していません)応答は常にごちゃごちゃしたコンテンツでした。
PHPでの出力を最小限に抑える例(phpページのhtml出力を縮小する方法は?):
<?php
function sanitize_output($buffer) {
$search = array(
'/\>[^\S ]+/s', // strip whitespaces after tags, except space
'/[^\S ]+\</s', // strip whitespaces before tags, except space
'/(\s)+/s' // shorten multiple whitespace sequences
);
$replace = array('>', '<', '\\1');
$buffer = preg_replace($search, $replace, $buffer);
return $buffer;
}
ob_start("sanitize_output");
?>
方法2:
止められない場合は、それらをねじ込んで、偽/無用なデータを応答として提供します。
方法3:
一般的なスクレイピングユーザーエージェントをブロックします。ユーザーエージェントとして "python3.4"を使用してスクレイピングすることは不可能であるため、主要な/大規模なWebサイトでこれを確認できます。
方法4:
すべてのユーザーヘッダーが有効であることを確認します。スクレイパーを本物のユーザーのように見せるために、可能な限り多くのヘッダーを提供することがあります。それらの一部は、en-FUのように真実でも有効でもありません:)。
以下は、私が一般的に提供するいくつかのヘッダーのリストです。
headers = {
"Requested-URI": "/example",
"Request-Method": "GET",
"Remote-IP-Address": "656.787.909.121",
"Remote-IP-Port": "69696",
"Protocol-version": "HTTP/1.1",
"Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
"Accept-Encoding": "gzip,deflate",
"Accept-Language": "en-FU,en;q=0.8",
"Cache-Control": "max-age=0",
"Connection": "keep-alive",
"Dnt": "1",
"Host": "http://example.com",
"Referer": "http://example.com",
"Upgrade-Insecure-Requests": "1",
"User-Agent": "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.111 Safari/537.36"
}
これへの迅速なアプローチは、ブービー/ボットトラップを設定することです。
特定の時間だけ開かれたり、まったく開かれたりしても、IPなどの特定の情報が収集されるページを作成します(不規則性やパターンを考慮することもできますが、このページを開く必要はありません)。
CSS display:none;で非表示になっているページに、このリンクを作成します。または左:-9999px; 位置:絶対; ボットがページの特定の部分を忘れることを選択できる場合があるため、コンテンツがフッターではなく該当するような、無視される可能性が低い場所に配置してください。
robots.txtファイルで、フレンドリーボットに情報を収集させてこのページの1つとして設定してほしくないボット(笑)にしたくないページに、一連の禁止ルールを設定します。
友好的なボットがやってきた場合、そのページは無視する必要があります。そうです、それでもまだ十分ではありません。これらのページをさらにいくつか作成するか、別の名前を受け入れるようにページを再ルーティングしてください。その後、robots.txtファイル内のこれらのトラップページに、無視するページとともに、禁止ルールを追加します。
これらのボットまたはこれらのページに侵入する人のIPを収集し、禁止するのではなく、乱数、著作権表示、特定のテキスト文字列、怖い画像、基本的には邪魔になるものなど、ヌードルテキストをコンテンツに表示する機能を作成します良い内容。読み込みに時間がかかるページを指すリンクを設定することもできます。PHPでは、sleep()関数を使用できます。一部の適切に記述されたボットが一度にX個のリンクを処理するように設定されているため、ロードに時間がかかり過ぎるページをバイパスする何らかの検出がある場合、これはクローラーとの戦いになります。
特定のテキスト文字列/文を作成した場合、なぜお気に入りの検索エンジンにアクセスして検索しないと、コンテンツが最終的にどこにあるのかがわかる場合があります。
とにかく、あなたが戦術的にそして創造的に考えるならば、これは良い出発点であるかもしれません。最善の方法は、ボットのしくみを学ぶことです。
一部のIDを詐取したり、ページ要素の属性を表示する方法についても考えます。
<a class="someclass" href="../xyz/abc" rel="nofollow" title="sometitle">
一部のボットは、ページまたはターゲット要素の特定のパターンを探すように設定されている可能性があるため、その形は毎回変化します。
<a title="sometitle" href="../xyz/abc" rel="nofollow" class="someclass">
id="p-12802" > id="p-00392"
通常の画面スクレイピングを停止することはできません。良くも悪くも、それはウェブの性質です。
登録ユーザーとしてログインしていない限り、誰もが(音楽ファイルを含む)特定のものにアクセスできないようにすることができます。Apacheで行うことはそれほど難しくありません。IISでも同様に難しいことではないと思います。
1つの方法は、コンテンツをXML属性、URLエンコードされた文字列、HTMLエンコードされたJSONでフォーマット済みのテキスト、またはデータURIとして提供し、それをクライアントでHTMLに変換することです。これを行ういくつかのサイトを次に示します。
Skechers:XML
<document
filename=""
height=""
width=""
title="SKECHERS"
linkType=""
linkUrl=""
imageMap=""
href="http://www.bobsfromskechers.com"
alt="BOBS from Skechers"
title="BOBS from Skechers"
/>
Chromeウェブストア:JSON
<script type="text/javascript" src="https://apis.google.com/js/plusone.js">{"lang": "en", "parsetags": "explicit"}</script>
Bing News:データURL
<script type="text/javascript">
//<![CDATA[
(function()
{
var x;x=_ge('emb7');
if(x)
{
x.src='data:image/jpeg;base64,/*...*/';
}
}() )
unescape('Rolling%20Stone%20%3a%20Rock%20and%20Roll%20Daily')
TiddlyWiki:HTMLエンティティ+整形済みJSON
<pre>
{"tiddlers":
{
"GettingStarted":
{
"title": "GettingStarted",
"text": "Welcome to TiddlyWiki,
}
}
}
</pre>
Amazon:遅延読み込み
amzn.copilot.jQuery=i;amzn.copilot.jQuery(document).ready(function(){d(b);f(c,function() {amzn.copilot.setup({serviceEndPoint:h.vipUrl,isContinuedSession:true})})})},f=function(i,h){var j=document.createElement("script");j.type="text/javascript";j.src=i;j.async=true;j.onload=h;a.appendChild(j)},d=function(h){var i=document.createElement("link");i.type="text/css";i.rel="stylesheet";i.href=h;a.appendChild(i)}})();
amzn.copilot.checkCoPilotSession({jsUrl : 'http://z-ecx.images-amazon.com/images/G/01/browser-scripts/cs-copilot-customer-js/cs-copilot-customer-js-min-1875890922._V1_.js', cssUrl : 'http://z-ecx.images-amazon.com/images/G/01/browser-scripts/cs-copilot-customer-css/cs-copilot-customer-css-min-2367001420._V1_.css', vipUrl : 'https://copilot.amazon.com'
XMLCalabash:名前空間付きXML +カスタムMIMEタイプ+カスタムファイル拡張子
<p:declare-step type="pxp:zip">
<p:input port="source" sequence="true" primary="true"/>
<p:input port="manifest"/>
<p:output port="result"/>
<p:option name="href" required="true" cx:type="xsd:anyURI"/>
<p:option name="compression-method" cx:type="stored|deflated"/>
<p:option name="compression-level" cx:type="smallest|fastest|default|huffman|none"/>
<p:option name="command" select="'update'" cx:type="update|freshen|create|delete"/>
</p:declare-step>
上記のいずれかでソースを表示すると、スクレイピングはメタデータとナビゲーションを返すだけです。
ほとんどはすでに述べられていますが、CloudFlare保護を検討しましたか?私はこれを意味します:
他の会社もおそらくこれを行うでしょう、私が知っているのはCloudFlareだけです。
それは彼らの仕事を複雑にするだろうと私はかなり確信している。レート制限のためにCloudFlareで保護されたサイトのデータをスクラップしようとしたときに、4か月間IPが自動的に禁止されたこともありました(単純なAJAX要求ループを使用しました)。
良い例を見たい場合は、http://www.bkstr.com/をチェックしてください。それらは、j / sアルゴリズムを使用してCookieを設定してから、ページをリロードして、Cookieを使用してリクエストがブラウザー内で実行されていることを検証できるようにします。スクレイピング用に構築されたデスクトップアプリは間違いなくこれでうまくいきますが、ほとんどのcURLタイプのスクレイピングは停止します。
スクリーンスクレイパーは、HTMLを処理することによって機能します。そして、彼らがあなたのデータを取得すると決心した場合、人間の眼球は何かを処理するため、技術的にできることは多くありません。法的にはすでに指摘されていますが、何らかの助言があるかもしれません。それが私の推奨事項です。
ただし、HTMLベースではないプレゼンテーションロジックを使用して、データの重要な部分を非表示にすることができます
これはおそらく検索ランキングに影響することを覚えておいてください。
HTML、CSS、JavaScriptを生成します。パーサーよりもジェネレータを書く方が簡単なので、提供される各ページを別々に生成できます。すると、キャッシュや静的コンテンツを使用できなくなります。