結局、画像を画面の付属物とみなしたり、複数のURLを一つのサイトとして扱う UI を持ったアンテナが必要なんだな。逆に言うとたったそれだけの話だった。オリジナリティとビジュアルに拘る人々も大満足アンド大簡単で RSS 強制出力な CMS が大出現しない限り、まだまだアンテナは必要だと思う。
自分は最近(2) に似た仕組みでチェックしてるけど、いい加減人任せにしたい。最近購読数も増えてきたし。
***
前時代的 Web サイトの中でも特に厄介なサイトが多い、オタサイト(※)更新検知(※)でいつも困っているので、上手くやる方法についてぼんやりしたメモ。状況的には数年変わっていないので、今更な話だけど。
※見栄えに拘るタイプの趣味のサイトと言う程度の意味。特定のクラスタやジャンルを指す物ではない。
※見栄えに拘っているので複雑なサイトが多い(正しく拘るのであればそうはならないと言う突っ込みはさて置き)
例として以下のようなフレーム構成のサイトがあったとする。

通常の場合、静的サイトであれば、この画面の URL をアンテナなり WWWC なりに食わせれば良いが、フレーム構成であるため、そのまま登録する事は出来ない。
一般的な感覚で言って、中段のフレームを登録すれば良いように思われるがさにあらず。何故かと言うと、中段を更新せず、各メニューフレームに new と書いたりする場合も多い。
では、上下段フレームの内容もあわせてチェックすれば良いかと言うと、コレもダメ。何故かと言うと、フレームの HTML の内容を変化させずに、メニューアイコンその物を同ファイル名のまま差し替えて、画像内に new など付与する場合がある為。
結局、これは中段も同様で、扉絵内でイベント告知が行われたりする。動画でこのパターンはまだ見たことが無いが、flash ならありえる。
と言うかフレーム分けされていなくても、これらの問題は発生する。
#恐らく HTML を触りたくないのだろう。気持ちは解る。単に HTML 忌避というより、素人レベルの観点で結構込み入った状態になっている場合も多いし。
運良く、判別出来たとしても…恐怖の「さいとりにゅーある」がある。しかもやる人はかなり頻繁にやったりする。更新通知 URL は変化させないでねとか、そう言った理屈は通用しない。て言うかリニューアル以外でも結構気まぐれに変化する。彼らからしてみれば、人間の目で判別出来れば問題無いので、その辺のフットワークは軽い。信用できる URL はサイトトップのみであり、中段も下段も糞も無い。
と言う訳で、こう言う場合、アンテナなりWWWCのような更新チェッカを使う事は出来ない。というか難しい。あるいは気持ちよく使う事が出来ない。
こう言う場合の解法は…
1.毎日サイトの HTML を全て DL して、全てのファイルの更新日時を調査する。
HTML が変化しない場合でも、画像が変化する場合があるので、HTML の全取得と、画像の更新日時の保存が最低限必須になる。
現状存在する当該サイトの全ての URL を記録して、毎回全てに HEAD リクエストして、HTML が更新された場合、リンク追跡を再度行い、URL のリストを更新する。という、ちょっと賢めのサイト一括ダウンローダーがあれば取得自体は可能(画像の更新日時”のみ”を記録してくれるような物は無いので、お任せにすると、本当に全取得になってしまうけど…)
後は更新があった物のみアクセスする仕組みがあればよい。ログから引っぱってHTMLにするか。
2.彼らが実質トップだと思っている画面のみ保存してチェックする
(1)に比べて軽くなる。最深部がこっそり変化した場合や、”実質トップ”が複数存在する場合に追いきれない。また”実質トップ”の見極めミスも発生する。
上記二つとも、ファイルの更新日時なり、ログからの更新日時の抽出が必要になってくる。カウンターの除外処理も必要。
メニュー画像等が更新された場合に、該当するリンク先が何処か探す必要がある。画像が更新された場合は、画像が属する画面が更新された物として扱い、利用する側の UI としては、画像の URL ではなく画面の URL が欲しい。
2αは省略。
3.スクリーンショットを利用する
(2)の発展系
トップページのスクリーンショットを、毎日同じ条件で取得し、保存した画像ファイルの変化の有無で検知する。例えば差分が発生したスクリーンショットを混ぜ込んだ RSS などを自動生成すれば、LDR などで閲覧するにも中々快適かも知れない。
器械には激しく優しくないサイトたちでも、人間の目にはそれなりに配慮しており、アタリのURLさえチェックしておけば、概ねチェック漏れも無い。今風の真っ当な感覚では予測不能な飛び道具が来た場合にも対応可能。
この場合の手間は、自動的にスクリーンショットを取得する事と、カウンターと動画の除外処理となる。昨今流行のスクリーンショット系 API はキャッシュを噛ませている為、更新検知には利用出来ない。windows であれば url2bmp あたりが利用できそう(試してない)。あるいは操作記憶型マクロなどでも良いし、Linux の場合は、シェルからのブラウザ起動と import コマンドなど。
その後、取得画像をImageMagickなりで、動画とカウンタ領域を塗りつぶす。操作記憶可能な画像編集アプリがあるならそれでも良い。もう少し手間を省くなら、除外領域の塗りつぶしの仕組みの代わりに、取得時に URL フィルタでも掛けておけばよい。Proxomitron なり adblock なり polipo なり、あるいはファイルに落とした後に置換処理するなり。
この方法であれば、対象 URL と除外領域の情報のみで更新チェックが可能になる。精度は(2)と変わらないので、手間掛けすぎのような気もするけど、プログラムする場合、取得部分はブラウザに一任できるのと、更新検知は画像のみ扱えばよいので、扱う情報の種類は減るのでちっちゃくなるかも。



そういうサイトチェックしてるんだ…してないと思ってたよ。
巡回対象先教えれ(ぉ
コメント by kyo_ju — 2008/9/5 金曜日 @ 0:51:14
いや人形関係ばっかりだから、興味なさそうだし、サイト自体は google で出てくる所ばかりだよ。サイトコンテンツよりも、リアル活動の検知が主目的(にならざるを得ないサイト運営方針だったり…)だし。
他のアート物も幾らか入ってるけど、基本tumblrに一度は貼った物ばかり。
だから萌え画像はありませんw
コメント by staki — 2008/9/5 金曜日 @ 1:58:20
ただでも『全部公開したい欲』にコレも該当するので、どうにかして web 化できないかなとは思ってるんだけど。
コメント by staki — 2008/9/5 金曜日 @ 2:02:29