単にそのままzipに入れればいいんじゃん

昨日のMHTMLの話の続きで、要するにページを保存するときに、関連する複数のファイルを保存したい&URLをメタデータとして持っておきたいということだと思った。

これだけだったらzipやtarでファイル名が入る領域にURLの文字列を入れればいいだけだ。zipならアーカイブの中のファイル毎にコメントがつけられる領域があるから、コメントの部分にHTTPヘッダを生で保存すりゃいい。というわけでPythonで書いてみた。さすがにファイル名がURLだとWindowsでもLinuxでも開けない。展開すると…しないほうがいいって感じになる。普通のunzipとかじゃなくて、自分で書いたので展開していく必要がある。だってディレクトリのような名前でファイルのデータが入ってたりするし、Windowsの場合はそれ以前にファイル名が「http://」ではじまってしまうのを処理できてなかった。LinuxのunzipとかFileRollerの場合はhttp://はどうにか「http:」というディレクトリということで処理してくれたけど、やはりいまいちな感じ。

というわけでZipについて書いてみたり、mhtの猛烈に遅いCGIインタフェースを書いてみたのはいいんだけど(ちなみに昨日恥ずかしげもなく上げたmht.pyはforwardされる場合とかにけっこうバグります)、やっぱりMHTMLとZIPとtarと…というのをいろいろ組み合わせて、共通する部分は共通化したほうがいいと思うので、どういう構成にするかちょっと悩みはじめたよ。URLとリンク追跡とかの部分と、共通インタフェースを持ったアーカイブファイルの部分で階層に分けて、主をURLのほうに置けばいいのかなぁ。主をアーカイブのほうにしたほうがいいのかな。いや今回の主はURLのほうだ。

アーカイブの共通インタフェースはPythonの場合は標準ライブラリにZipFileとTarFileがあるから、ある程度は規定できる。あとは展開やCGIインタフェースのほうもURLが主のほうがやりやすいなぁ。mafみたいに特定の名前のファイルをRDFとして入れて使うか、先頭にあるファイルがメインのファイルだなんとな〜く思うか、というあたりも含めて。フォーマットの変換は簡単にできるようにしとかないと後で嫌になるだろうし。どうしようかな。この程度の話で眉間に皺を寄せて上げてFactoryMethodがどうの、とか言いだしそうな自分が恐いが。

なんでこんなこと言ってるかっていうと、やはり見たページは全部保管して後で処理したいなぁ、という思いが強くなってきたからだ。いわゆる個人用web.archive.org。「昔見たんだよなぁ」というページを全部保管してあって検索できるので至極便利、と言えるはずだ、よね。そのための要素がまだけっこう足りてないなぁ、と思っている。Webページ単位で、URLやヘッダ情報なんかも含めて元のファイルを完全に復元できる&普通にローカルだけで見られるように加工して復元できる、という状態のアーカイブがあるのがいいと思う。コメントをつけられるとさらにいいかも。

「個人用web.archive.org」は意外と悲願だったりする。記憶領域があれば、「見たTV番組は全部保存しておく」とかもあってほしい。TV番組とかはどうせ見てない番組までオンデマンドでいつでもどこでも見られるようになる…はずだったんだけどな。世の中ってのはなかなか便利にならない。

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です