2003年1月分。
あ、sawadaspecial.comから漢字で元素と漢字元素周期表にリンクが。おかげですごい勢いでアクセスが……と思っていたら夜中過ぎから俺ニュースからもリンクが張られて更にすごいことに……。数年振りにやってきた
Analogによるサイト全体の統計より。
年月日 時間帯: リクエスト数: ページ数:
--------------------------------: ------------: --------:
2003年 1月 8日 14時00分-15時00分: 365: 64: +
2003年 1月 8日 15時00分-16時00分: 438: 78: +
2003年 1月 8日 16時00分-17時00分: 1451: 135: ++
2003年 1月 8日 17時00分-18時00分: 1030: 80: +
2003年 1月 8日 18時00分-19時00分: 552: 55: +
2003年 1月 8日 18時00分-19時00分: 552: 55: +
2003年 1月 8日 19時00分-20時00分: 7041: 183: ++
2003年 1月 8日 20時00分-21時00分: 26142: 598: ++++++
2003年 1月 8日 21時00分-22時00分: 25100: 688: +++++++
2003年 1月 8日 22時00分-23時00分: 26903: 650: +++++++
2003年 1月 8日 23時00分-24時00分: 57674: 1069: +++++++++++
2003年 1月 9日 00時00分-01時00分: 70204: 1292: +++++++++++++
2003年 1月 9日 01時00分-02時00分: 51087: 811: +++++++++
2003年 1月 9日 02時00分-03時00分: 23795: 433: +++++
それにしても、3年前に作ったページが未だに新たな読者に発見され続けている、というのは有難いことであります。比較対象がないのではっきりとは分かりませんが、労力の割にはかなり多くの読者に恵まれているような気がします。
とか暢気なことを言ってますが、漢字元素周期表はもともと100以上の画像（それぞれは小さいながらも）を含むページでありまして、そんなページにこれだけのアクセスが集中するとサーバの負荷がおそろしいことになってるのでは……。というわけで、遅まきながら先ほど表の部分を一枚画像にしたページと置き換えたのでありました。すみません。＞プロバイダさん
（2003年1月9日）
先週あたりにD-COT 1月4日経由でrss-jp.netというサイトを知ったのですが、「日本で配布されているRSS/RDF」の独自生成のところを見ると、普段お見かけしているサイトのRSSもちらほらと。
RSSがサイトの概要を公開するRDF/XML文書、とことくらいは以前にThe Web KanzakiでのRSSの説明を見かけていて頭にはあったものの、今ひとつピンとくるものがないままだったのですが、実際に利用例を見て、しかも個人サイトでも導入しているところがあるのを見ると、
なんとなく分かってきたところで、さて自分とこにも導入してみようと考えたのですが、いちいちRSSファイルを手書きするのは面倒だし記述を間違えるかもしれず、やはり面倒なことはコンピュータにさせたいところ。徒書では最新記事の表示に、HTMLファイルを読んで最新数件を表示するCGI(index.cgi)を使用しているのですが、これを元にして最新記事の概要をRSSとして出力できないか。……といった思考の流れで、RSS生成スクリプトのサンプルも参考にしつつ、rss.cgiができまして、8日あたりから密かに公開してました。
当初、文字コードはHTMLファイルと同じShift_JISのままで出力していたのですが、RSS Validatorにかけてみたところ文字コードが無効というようなエラーになりちょっと悔しかったので、急遽Jcode.pmの使い方を覚えてUTF-8変換を達成。HTMLファイルについては、古いブラウザで見ることも考えてもう暫くはShift_JISのままにしておきたいけど、最近の技術には（XMLのデフォルトの符号化方法でもある）UTF-8を使っていった方がよいか、などと考えてみたり。……てなところで改めてRSS 1.0の仕様をよく見てみると、文面にはUTF-8（とUS-ASCII, ISO-8859-1）のことしか書いてないから、やはりUTF-8にしておくべきなのだろうか。
- Encoding
- While RSS 0.9 supported only ASCII encoding, RSS 1.0 assumes UTF-8. Using US-ASCII (i.e. encoding all characters over 127 as &#nnn;) is conformant with UTF-8 (and ISO-8859-1, HTTP's default header encoding).
サイトによっては、XSLTを使ってRSSを対応ブラウザで表示できるようにしているところもありましたが、ここのRSSはスタイル無しの素のままであります。自分がXSLTを
例えば、ここのRSSをウェブベースのツールで表示させた場合はこんな感じ。CGIのパラメタにより表示を変更できるものもあります。
また、試しにrss-jp.netで公開されているスクリプトを使用して、某方面で公開されているRSSをHTML表示するページなんてのを作ってみました。<script ... ></script>タグを並べるだけで好きなサイトの更新情報が見られる、というのは確かに手軽で便利そうであります。
後から、RSSのMIMEタイプは何とすべきか、ということが気にかかりました。仕様では今のところapplication/xmlとなっているようだけど、RSS独自のMIMEタイプもそのうち登録される様子。で、検索してみるとまだ正式登録されていないようですががapplication/rss+xmlというのが提案されているらしい（英語ページばかりなので斜め読みですが）。またlink要素の使い方として、サイトのトップページに
<link rel="alternate" type="application/rss+xml" title="RSS" href="url/to/rss/file">
と書くやり方がdiv into markの2002年6月2日（英語）など幾つかのページに記述あり。そんなわけで、link要素の使い方も含めてここでもその方法を取り入れてみました。
ただ、RSSをapplication/rss+xmlで出力すると、ブラウザでソース確認ができなくなってしまう（ダウンロードのダイアログが出てきてしまう）ので、CGIを少々改造してURLに?xmlをつけるとapplication/xmlで出力する機能なぞつけてみました（CGIだとMIMEタイプの出力も融通がきいて便利）。一応正式版は"http://www.akatsukinishisu.net/itazuragaki/rss"ということで。
註: 現在はapplication/rss+xmlで提供するのをやめて、application/xmlとして提供しています。
その他のRSS関連ページでは、agenda -2002/9/16〜31を読んで、RSSもまた厳密に書くべきだなと改めて認識してみたり、グランド・ウェブ！ ファンキー ヘタレ・ロードの2002年11月3日を読んで、Flashティッカーで更新情報表示するのは見た目かっこよくていいなと思ったり、などと興味深く読みました。
嗚呼、案の定文章が長くなってしまいました。きっと新しいものを覚えたてで浮かれているのです。
（2003年1月12日）
アメフラシを
あのですね、アメフラシで検索するとですね、サナダムシ似のグロ的画像がバンバン釣れるんですよ。
というわけで早速実行（←いいのか）。
５匹で輪になって」！ 生命の神秘だ。人間の場合に当てはめてみると……こわい考えになってきたので中止。
むしろ楽しみました。いやはや。
ウェブで見かけるXHTML 1.1のページの中には、metaタグで <meta http-equiv="Content-Type" content="application/xhtml+xml; charset=Shift_JIS" /> という風に書いてあるものがありますが、この記述は、metaタグを解釈して、その通りにContent-Typeヘッダを出力してくれるようなサーバでもない限り、意味がないのではないでしょうか。
application/xhtml+xml になっているのは、メディアタイプについて嘘をついてしまっているような気がします。
→metaタグのapplication/xhtml+xml(2)に続く。
（2003年1月13日）
先刻のmetaタグのapplication/xhtml+xmlに、早速言及を頂いたので追記を。
うちの掲示板に頂いたsatoshiiさんの書き込みを以下に引用。参考になります。
http://www.akatsukinishisu.net/itazuragaki/?i200301-05 の件ですが、実は僕も気になっていました。「meta タグを解釈して、その通りに Content-Type ヘッダを出力してくれるようなサーバでもない限り、意味がないのではないでしょうか。」というのは、全くその通りだと思います(逆を返せば、そのようなサーバが存在するならば構わないのですが…)。
UA が直接的にそういった文書を処理する場合、1) その UA が XML パーザなら、そもそも meta http-equiv による記述は解釈されませんし、2) その UA が XML パーザでないなら、application/xhtml+xml と認識させても意味がありません。結局、いずれにせよ meta による指定が UA に対し直接に意味を持つことはありません。
ちなみに、例の XHTML Media Types [1] にも "XHTML を application/*+xml として serve する場合には、meta http-equiv での content-type 指定は記述すべきでない (SHOULD NOT) と" という注記 [2] があります。
# そんな儚げな meta に希望を託すより、直接サーバ管理者に .htaccess の書き換えをお願いする方が余程有効なのでは…。
[1] http://www.w3.org/TR/xhtml-media-types/
[2] http://www.w3.org/TR/xhtml-media-types/#application-xml
Note that a meta http-equiv statement will not be recognized by XML processors, and authors SHOULD NOT include such a statement in an XHTML document served as 'application/xml' (and 'application/xhtml+xml' as well for that matter).
べた日記の1月14日より:
現状、SSI を使用した状態（拡張子はshtml）のままで
application/xhtml+xmlをヘッダで吐くのは無理ぽなので、XHTML 1.0 Transitionalとしてtext/htmlにしますた。
そう！ ApacheではどうもSSIはtext/htmlであるファイルにしか効かない模様なのですよ。自分も、コンテントネゴシエーションを用いてapplication/xhtml+xmlに移行しようして、その問題に突き当ったので断念したのでした。将来的にはapplication/xhtml+xmlなファイルにもSSIが効くようになってほしいところなのですが。
追記: 前の段落はまちがいでした。詳しくは次項「SSIとapplication/xhtml+xml」を参照下さい。
それはともかくXHTML Media Typesに従うのであれば、XHTML 1.0の互換性ガイドライン（邦訳）に従った文書にすればいいのであり、StrictをやめてTransitionalにすることはないですよ。
（2003年1月14日）
satoshiiさんの記事をこちらに引用しました。
（2003年1月22日）
先の「metaタグのapplication/xhtml+xml(2)」で、ApacheではどうもSSIはtext/htmlであるファイルにしか効かない模様
、などと書いてましたが、後で色々と試してみたところ、この文は間違いであると分かりました。申し訳ありません。以下、application/xhtml+xmlであるファイルでSSIを行う方法について述べます。
まず、SSIを行うにはAddHandler server-parsed命令による方法がありますが、この場合は.htaccessファイルに次のように設定すれば、application/xhtml+xmlであるファイルでも問題なくSSIが使用できます。
AddHandler server-parsed xhtml
AddType "application/xhtml+xml; charset=Shift_JIS" xhtmlSSIを行うには、他にXBitHack命令による方法もありますが、この場合、単にXBitHackを置くだけだと、これはtext/htmlであるファイルにしか働きません。例えば次のような場合:
XBitHack full
AddType "text/html; charset=Shift_JIS" html
AddType "application/xhtml+xml; charset=Shift_JIS" xhtml自分は普段XBitHackの方を使用していたので、この設定でapplication/xhtml+xmlのファイルにSSIが効かないことをもって、SSIはtext/htmlであるファイルにしか効かない
と勘違いしていたのでした。
さて、AddHandler server-parsedによる方法なら、application/xhtml+htmlであるファイルでもSSIが使えるわけですが、これだとXBitHack fullでできた、Last-Modifiedヘッダを出すSSIにはなりません。が、試しに次のようにAddHandler server-parsedとXBitHack fullを両方書いてみると、属性754のファイルで、Last-Modifiedヘッダを出力するSSIを実現することができました。
XBitHack full
AddHandler server-parsed html xhtml
AddType "text/html; charset=Shift_JIS" html
AddType "application/xhtml+xml; charset=Shift_JIS" xhtmlひとつ欠点があるとすれば、ファイルの属性を644などにしても「SSIを効かなくする」ことができないところですが、
以上、検証はApache/1.3.12（当サイトのサーバ）で行いました。
（2003年1月15日）
1月16日は、東京ドームで行われたBON JOVIのライブに行っておりました。BON JOVIについてはここ最近は熱心なファンであるとは言えず、最新アルバムも今年に入ってから聴き出した有様ではありましたが、聴き覚えたばかりの感動も新たなところにライブを聴いたこともあってか、大いに楽しんで来たのでありました。
……個々の曲などの感想を書こうと思ったのですが、どうも上手く書けそうにないので棚上げにしときます。
リッチー・サンボラの歌う"I'll Be There For You"が聴けてよかった……。
（2003年1月22日）
そうこうしている間に、短編では第6期が開始しています（ここの表紙の宣伝文を変えるのを忘れてたので、慌てて変更）。
第5期では今までにはなかった予選結果からの逆転が起こったり、第6期になって作品数が少し増えて嬉しかったりしましたが、それについて語る間もなく、久遠氏掲示板にて第6期作品についての議論をしております。柄にもなく。
主催する者が議論に参加してしまうのはどうかと思わなくもないものの、主催者であると同時に熱心な読者のひとりでもあるので、つい。でも願わくは、このような議論が読み手の間で発生してくるとよいのですが。
でもって、参加したい
、とか面白い
、と思う方にはぜひ参加してほしいものでございますよ。と言ってみたり。
（2003年1月23日）
『短編』の掲示板で、他にも1000字小説の投稿サイトが出てきてくればいいというような話を書いたのだが、そうなることは、必ずしも『短編』にとって良くはならないかもしれない。力あるサイトに投稿者が引き寄せられ、作品・読者を集められないサイトがあえなく立ち消えになる、ということも考えられるだろう。一応それなりのサービスを提供しているつもりではあるけれど、そう言ってられるのも今だけ、という気もする。
でもまあ、そんな個々のサイトの興亡などは、長期的視野で見れば投稿者や読者にとって大した問題ではないのだ。様々な特徴を持ったサイトが存在して、書き手・読み手が自由にそれらを選択できるようになれば、ジャンルとしての1000字小説――でなくともウェブ超短編小説――は更なる盛り上がりを見せるに違いない、と思う。
やや誇大妄想になってるような気もするが。
開始以来、今のところ『短編』の運営にはさほど問題もなく、また運営自体を楽しみつつ続けているのだが、いつかは大きな批判を受けたりすることもあるだろう。今までは個人サイトをのんびりと運営していただけなので、特に問題もなく過ごすことができていたけど、『短編』は人からコンテンツを預かって掲載するというサイトの性格上、意見の衝突が起こる可能性はずっと大きいはず。で、そのような批判に直面した時に、自分は取り乱すことなく冷静に対処できるだろうか……というのが最近になってやや自信がなくなってきていたりします。とは言うものの、なるべくならない方がいいにしろ、「いつかはその時が来る」というのは（過去の経験より）ほとんど確信しているので、そのことを忘れることなく、今後も運営を続ける所存であります。
批判が自分のみに向いているのであればまだいいとしても、投稿者を巻き込むこと――特に、「読者に作品を読んでもらう」という本来の目的を損なうこと――は何としても避けたいところ。だから今後は他サイト言及には十分注意したいと思います。
ところで、最近『短編』に代替スタイルシートを追加したのですが、ひとつは元のを白黒反転したもの、もうひとつはここのスタイルシートの流用、と
（2003年1月29日）
韜晦日記の1月29日経由でLife with a Roseのリンクページのコメントを拝見。ツボを突かれた褒め言葉には弱いので、まあ言及した時点で実行することはほぼ決定していたのですが（それで止めたらただのチキン野郎だ）、御蔭でやる気に加速がつきました。きりのいいところで2月から初める予定です。
ただし、やつて上げ
るなんて尊大な物言いはしませんよ！ 篆書バナー作成は当サイトを閲覧している方々のご愛顧に応えるための企画なのですから。感謝をこめて。
（2003年1月31日）
Operaの7 for Windows Finalを入れてみる。β版にあった、
確か仕様もそうなっていたような……と今になって確認してみる。何故かW3Cのサーバにつながらないので、仕様書邦訳のlist-style-imageの説明より:
この特性は，リスト項目マーカとして使用される画像を設定する。画像が利用できる場合, 'list-style-type'マーカで設定したマーカと置換する。
（2003年1月31日）
Web Site Wathchの「携帯電話でのweb閲覧」で、言葉 言葉 言葉の掲示板で挙がっていた携帯電話でのウェブ閲覧の話がまとめられていて、興味深く拝見……
私のau（SONY C1002S）で闇黒日記を見ようとすると，最新データが表示されない（以前見たデータで表示される）ことがあって，何故だろう，と常々思っていたのです。
（中略）
もしかしたら，サーバに残っているデータが更新されていないのかな？
自分もau(CASIO C452CA)ユーザなのですが、最新データを見るには手動操作で「ブラウザの履歴をクリア」をしないといけないようでした。どうもこの携帯電話ブラウザは「キャッシュとサーバの文書との更新日付を比較して、新しくなってたらサーバから持ってくる」ということはできないようで、なかなか面倒ではあります。
携帯電話でも閲覧可能なページを作ろう（『曉に死す』はともかく『短編』はなるべくそうしたい）とするとこれがまた奥が深そうで、取り敢えず自分の持っている物から何とかしようと、近頃EZweb ホームページを作ろう！などを読んだりして色々と試行錯誤中です。（ページをサーバで変換する仕組みは、HTML→HDMLコンテンツ変換仕様に詳細があります）
サーバで変換してくれる御蔭で、Shift_JISのみならずEUC-JPやUTF-8で書かれたページも読むことができるのですが、どうもこの素晴らしき文字コード変換は、HTTPヘッダに文字コードが明記されていないと働かないようでした。例えばEUC-JPのページでContent-typeヘッダが"text/html"のみだと、あのよくある半角カナだらけの文字化けが発生します。また、metaタグでの文字コード指定は無関係のようです。
そこで！ 技術ある某方面の方々には、是非HTTPヘッダでも文字コードを出力して頂けるよう、（わたくしの携帯電話での巡回の都合という誠に勝手な理由がら）ひそかにお願いする次第であります。
（2003年1月31日）