クローラーのわかりやすい入門 基礎理論（前編）_html/css_WEB-ITnose

著作権声明: この記事は Zhuge io Kong Miao から転載されたものです。転載する必要がある場合は、Tingyun College チームのメンバーである Ruan Xiaoyi までメールでご連絡ください: ruanqy#tingyun.com

クローラーの内容について 2つの記事と6つのパートに分けて共有します。

1. 目的は何ですか

2. コンテンツのソースはどこですか?

3. ネットワーク リクエストについて学習してください

4. いくつかの一般的な制限方法

5. 問題を解決してみます

6. 効率の問題

この記事では、まず最初の 3 つの部分について説明します。

1. 私たちの目的は何ですか

一般的に言えば、私たちがクロールする必要があるのは、Web サイトまたはアプリケーションのコンテンツであり、そのコンテンツは通常、次の 2 つの部分に分けられます。非構造化テキストまたは構造化テキスト。

1. 非構造化データについて

1.1 HTML テキスト (JavaScript コードを含む)

HTML テキストは、基本的に従来のクローラー プロセスで最も一般的な、つまり大部分のWeb ページをクロールして HTML を取得するなどの状況に遭遇し、その後、いくつかの共通要素を解析して重要な情報を抽出する必要があるとき。 HTML は実際には構造化されたテキスト編成であるはずですが、必要な重要な情報は通常は直接入手できず、HTML の解析と検索、さらには一部の文字列操作が必要なため、依然として非構造化データとして分類されます。

一般的な解析方法は次のとおりです。

• CSS セレクター

現在、Web ページのスタイルは多数あるため、一般的なWeb ページには、クラス、ID などのいくつかの CSS 配置が存在します。または、Tencent のホームページの財務セクションなど、共通のノード パスに基づいて配置することもできます。

ここでは、 ID は Finance です。CSS を使用します。セレクターは「#finance」で、財務領域の HTML を取得します。同様に、特定の CSS セレクターに基づいて他のコンテンツを取得できます。

• XPATH

XPATH はページ要素のパス選択メソッドであり、次のような chrome を使用してすばやく取得できます。

XPATH をコピーして取得します——//*[@id="finance"]

• 正規表現

標準の正規表現で解析された正規表現は、通常、HTML を通常のテキストとして扱い、指定された形式を使用して関連するテキストと一致します。これは、テキストの小さな断片、特定の文字列、または JavaScript コードを含む HTML には適していますが、これはできません。 CSS セレクターまたは XPATH とともに使用されます。

• 文字列の分離

正規表現と同じですが、より怠惰な方法であり、推奨されません。

1.2 テキスト

例えば、記事や文章など、本来の目的は有効な情報を抽出することなので、処理が遅れた場合は直接保存することができます。有用な情報をリアルタイムに抽出するために必要な一般的な処理方法は次のとおりです:

• 単語分割

クロールされた Web サイトの種類に応じて、基本的な単語の分割に別の辞書を使用してから変更します。 単語頻度統計はベクトルの表現に似ており、単語が方向、単語頻度が長さになります。

NLP

自然言語処理、意味分析、肯定的または否定的などの結果の表現など。

2. 構造化データについて

構造化データは、一般に JSON 形式に似た文字列であり、JSON フィールドを直接解析するだけで十分です。

2. コンテンツはどこから来たのか

以前は、取得する必要のあるコンテンツは主に Web ページから取得することが多かったです。一般的に、クロールしようと決めたときは、すべて Web でした。しかし、近年のモバイル インターネットの発展に伴い、モバイル アプリからのコンテンツがますます増えていることもわかりました。そのため、クローラーは Web ページのクロールと解析に限定されず、モバイル アプリのネットワーク リクエストのクロールもシミュレートします。この部分については 2 回に分けて説明します。

1 Web ページのコンテンツ

Web ページのコンテンツは通常、Web ページ上で最終的に表示されるコンテンツを指しますが、このプロセスは Web のコードにコンテンツを直接組み込むほど単純ではありません。

Chrome または Firefox を使用してページ上の要素を検査すると、HTML タグの下にコンテンツがあることがわかりますが、クロール時は空です。

多くのコンテンツは、ボタンをクリックするか、ページ上でインタラクティブな操作を実行することによって表示する必要があります。

つまり、多くの初心者がやっているのは、特定の言語のライブラリを使用してブラウザの動作をシミュレートすることですが、実際には、ローカル ブラウザを呼び出すか、JavaScript を実行してデータをキャプチャするエンジンを組み込むことになります。大量のデータをクロールする場合、これは非常に非効率であり、技術者にとっては、このコンテンツは Web ページにどのように表示されるのでしょうか。これは主に次の状況に分類されます。

• Web ページにコンテンツが含まれています

一般的には、この状況が最も解決しやすいです。基本的に、静的 Web ページまたは動的 Web ページのハードコードされたコンテンツは、テンプレートを使用してレンダリングされます。ブラウザーが HTML を取得すると、HTML にはすべての重要な情報がすでに含まれているため、Web ページ上に直接表示されるコンテンツは特定の方法で取得できます。 HTML タグ

• JavaScript コードがコンテンツを読み込みます

この状況は、Web ページが表示されるときにコンテンツが HTML タグ内にあるにもかかわらず、実際にはタグに追加するjsコードの実行によるものなので、この時点では内容はjsコード内にあり、jsの実行はブラウザ側の操作となるため、プログラムを使用してリクエストを行うと、 Web ページのアドレスを入力すると、返される応答は Web ページのコードと JS コードであるため、ブラウザ側で内容が表示されます。解析中に js は実行されないため、指定された HTML タグの下のコンテンツが見つかる必要があります。現時点での解決策は、通常、コンテンツを含む js コード文字列を検索し、HTML タグを解析する代わりに正規表現メソッドを使用して表現し、対応するコンテンツを取得することです。

• Ajax 非同期リクエスト

この状況は現在、特にコンテンツがページ分割された形式で Web ページに表示されている場合に非常に一般的です。ページ 更新されないか、Web ページ上で対話型操作を実行した後にコンテンツが取得されます。では、これらのリクエストをどのように分析すればよいのでしょうか?ここでは、Chrome の操作を例として説明します:

したがって、ページの更新を開始したら、すべてのリクエストの追跡を開始し、データがどのステップでロードされるかを観察する必要があります。 。その後、コアの非同期リクエストを見つけたら、この非同期リクエストをクロールするだけで済みます。元の Web ページに有用な情報がない場合は、元の Web ページをクロールする必要はありません。

2 アプリのコンテンツ

現在、モバイル アプリケーションが増えているため、アプリには多くの有用な情報が含まれています。また、非構造化テキストと構造化テキストの解析を比較すると、構造化テキストの方が便利です。ウェブサイトとアプリの両方を持っている場合は、ほとんどの場合、基本的には JSON の API だけをクロールすることをお勧めします。データ。では、アプリデータをキャプチャするにはどうすればよいでしょうか?一般的な方法はパケットをキャプチャすることです。基本的な方法は、コンピュータにパケット キャプチャ ソフトウェアをインストールし、ポートを設定してから、携帯電話とコンピュータを同じ LAN 内に置き、IP を設定することです。このとき、携帯電話のネットワーク接続でプロキシを開くと、アプリがいくつかの操作を実行し、ネットワーク データ リクエストがある場合は、上記のネットワーク リクエストを分析する Chrome と同様に、パケット キャプチャ ソフトウェアによって記録されます。すべてのリクエスト状況を確認し、リクエスト操作をシミュレートします。ここでは、Mac の場合は Charles、Windows の場合は Fiddler2 というソフトウェアをお勧めします。

使用方法については後ほど詳しく説明しますが、これには HTTPS 証明書の問題が関係する可能性があります。

3. ネットワーク リクエストを理解する

リクエストについては簡単に触れただけですが、リクエストは以下を含む非常に重要な部分です。制限を回避する方法、正しいデータを送信する方法、すべてに適切なリクエストが必要です。ここでは、リクエストとそのシミュレーション方法について詳しく説明します。

クローラーは実際には HTTP リクエストの束であるとよく言われます。Web ページのリンクであっても、アプリでパケットをキャプチャして取得した API リンクであっても、クロールされるリンクを見つけて送信します。リクエスト パケットとリターン パケットの取得 (ここでは HTTP 長い接続やストリーミングも考慮されていません)。したがって、コア要素は次のとおりです:

1) URL

2) リクエスト メソッド (POST、GET)

3) パケット ヘッダーをリクエスト

4) パケット コンテンツをリクエスト

5) パケット ヘッダーを返す

Chrome を使用してネットワーク リクエストをキャプチャする場合、またはパケット キャプチャを使用する場合リクエストを分析するツール 最も重要なことは、URL、リクエスト メソッド、およびヘッダー内のフィールドを理解することです。また、最も一般的に制限されるフィールドは、User-Agent、Referer、および Cookie です。 Auth はヘッダーにも追加されました。

リクエストの内容は、投稿時に送信する必要があるデータです。一般に、Key-Value は URL エンコードされます。

返されるパッケージのヘッダーのほとんどは無視されます。しかし、実際には、URL、リクエスト メソッド、リクエスト パッケージのコンテンツがすべて正しいにもかかわらず、コンテンツが返されない、またはリクエストが制限されているのは、おそらく 2 つの理由であることがよくあります。 :

• 1 つは、返されたパッケージのコンテンツが空であるが、返されたパッケージのヘッダー フィールドに Location があるため、この Location フィールドがブラウザーにリダイレクトを指示するため、コードがリダイレクトされない場合があります。当然、コンテンツはありません。

• もう 1 つの問題は、多くの人が頭を悩ませている Cookie の問題です。簡単に言うと、これがブラウザがあなたのリクエストを認識する理由です。実際、前のリクエストの戻りパケットのヘッダーに Set-Cookie というフィールドがある可能性があります。Cookie は、一度設定されると、有効期限が切れない限り、通常はローカルに保存されます。リクエスト フィールドに自動的に追加されるため、Set-Cookie のコンテンツによって、ブラウザがそれを保存する期間、どのようなコンテンツが保存され、どのパスで使用されるかがわかります。Cookie はすべて指定されたドメインの下にあり、通常は交差しません。ドメインは、要求したリンク ホストです。

したがって、リクエストを分析するときは、最初の 4 つに必ず注意を払い、シミュレーション中に一貫性を保ち、5 番目が返されたときに制限やリダイレクトがあるかどうかを観察してください。

さらに技術的な記事を読みたい場合は、Tingyun Technology Blog にアクセスし、Tingyun 公式 Web サイトにアクセスして、アプリケーションのパフォーマンス最適化の魔法をさらに体験してください。