最高の＆＃8220;ファイル形式＆＃8221;単一のアーカイブに完全なWebページ（画像など）を保存するには？ [閉まっている]

Question

私は、タイムカプセルのように1つの場所に単一の画像とテキストファイルを保存するプロジェクトに取り組んでいます。現在、DOC、PPT、ODFなど、ほとんどすべてのプロジェクトを1つのファイルとして保存できます。ただし、完全なWebページはできません-別のHTMLファイルとデータフォルダーとして保存されます。 ウェブページを1つのアーカイブに保存したいのですが、いくつかの解決策がありますが、「標準」はありません。 HTMLアーカイブに最適な形式はどれですか？

• Microsoftには MHTML があります。基本的にはファイルですMIME HTML電子メールメッセージとして正確にエンコードされます。既に既存の標準に基づいており、MHTML自体は rfc2557 として提案されました。これは素晴らしいアイデアであり、「提案された標準」であったことを除いて、永遠に存在し続けています。さらに、IE以外の実装は面倒です。 IEとOperaはそれをサポートしています。面倒な拡張機能を備えたFirefoxおよびSafari。

• Mozillaには Mozillaアーカイブ形式 -基本的に、RDFとしてメタデータが保存されたマークアップと画像を含むZIPファイル。これは素晴らしいアイデアです-Winampはスキンに対してこれを行い、埋め込み画像に対してODFおよびOOXMLを行います。私はこれが大好きです。1を除いて、Mozilla以外は誰も使用していません。2それをサポートする唯一の拡張機能はFirefox 1.5以降更新されていません。

• データURI の人気が高まっています。 MHTMLまたはMAFのような外部の場所を参照する代わりに、ファイルをHTMLマークアップにbase64として直接エンコードします。ファイルはマークアップがある場所に正しいため、ビューに応じて合理化されます。ただし、サポートはまだやや弱いです。 Firefox、Opera、およびSafariは、失言することなくサポートしています。 IEはマーケットリーダーでしたが、IE8でのみサポートを開始し、その後も制限がありました。

• もちろん、＆quot;完全なWebページを保存＆quot; があり、HTMLマークアップは＆quot; savedpage.html＆quot; として保存され、ファイルは別の＆quot; savedpage_files＆quot; フォルダー。 Afaik、誰もがこれを行います。よくサポートされています。しかし、2つの別個の要素を処理する必要があるのは単純ではなく、 all で合理化されています。私のプロジェクトでは、それらを単一のアーカイブに入れる必要があります。

ブラウザのサポートとページの編集の容易さを念頭に置いて、単一のアーカイブにウェブページを保存する最良の方法は何だと思いますか「標準」として最適なものは何ですか？または、HTMLファイルと別のフォルダーを処理して対処する必要がありますか？私のプロジェクトのために、私はそれをサポートすることができます が、私はそれを避けるのがベストです。

Answer 1

私のお気に入りはZIP形式です。理由：

• この目的には非常に適しています
• よく文書化されている
• それらを作成または読み取るための多くの実装があります
• ユーザーは簡単に単一のファイルを抽出し、それらを変更してアーカイブに戻すことができます
• ほとんどすべての主要なオペレーティングシステム（Windows、Mac、およびほとんどのLinux）には、ZIPプログラムが組み込まれています

代替案にはすべていくつかの欠陥があります：

• MHTMlでは、簡単に編集できません。
• データURIの場合、実装がどれほど難しいかわかりません。 （ZIPを使用すると、3年前にPHPでもできました...）
• 別々のファイルとして物事を保存するオプションは、間違って行き過ぎてアーカイブを台無しにする可能性のあるものが多すぎます。

Answer 2

PDFは、ほぼすべてのプラットフォームのほぼすべてのブラウザーでサポートされ、コンテンツと画像を1つのファイルに保存します。適切なツールで編集できます。これはほぼ間違いなく理想的ではありませんが、考慮するオプションです。

Answer 3

ファイル形式の問題だけではありません。別の重要な質問は、正確に何を保存したいですか？それですか：

1. すべての参照リソース（画像、 CSSとjavascript？

2. ある時点でレンダリングされたページをキャプチャします。静的 WebページDOMのレンダリングされた状態の画像？

最新の「ページを名前を付けて保存」ブラウザの機能は、MAF、MHTML、file + dirのいずれであっても、最初の方法を試みます。これは最終的に欠陥のあるアプローチです。

Webページを忘れないでください。日はむしろローカルアプリケーションであり、簡単に保存できる静的なドキュメントです。潜在的な問題：

1. 実際には、1ページはJSによって動的に構築される複数のページであり、ユーザーの操作が必要です 希望する状態にするには

2. AJAXアプリケーションは、それをレンダリングするリモートサービスとリモート通信を行うことができます オフラインビューには使用できません。

3. javascriptコード内の非表示のリンク。そのようなリソースは、保存されたページの一部ではありません。 JSコードを解析しても、それらが検出されない場合があります。コードを実行する必要があります。

4. 基本的なhtml要素の位置も再計算でき、動的に計算できます JSおよびローカルで再作成することは常に可能/簡単ではありません。

5. ページを目的の状態にするには、何らかのJSメモリダンプが必要で、これをロードします 保存したい

さらに多くの問題...

Chrome SingleFile 拡張機能を確認します。既に述べたデータURIを使用してインライン化された画像を含む1つのhtmlファイルにWebページを保存します。私はそれをあまりテストしていないので、「揮発性」をどれだけうまく処理できるかは言えません。 ajaxページ。

Answer 4

zipファイルを使用します。

zipファイルを一時ディレクトリに抽出し、ブラウザにindex.htmlファイルをロードするプログラム/スクリプトをいつでも作成できます。 index.ini / txtファイルを使用して、抽出時にロードするファイルを指定することもできます。

基本的には、Mozilla Archive形式のようなものが必要ですが、ロードするファイルを指定するためだけに不要なrdfが不要です。

MHTファイルは適切ですが、通常base64を使用してファイルを埋め込みます。これにより、ファイルサイズが本来より大きくなります（データURIも同じです）。添付ファイルをバイナリとして追加できますが、16進エディターを使用して手動で追加するか、クライアントによるツールとツールのサポートを作成する必要があります。

もちろん、ブラウザが生成するものを使用したい場合、MHT（少なくともOperaとIE）の方が良いかもしれません。

Answer 5

i zipファイル以外を使用する言い訳はありません

Answer 6

まあ、ブラウザのサポートと編集の容易さが最大の懸念事項である場合、単一のファイル形式のエディタを提供し、ブラウザであまり良くないサポートで生きるつもりがない限り、ファイル+ディレクトリのアプローチに固執していると思います。

コンテンツを圧縮することにより、単一のファイルを作成できます。親ディレクトリを作成して、処理を簡単にすることもできます。

Answer 7

問題は、htmlがトップダウンではなくボトムアップであることです。私のボックスに＆quot; What's the best＆quot; file format＆quot;として保存したファイル名を見てください単一のアーカイブに完全なWebページ（画像など）を保存するには？ -Stack Overflow.html＆quot;

「|」を追加するだけまた、バックアップをコピーしてスペアドライブに貼り付けるのに問題があります。最終的にあなたは終わります。ファイル名を切り取って保存します。数十/おそらく数百の同一のindex.htmlまたはindex.phpが私のドライブを混乱させています。

部分的な解決策は、独自のCMSを記述し、スクリプトを使用してすべての関連ファイルをフラットファイルデータベースにマッピングすることです。次に、fileName、size、mtime、md5を使用して各ファイルの一意のIDを取得します。 100kまたは1000kレコードを許可するフラットファイルインデックスを作成します。目標は、一度書いて何度も使うことです。したがって、files_archiveに含まれるコンテンツ（index8765432.htmlなど）に基づいた一意のIDが必要な実際のCMSが必要です。他の人にも同じ。次に、保存された元のhtmlからfiles_archiveへの非破壊シンボリックリンクを作成し、必要に応じてphpまたは代替スクリプトを使用してファイルを再作成します。私があなたがいるのと同じポイントにいるのでそれが機能するかどうかわからない-たぶん一週間で確実にわかるでしょうより有用なアプローチは、ビジネスまたは個人の要望と関連タスクに基づいてトップダウン構造にすることです。したがって、元のコンテンツを保持するために、ファイルは上から下に編成され、外部ファイルは下から上に編成されます。私の関心はWeb 3.0サービスであり、マシン間の相互作用に近づくほど、情報を構造化する必要性が高まります。たぶん、すべてを1つのファイルにまとめるという考えを再考するときが来たでしょう。したがって、トップダウンソリューションで数百ではなく1つのファイルを変更できる場合に、何百ものmain.cssをバンドルする理由があります。