ハクソク

世界を動かす技術を、日本語で。

Gwtar: 静的効率的な単一ファイルHTMLフォーマット

99日前原文(gwern.net)

概要

Gwtar は、HTMLアーカイブの 三重苦 （静的・単一ファイル・効率性）を同時に解決する新しい 自己完結型HTML形式。 JavaScript による HTTP Rangeリクエスト で必要なアセットのみ遅延読み込みを実現。 Gwern.net で大規模HTMLアーカイブ配布に活用。 自己抽出型HTML＋tarball 構造で将来互換性とサーバー依存排除を両立。 Cloudflare 等の制約やローカル閲覧時の課題も存在。

Gwtar: 静的・単一・効率的なHTMLアーカイブ形式

  • Gwtar は、HTMLアーカイブの 三重苦（trilemma） 「静的（完全自己完結）・単一ファイル・効率的（遅延読み込み）」を全て満たす新形式
  • HTML＋JavaScriptヘッダー の後ろに tarball （オリジナルHTML＋全アセット）を連結した 自己抽出型HTMLファイル 構造
  • ブラウザは最初に ヘッダーのみ取得、 window.stop() で残りのダウンロードを停止
  • ページ内JSが Rangeリクエスト で必要なアセットのみを tarball部分から取得 し、効率的な遅延読み込みを実現
  • サーバー側の特別な設定不要、将来も標準的なWeb技術だけで動作保証

既存形式の三重苦

  • SingleFile 等は「静的・単一ファイル」は達成するが 効率性（遅延読み込み不可） に欠点
  • WARC/MAFF 等は「静的・効率的」だが 単一ファイル ではなく、再生に複雑なソフトが必要
  • 通常のHTML保存 は「単一・効率的」だが 静的性（完全自己完結） が不十分

Gwtarの設計と実装

  • deconstruct_singlefile.php （PHPスクリプト）でSingleFileアーカイブを Gwtar形式に変換
    • 画像圧縮や PAR2 FEC（前方誤り訂正） もオプションで追加可能
  • ヘッダー部 に アセット情報（JSON） やメタデータを格納
  • アセット取得時は blob最適化 でブラウザにバイナリをそのまま渡す
  • JS依存 だが、非対応時は<noscript>で説明文表示・全体ダウンロードへフォールバック

制限と注意点

  • ローカル閲覧 時はCORS等のセキュリティ制約で動作しない場合あり
    • 必要に応じて 通常の複数ファイル形式 へ戻せる
  • Rangeリクエスト 必須。サーバー設定やCDN（例： Cloudflare）の仕様によっては動作しない場合あり
    • MIMEタイプ をx-gwtar等に変更して回避策
  • 圧縮や重複排除 は直接サポートせず。ファイルシステム側や生成時に対応

拡張性・応用

  • バイナリアセット （例：Sqlite3 DB等）も埋め込み可能。科学データの再現性向上
  • 追記データ （署名・FEC等）もtarball後に連結可能
  • GPG署名 や メタデータ の埋め込みにも対応
  • CC-0パブリックドメイン で公開、特許なし

今後の課題

  • ハッシュ検証・バリデーションツール の充実
  • SingleFile 等既存ツールとの統合
  • 圧縮・重複排除・マルチページ対応 等のフォーマット拡張
  • Cloudflare等CDN との互換性向上

HTMLアーカイブ三重苦とGwtarの解決

  • 静的性 ：オリジナルページに依存せず、全アセット内包
  • 単一ファイル ：管理・配布・再ホストが容易
  • 効率性 ：必要なアセットのみ遅延取得、巨大ファイルでもユーザー負担低減

Rangeリクエストとブラウザ互換性

  • HTTP Rangeリクエスト で巨大ファイルから必要部分のみ取得
  • window.stop() でヘッダー以降の自動ダウンロードを停止
  • クロスプラットフォーム・将来互換性 を確保

Cloudflare等CDNとの相性

  • Cloudflare はtext/htmlでのRangeリクエストを遮断するため、 x-gwtar 等のMIMEタイプで回避
  • ブラウザは <html>タグのsniffing で正しく表示可能

バイナリアセット・署名・拡張

  • バイナリアセット の埋め込み・参照方法例（<object>タグ＋JSイベントフック）
  • PAR2 FEC で破損時の復元性向上
  • GPG署名 等の追記も可能

まとめ

  • Gwtar は大規模・長期的なHTMLアーカイブ保存に最適
  • ユーザー・サーバー双方に特別な負担なし で、静的・単一・効率的な配布を実現
  • 将来拡張・他ツールとの連携 も視野に入れた設計

参考文献

  • Gwern.net: Gwtarドキュメント
  • RFC 7233: HTTP Range Requests
  • SingleFile, MAFF, WARC等アーカイブ形式関連情報
  • Cloudflare公式ドキュメント

Hackerたちの意見

今日はwindow.stop()について知ったよ。これがこの全ての仕組みを動かす鍵なんだって。ブラウザがこれ以上のアセットの読み込みを止めるんだ。詳しくはここを見てね: https://developer.mozilla.org/en-US/docs/Web/API/Window/stop どうやら、主要なブラウザは10年以上もこれをサポートしているらしい: https://caniuse.com/mdn-api_window_stop 使い方を示すスクリーンショットもあるよ: https://gist.github.com/simonw/7bf5912f3520a1a9ad294cd747b85... それ以降はここを見て: https://simonwillison.net/2026/Feb/15/gwtar/

└

すごい！これも知らなかった。Phpには__halt_compiler()って似たような機能があって、同じ目的で使ったことがあるよ。ファイルの最後にドキュメントを入れるためだけに使うこともあるし、コメントブロックが必要ないから便利だよね。

└

逆ではないけど、これを見ているSPA（フレームワークやライブラリではなく）開発者には、document.writeやwindow.openなどのAPIを使う方が良いってことを覚えておく価値があるかも。ただ、メインのロジックがサーバーにあって、ダウンロードやレイジーローディングのロジックを手動で実装しようとしている場合には、興味深いかもしれない。でも、初期化やリダイレクトスクリプトに明示的に取り組んでいない限り、やっぱり良くないと思う。

└

これ、Claude Artifactsと互換性あるのかな。自分でアーティファクトを公開できるバンドラー機能を作ったんだけど、https://claude.ai/public/artifacts/a49d53b6-93ee-4891-b5f1-9... 最後は圧縮されたbase64の塊になってるだけなんだよね。次の疑問は、これが単一ファイルを共有できる環境で動くとしたら、人々が使ってるのがバレたらその機能を無効にされるかどうかだね。

作者はWARCを軽視してるけど、なんでだろう。私にはGwtarの方がWARCよりも複雑に見えるし、柔軟性もないし、また新しいフォーマットが増えただけって感じ。

└

WARCのURLをクリックしてブラウザで直接内容を見ることはできないと思うよ。

└

WARCが十分じゃない理由が具体的に挙げられてるね。「WARCs/WACZsは静的で効率的だけど、単一ではない（WARCは単一のファイルだけど、表示するにはWebRecorder/Replay Webpageのような複雑なソフトウェアインストールに依存しているから）。」

最初は賛成だったけど、ローカルファイルから簡単に開けないって分かってがっかりした。ローカルアクセスはアーカイブフォーマットの主な使用ケースの一つだと思うんだけど。

└

同意だね。asm.jsみたいに、デフォルトでサポートされることで「バックドアパイロット」[1]的な面白い使い方ができると思ってた。でも、ローカルでファイルを「ただ」ブラウザに読み込めないのは、かなりのポイントを無駄にしてる気がする。[1] https://en.wikipedia.org/wiki/Television_pilot#Backdoor_pilo...

└

ビューワープログラムで解決できるかな？静的HTMLサーバーとか？

└

つまり、claude -p "このディレクトリでPythonのウェブサーバーを立ち上げてください" か、python -m http.server 8080 --bind 127.0.0.1 --directory . って、そんなに難しくないよね。

└

HTMLはすでに単一ファイルの良いフォーマットだし。画像はdata-uriでインラインにできるし、CSSやJavaScriptも最初からインラインにできてた。何がもっと必要なの？フォント？またdata-uriだよ。ついでに言うと、HTMLはワードプロセッサのアプリが全てを保存すべき形式かもね。ピクセル単位で要素を配置できるし。

いいね！前に似たようなもの（もっとハッキーなやつ）を作ったことがあるよ。https://github.com/AdrianVollmer/Zundler これはローカルで動くけど、最初に全部解凍する必要があるんだよね。

└

これはSingleFileZみたいに、静的で非効率的なHTMLアーカイブってこと？ローカルでも簡単に見れるのかな？どうやってSingleFileZやGwtarのローカルビューイングモードのセキュリティ制限を回避してるの？ちょっと複雑で、どこがトリックなのかついていけてないんだけど、単一オリジンについてはちょっとした詳細（フォーム）しか触れてないよね。

すごくいいアイデアだね。単一ファイルのHTMLウェブアプリは、コンピュータソフトウェアの中で最も耐久性がある形だと思う。俺が書いた単一ファイルウェブアプリの例は、https://fuzzygraph.com と https://hypervault.github.io/ だよ。

SingleFile [1] が生成するZIP/HTMLポリグロット形式が「静的で単一だけど効率的ではない」と記事で言われてる理由を知りたいな。gwtar形式と比べて何が効率的じゃないの？[1] https://github.com/gildas-lormeau/Polyglot-HTML-ZIP-PNG

└

「効率性」っていうのは、現在のビューをレンダリングするために必要なアセットだけをダウンロードすることだよね。どうやってレンジリクエストを実装して、ウェブブラウザがURLをリクエストしたときにSingleFileZ全体をダウンロードしないようにしてるの？

似たようなことを考えたことがあるけど、Service Workerレイヤーでやると、ページがそのままでHTTPリクエストを全てインターセプトできるんだよね。window.stop()アプローチに似てて、リクエストはメインのHTMLファイルを切り詰めて、残りのリクエストはサービスワーカーが提供するアセットのblobになる感じ。サービスワーカーファイルはデータURIにして一つのファイルにまとめられるかも。

面白いけど、ローカルファイルにレイジーロードが必要な理由がちょっと混乱してる。これらのファイルはどれくらいの大きさを想定してるの？（それとも、レイジーローディングはすでにやってることをサポートするためだけなのかな？）

└

アイデアとしては、ローカルじゃないってことだと思う。HTTPサーバー上の非常に大きなファイル（レンジリクエストに必要）で、ネットワーク越しに全部ダウンロードしたくないってわけ。もちろん、HTTPサーバー上にあるから、異なるファイルのリクエストを複数処理するのは簡単だけど、サーバーで管理するのが面倒なこともあるし、単一ファイルの方が楽だよね。もしかして、これはGwernが自分のウェブサイトにMediaWikiを使うことを選んだ流れなのかな？

他に誰かいる？GWAAAR！ - G.W.A.R！ - ここにいるのは多分唯一のメタルオタクだね。