■[PR][]
[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。
めずらしいメールが来た。1980年代のおもちゃを懐かしむ本を制作するらしく、うちのサイトのチョロQのページにある、F14トムキャットの写真を使わせてほしいという依頼だ。こんなことになるとは思ってもいなかったので、載せている画像の質は非常に悪い。
せっかくなので、撮り直したものを使ってもらおうと考えた。F14トムキャットなら、まだ持っているはずだと思って、部屋のあちこちを調べた。ポルシェとかマグナム号はすぐに見つかったのに、目当てのF14がなかなか出てこない。1時間くらいかかって、ようやく見つけた。
で、DIMAGE X20を使って撮影開始。いろんなアングルから、10枚くらい撮った。そのうちの一枚を縮小したのがこれ。
ちょっと暗いかもしれないけど、今まで載せていたのよりはマシ。
実際は、640×480のものを無加工で提供した。メールに添付するのは迷惑だろうから、適当に臨時のページを作って、好きなのをどうぞという感じで。
しっかし、前日まで風邪をひいていて、今日は深夜まで仕事だったというのに、何をしているんだか。
おきらく画廊のページを新しくした。このブログのデザインに近いけれども、中身はWeb Diary Professionalなので、見えないところでの苦労がいろいろある。
ひと月あたりの記事数が少ないので、月別リストを年別リストに改造した。幸い、一年ごとに表示する機能が最初からあったため、リストの表示部分を少しいじるだけで済んだ。それでもリストに10項目あるということは、初期の絵は9年前にもなるわけか。
カテゴリについては、階層を作る機能があるけれど、ちょっとクセのある仕様だったので、単純に作品名だけで分けることにした。すでに30以上のカテゴリになってしまっているのは、特に気にしていない。これで、どんな絵があるのかがわかるし、興味のあるカテゴリの絵を一度に見られるという、ブログ形式の恩恵にあずかることができた。
Web Diary Proには、各記事をHTMLとして出力する機能がある。これによって、CGIファイルや、「?」といった記号をURLに含めずに記事を指定できる。特にhi-hoの場合は、CGIファイルの格納位置が特殊なので、この機能はありがたい。ただ、出力させるHTMLのタグを変更したいときは、すべてのページを再構築する必要がある。ボタンを押すだけではあるけれど、全ファイルの更新になるので、そこそこ時間がかかる。絵の保管が目的だから、記事数が激増することはないだろうということで、この機能を使っている。もし、通常の日記として使うとしたら、ちょっとためらう。同一ディレクトリに記事数と同じ数のファイルが作られるわけだから、何百件もの記事数になると、気分的によろしくない。もっとも、現時点ですでに150件ほどあるのだけど。なお、書き出すHTMLファイルの元になるデータは、ひと月ごとにまとまったファイルで管理しているようだ。
というわけで、管理側の都合はともかく、利用しやすくはなったと思う。時間をかけただけのことはあった。
体調が回復したのかどうか、よくわからないまま、連休が終わった。
何もできずに終わってしまいたくはなかったので、おきらく画廊のページをリニューアルする作業を進めていた。このページは、ただ描いた順に並べられているだけなので、どこにどんな絵があるのか、さっぱりわからないのが問題だ。
これを解決するには、カテゴリでフィルタリングできるブログ形式にしたほうがいいと思った。どうせならCGIでやってみようということで、Web LibertyのWeb Diary Professionalを使ってみることにした。hi-hoはCGIの制約が多くて、設置するのが大変だったが、使えることはわかった。最も苦労したのは、ブログで使っているのと同じようなデザインにすることだ。これに相当な時間を使ってしまった。あれこれとテストをして、どうにか運用できそうかなという感触をつかんだところで休みは終わり。移行する時間が取れなかった。
一番の問題は、ここまでするほどの絵でもないのでは、とか思い始めてしまったことだ。いかんいかん。それはそれとして、せっかくここまで時間をかけたので、Web Diary Professionalのカスタマイズ方法を、忘れないうちにまとめておきたい気分だ。
世界樹の迷宮Wikiから、うちのサイト(T's Square)が世界樹の迷宮絵のあるサイトとしてリンクされていた。喜ばしいことではあるけれど、ちゃんと色を塗っておけばよかったなとも思ったり。
掲示板に書き込みがないのに、更新日時だけ新しくなってしまう現象がよく起こっていた。これでは、自動化している意味がない。
更新日時は、データファイルのタイムスタンプを参照する仕組みにしていた。内容に変更がないのに、タイムスタンプが更新されるケースというのは、書き込み制限に引っかかった場合だろうか。自分で試してみたが、再現しなかったので、実はよくわからない。
回避策として、書き込みが正常に処理されたあと、データファイルとは別のファイルを生成して、そのタイムスタンプを更新日時として使用することにした。これなら、データファイルのタイムスタンプがコロコロ変わっても影響がない。
これはこれで悪くないけれど、どうせならもっと改良しようということで、生成したファイルに書き込み日時の情報を入れて、そこを参照するようにした。こうすると、手動で自由に書き換えることもできる。そして、記事を削除したときには、データファイルの中を参照して、最後の書き込み日時を出力する処理を加えた。これで、常に最後の書き込み日時を更新日時として表示できるようになった。
数日間続いていた掲示板へのいたずらの書き込みが、ピタリと止まった。飽きたのだろうか。
リモートホストが毎回コロコロ変わっていて、その情報で弾くことはできず、その他の情報でフィルタリングしていた。もちろん、記事はすぐに削除した。書き込まれた記事はメールで送られてくるし、携帯電話からでも削除できるので、数分もしないうちに消せる。
怪しいと判断した書き込みはエラーにしている。今までは、エラーの原因を出力していたが、わざわざ見せるのはヒントを与えているようなものなので、「調査のため、管理者へ情報が送られました」というメッセージに統一した。実際には何も送られていない。むしろ、エラーにならずに書き込めたときに情報がメールで届くので、このメッセージはでたらめなのだが、なんとなく心理的にイヤな気分にさせる意図でこのようにした。
これが効果的だったというよりは、やっぱり飽きたのではという気がする。とにかく、こういうのはむやみに反応せず、とことん消して、書き込めないように対処するのが一番だ。
海外からと思われる、悪質な掲示板への書き込みがしぶとい。NGワードやリモートホスト規制で弾いてきたが、日が経つと、それらをすり抜けてまた書き込まれる。
書き込みモード(通常モードか図/表モード)の値が不正なものがいくつかあったので、チェックを厳しくした。しかし、今度はそこも正しくして書き込んできた。
何かいい手はないかと、いくつかの書き込みをじっと見ていると、どれもリンクの書き方に特徴があることに気づいた。リンクを「|」で区切って書き並べているのだ。ではそれをNGワードにしてしまおうということで、「html | http」を加えた。選択一致の記号とかぶるので、Perlで書くときは「html | http」となる。
何度もうっとうしいけれども、Perlの勉強にはなっている。次はどんな内容で書き込んでくるかしらん。
この前の掲示板の書き込み規制の件で、Perlの文法について、もう少し調べた。
if ($host =~ 'ホスト名の部分文字列') でも、文字列に正規表現が使えた。となると、正規表現かどうかで分けて書く必要性はあまりなさそうだ。
それと、条件を書き並べるよりも、選択一致を使ったほうがスマートだと思った。つまり、
if ($host =~ /文字列1|文字列2|文字列3/)
というような。
if文が長くなるのはよろしくないので、適当な変数に入れておくとすっきりする。
$nghost = "foo93[0-4]\.bar\.ne\.jp|"
. "foo-[1-3]\d\.bar\.net|"
. "foo3[7-9]\.bar\d[1-5]\.com";
if ($host =~ /$nghost/) {
&error('ホスト規制','このホストからは投稿できません.');
}
Perlは手軽で便利だな。もっと使う機会を増やして慣れておきたい。
掲示板に、宣伝の書き込みがたまにある。すぐに消せるけれど、消すだけで更新日時が変わってしまうのが気に入らない。そこで、書き込み規制をすることにした。
まず、記事に特定の単語があったら書き込めないようにした。簡易BBSのソースで、内容がないときのエラー処理の後ろに、次のように追加した。以下は一例で、規制したい単語の数だけ条件を増やす。
if (($FORM{'value'} =~ 'NGワード1') || ($FORM{'value'} =~ 'NGワード2')) {
&error('NGワード','不適切な言葉が含まれています.');
}
ホストでの規制もした。リモートホストの取得処理の後ろに、以下のように書いた。これも、規制したいホストの数だけ条件を増やす。
if (($host =~ 'ホスト名1') || ($host =~ /ホスト名2/)) {
&error('ホスト規制','このホストからは投稿できません.');
}
'foo.bar.ne.jp'のような部分文字列での書き方だけでなく、/foo..\.bar\.ne\.jp/のように正規表現も使えるので、数字が変わっていても対応できる。
本当は、処理したい文字列を、別の場所に書き並べるか、外部にファイルを持ったほうが、今後のメンテナンスがしやすい。今のところは、似たようなホストからの、似たような書き込みが多いので、今回は簡単に済ませた。
たまに掲示板に宣伝の書き込みがあるので、.htaccessでホストの制限をしようとした。しかし、設定しても機能しない。どうやらhi-hoでは、cgi-binディレクトリ配下は.htaccessファイルの設定を無視するらしい。
サーバの制限事項のページに書いてなかったので、いちおうhi-hoに問い合わせたら、そういう仕様とのことだった。書いておいたほうがいいんじゃないかと言ったら、貴重なご意見ありがとうございますみたいな返事が来た。実際に追記されたら、ちょっと感心する。いつまでもそのままだったら、何らかの事情で却下されたか、闇に葬られたということで。
改めて、うちのサイトのトップページを見ると、何も説明がないことに気づいた。これだと、初めて来た人が少しとまどいそうなので、簡単な説明を入れた。
一向に減らないスパムメールをどうにかしたい。まず、Webに載せているメールアドレスは、一部をエンコードして、JavaScriptで分割して表示するようにした。たとえば、t-inukaiは、document.write('t-' + '9;nuka&#' + 'x69;');にするなど。エンコードされた文字の途中でも分割しているのがポイント。アットマークは確実にそうしたほうがよいと思う。
あとは、プロバイダのほうでフィルタリングをした。hi-hoは、今のところメールアドレスの完全一致とサブジェクトの部分一致でしかはじけないようだ。メールアドレスのフィルタリングは役に立たないし、本文での条件指定もできないので、あまり効果はなさそうだ。
hi-hoのサーバは、wwwとtimの間にピリオドを入れなくても、ちゃんとアクセスできる。
MIDIのページは、何年も更新していないし、これからも更新される可能性は低い。改めて読み返すと、いろいろと小難しいことを書いているなと思う。我ながら、現役のときのパワーはすごいと感じた。そのときに書き残しておいてよかった。本当は、もっと書くことがたくさんあるのだけれど、今となってはもう無理っぽい。