Webアーカイブの開発のトピックについて少し

Webアーカイブは、サイト（またはサイトの一部）を元の形式で定期的に保存するシステムです。 ほとんどの場合、これは後世のために行われるため、「再生、クリック、 ノスタルジア 」が可能になります。



Webアーカイブの基本的な要件は、シンプルで包括的なものに思えます。

サイトのオフラインバージョンは完全に機能する必要があります。 すべての元の画像、Flashアニメーション、埋め込みビデオ、スクリプトなどがそこに表示されるはずです。 理想的には、元のものと異なるものであってはなりません。

開発者にとって、「フル機能のオフラインバージョン」という表現は非常に疑わしいものです。 あなたはそれが皮肉に聞こえると言うことさえできます。 結局のところ、最新のサイトはスクリプトなしでは存在せず、スクリプトは常に動作の不確実性を生み出します。 しかし、あるキャラクターが「結論に急ぐ必要はありません。そうしないと、結論があなたを攻撃します。」と言います。

マテリエル

正直なところ、オープンソースの情報を読み直さないでください。 ウィキペディアの記事から始めることができます 。 残念ながら、そこには多くの実装はありませんが、組織的および法的問題についてはさらに多くのことが言われています。



興味のある人のために-読むことをお勧めします。 残りについては、一般的な開発に関するいくつかの用語を示します。



Webアーカイブ 。 たとえば、最も重要なインターネットアーカイブはarchive.orgです。 それは使用の 量と複雑さで怖いです。



Webクローラー -リンクをたどって、サイトのページを反復処理できるプログラム。 現在、彼らはたくさん離婚した。 おそらく、訪問者が待っている最も有名なロボットはGoogle Botです。 POCにはABotを使用しました 。



システム全体を構築するにはストレージ、インターフェースなどが必要ですが、残念ながらすべてが1つの記事に収まるわけではありません。 したがって、ここでは最も難しい部分、つまりサイトをクロールしてデータを保存するアルゴリズムについてのみ説明します。

ソリューションアプローチ

アーカイブの問題を解決する方法は明らかだと思います。 サイトはユーザー向けに作成されています。 ユーザーは何をしますか？ ページを開き、必要な情報を記憶し、次のページへのリンクをたどります。



仮想ユーザー（ロボット）を作成して、タスクを少し自動化してみましょう。



ロボットの操作の「履歴」（ハロー、アジャイル）は次のようになります。

ロボットは（ユーザーとして）リンクを介してページからページに移動します。 移行後、ページが保存されます。 ページからフォローできるリンクのリストを作成します。 既に渡されたリンクは無視されます。 未完成-保存など。

それは非常に短く、非常に抽象的に見えます。 設計の最初のステップは常に抽象的であり、それが最初である理由です。 次に、詳細を説明します。

詳細1

最初に、データモデルの基本的な「分割できない」エンティティを自分で決定する必要があります。 それをリソースと呼びましょう。 このように定義します：

リソースとは、リンクからダウンロードできるコンテンツです。

つまり、その主なプロパティは、サーバーが返すリンク（URI）とコンテンツの存在です。 完全を期すために、リソースの説明にメタデータ（タイプ、リンク、最終変更時刻など）を補足する必要があります。 ところで、リソースには他のリソースへのリンクが含まれる場合があります。



この概念に基づいて、クローラーの一般的なアルゴリズムを決定します。

1. 準備：処理のためのキューエントリURI
2. メインループ：キューからリンクを選択する
3. 指定されたリンクでリソースをダウンロードします
4. リソースで何か役に立つものを作る
5. リソースが参照するリソース（参照リソース）を調べる
6. それらをキューに入れる
7. サイクルの開始に移動

一般的に、論理的に見えます。 さらに詳しく説明できます。

詳細2

ステップ0。 準備。

そのため、ロボットはプロセスの最初にあります。サイトへのエントリポイント、いわゆるインデックスページへのリンクのみがあります。 このステップで、ロボットはキューを作成し、エントリポイントへのリンクをそのキューに入れます。



抽象的に言えば、キュ​​ーはロボットのタスクのソースです。 これで、唯一の要素を持つ行は次のようになります。







（注：小さなサイトの処理キューはメモリに保存できますが、大きなサイトの場合はデータベースに保存することをお勧めします。プロセスが途中で中断された場合に備えて）。

最初のステップ。 コンテンツ分析。

処理するキューからリソースを選択します。 （最初の反復では、これがエントリポイントです）。 ページをダウンロードして、参照しているリソースを見つけます。







ここでは、一般的に、すべてが簡単です。 ページはsiteにあります。 ロボットはそれをダウンロードし、リンクのHTMLコンテンツを分析します。 （リンクタイプについては、以下の「リソースのタイプ」を参照してください）。 例には、robots.txt（ロボットは無視します:)、Aboutリンクはabout.html、CSSファイルとJavascriptファイルへのリンク、Youtubeビデオへのリンクのいくつかのリンクが示されています。

第二段階

不要なリソースを除外します。 このために、ロボットは非常に柔軟な構成インターフェイスを提供する必要があります（ほとんどの既存のインターフェイスが提供します）。 たとえば、ロボットは、タイプ、拡張、サイズ、および更新時間でファイルをフィルタリングできる必要があります。 アウトバウンドリンクの場合、ネストの深さも確認する必要があります。 明らかに、リソースが既に何らかのリンクによって処理されている場合は、それに触れてはいけません。



残りの必要なリソースについて、記述構造を作成し、キューに入れます。 この段階の構造は完全に満たされているわけではないことに注意することが重要です。元の（オンライン）リンクのみが示されています。 （つまり、ステップ0の元のエントリポイントと同じです）。







重要：この段階では、「インデックスページ」ページのコンテンツには元のリンクが含まれているため、オフラインバージョンとして使用できません。 処理を完全に完了するには、リンクを置き換える必要があります。リンクはリソースの保存されたオフラインバージョンを指す必要があります。 キューを使用すると、これを簡単に実装できます。インデックスページリンクを更新するタスクをキューの最後に配置する必要があります。 これにより、このタスクの開始までに、参照されたすべてのリソースが処理されます。

第三段階

一般に、これは最初のステップであり、参照されるリソースごとにのみです。 （つまり、アルゴリズムは実装がより単純になります。ここでは、サイクルのステップを展開して、図を単純化します）。 このステップでは、ロボットはキューから次のタスクを取得します（前のステップで追加されたタスクをダウンロードします ）。



次に、リソースがオフラインで使用するために必要な変換を見つけます。 この例では、「埋め込み」ビデオを除くすべてのリソースが単純にダウンロードされます。YouTube経由で特別な方法でダウンロードされ、aviファイルとしてローカルに保存されます。



その後、参照されたリソースのローカル（オフライン）リンクが形成されます。







重要：最初のステップと同様に、リソースごとに発信リンクを識別し、それらを正しくキューに入れる必要があります。







（この例では、CSSファイルはimage.pngを参照しています）。

第4ステップ

参照されたリソース（およびもちろんimage.png）を削除した後のキュー内の次のタスクは、インデックスページのリンクを更新します。 ここでは、htmlページの構造を変更する必要がある場合があります。 たとえば、あるプレーヤーを介してオフラインバージョンのビデオを埋め込みます。

第5ステップ

最初のステップに進み、キューが空になるまで続行します。

拡張性

キューベースのアルゴリズムには1つの欠点があります。リソースは順次処理されるため、最新のサーバーほど高速ではありません。



したがって、並列処理の可能性を考慮する価値があります。 並行性には2つのオプションがあります。

• マクロレベル：複数のクローラーが異なるサイトで並行して動作します
• マイクロレベル：1つのクローラーがリソースを並列処理します

マイクロレベルでは、ロックに関する質問が発生します。 思い出すと、一貫性を保つために「リンクを更新する」タスクはキューの最後に正確に置かれます。 このタスクが開始されるまでに、関連するすべてのリソースがすでにローカルリンクを受信して​​処理されていると予想されます。 並列操作では、この条件に違反するため、同期ポイントを入力する必要があります。 たとえば、単純なオプションは、ダウンロードタスクを非同期的に開始することです。 リンクを更新するタスクが表示されたら、アクティブなダウンロードタスク（いわゆるバリア）の完了を待ちます。 難しいオプションは、セマフォを介してタスク間に明示的に依存関係を導入することです。 まだ深く分析されていないオプションがまだあるかもしれません。

リソースタイプ

明らかに、そのようなクローラーが処理しなければならないあらゆる種類のリソースを予測することは不可能です。 しかし、少なくともどのような困難に直面するかを知るために、私たちは試みます。

• HTMLページ。 最も一般的なタイプのリソース。 非常に簡単に処理できます（HtmlAgilityPackとCsQueryを使用した.netで）。 この種のリソースを参照する場合があります。
  
  
  
  
  • <a>を介した他のページまたはファイル
  • 画像<img>
  • CSSスタイル<link rel = "stylesheet">
  • スクリプト<script>
  • フラッシュアニメーション<オブジェクト>
  • 埋め込みビデオ<object>、<embed>または<iframe>
  • 注 ：システムは、メインコードを変更せずに新しいタイプのリンクとその処理のコンポーネントが追加されるように十分な柔軟性を備えている必要があります（よく知られているオープンクローズ原則）
  
  
  
• CSSスタイル。 そのままダウンロードします。 「url」関数を介して他のリソース（cssおよび画像）を参照できます
• スクリプト。 そのままダウンロードします。 スクリプトからではなく直接リンクを把握することはできません（動的ページの詳細については、以下を参照してください）
• 映像 プロバイダーによって異なる特別なアプローチを使用してダウンロードされます。 どこにも参照しないでください
• Flashアニメーション。 swfファイルとしてダウンロードされます。 他のリソースを参照したり、他のフラッシュファイルをダウンロードしたりすることはできますが、判断はできません。
• 動的リンク。 最初のビュー：結果としてDOM操作が発生し、追加のファイル（イメージ、スクリプト）のダウンロードが必要になります。 2番目のビュー：XHRリクエスト。

動的ページ

ロボットは私に質問をします：「それでも-動的ページ、スクリプトなどについて何を決めたのですか？」 答えは次のとおりです。検証では、すべてのページが等しく「動的」ではないことがわかります。 次のレベルのページダイナミズムを定義します。

• レベル1.古き良きhtmlページ 。 CSSスタイルを使用した静的HTMLコンテンツ。
  
  
• レベル2。スクリプトによって強化されたHTMLコンテンツ 。 ここでは、スクリプトはajaxリクエストを実行せず、サーバーから送信されたコンテンツのみを操作します。 たとえば、テーブルソーターまたはエキスパンダー。
• レベル3.オンロードローダー 。 ページをロードした後、スクリプトは動作を開始し、いくつかの追加コンテンツをロードします。
• レベル4。クライアントアプリケーション 。 ユーザーインターフェイスは、ユーザーアクションに応じて変更されます。 スクリプトはデータを非決定的にロードします。 これが、シングルページアプリケーション、「無限」リスト、スマートエキスパンダーの仕組みです。

ダイナミズムのレベルが高いほど、オフラインコンテンツを維持することが難しくなります。

• レベル1および2-完全に維持され、オフラインでも優れた動作をします。
• レベル3-このようなページを適切に処理する方法は1つしかありません。 これを行うには、ブラウザを（もちろん、プログラムで）起動し、メインページとすべての追加コンテンツが読み込まれるまで待ちます。
  
  
  • 組み込みのブラウザをインストールし、ページをロードします。
  • 元のHTML、スタイル、スクリプト、画像が読み込まれた後。
  • スクリプトは汚い行為をします（HOUSEを変更し、XHRリクエストを行います）。
  • システムは、ページのロード中に発生するすべてのリクエストを監視します。 （簡単な例は、Firebugが行うことです）。
  • すべてのリクエストはリソースリンクと見なされます。 サーバーからの応答はデータベースに記録され、前の部分のアルゴリズムに従って処理されます。
    
    POCの場合、Webkit.Net（git@github.com：webkitdotnet / webkitdotnet.git）を使用しましたが、少し更新する必要がありました。
    
    
    
    
    
    
    
    Firebugと同様に機能しますが、.Netからの違いがあります。
    
    
    
    
  • レベル4。単一ページのアプリケーション。 技術開発のレベルではありません。 そして、なぜ、このようなアプリケーションのオフラインバージョンを保持する必要があるのでしょうか。 SPAは通常、非常に主観的なコンテンツを表示しますが、これはユーザーやその他の多数のパラメーターに依存します。 私個人の意見では、これは必要ではなく、非常に難しい-光より速く飛ぶ方法です。 とにかく、誰も見て、感謝しません。
    
    
    
    しかし、ソリューションを提供することは私の義務です。 やってるよ。 私には2つのオプションさえあります。
    
    
    
    オペレーターのオプション。
    
    
    
    
    • オペレーターは、ブラウザーに特別な拡張機能をインストールします（または、ブラウザー全体を使用します）。
    • ページを最初に読み込んだ後、彼女のHOMEのスナップショットが作成されます。 ロシア語がどうなのか分かりません。 「スナップショット」はなんとなく奇妙に聞こえます。 （彼らは別の「キャスト」を提案します）。
    • ユーザーは、「クリックしてタップ」というアプリケーションの操作を開始します。
    • HOUSEの変更については、何が変更されたかが判断され、HOUSEの次の「フレーム」が保存されます。
    • 結果は一種のハウスアニメーションです。 私たちにとって便利な任意の形式で保存します。
    • アーカイブされたバージョンは読み取り専用になりますが、元のページの機能は送信されます。
    
    
    
    
    機械学習またはスクリプトオプション。 一般に、これは最初のオプションに似ていますが、オペレーターの手順は、さらに自動化された再生のために明示的または暗黙的に記憶されます。 自動分類器やニューラルネットワークを使用することもできます。研究者にとっては、可能性の広大な分野があります。 残念ながら、私たちは研究者ではなく開発者です。 正直なところ、複雑さは評価できません。
    
    
  
  
  
  
  

  おわりに

  
  
  
  
  ロボットに加えて、Webアーカイブシステムには、ストレージ、インデックス作成、およびインターフェイスが含まれている必要があります。意図的にそれらを考慮から除外しました。 第一に、これらのコンポーネントは、ロボットと比較して統合および構成が非常に簡単です。 第二に、気を散らさないためです。
  
  
  
  Webアーカイブシステムは妥当な時間で構築できますが、現代のサイトの動的な性質により制限があります。 第3レベルまでの動的ページは、許容可能なアーカイブに役立ちます。 4番目のレベルでは、多くの労力が必要になります。
  
  
  
  一般に、ロボットを開発するには2つの方法があります。 1つ目は、人工知能の使用です。 クローラーが何をしているかを「理解」できるように、クローラーを開発する必要があります。 2つ目は技術です。 スマートCMSのようなサイト用のプラットフォームを作成する必要があります。 その上で実行されているサイトは、アーカイブ用の単純な形式でロボットのコンテンツを公開できます。