http://www.tokyo-np.co.jp/00/tokuho/20040514/mng_____tokuho__000.shtml
そろそろ日本を脱出しなければ、と思い始めたのは何年前だったか。
ちなみに私がいままで長期滞在した国（アフガニスタン、イラク）は、私の滞在時にはどれも親米的だったが、どれも後で対米戦争をやっている。
私はWindowsが好きだ。
特にIE6がいい。私は今日、IE6がどんなによくできているかを思い知った。
webページの文字コードを判別する手がかり（というあたりが諸悪の根源なのだが）はいくつあるか。私の知るかぎりでは3つ、
1. レスポンスヘッダ
2. meta要素
3. テキスト
そしてXHTMLなら、これに加えて、
4. XML宣言のencoding
となる。が、XHTMLのencodingを間違えるような間抜けは無視できるので、XHTMLなら文字コード判別の必要はない。
この世でもっとも正しい方法は、レスポンスヘッダである。が、レスポンスヘッダ中にcharsetが表示されていると信じるのは、サンタクロースの存在を信じるよりもはるかに難しい。
meta要素はサンタクロースよりも信じられる。少なくとも日本語のページでは、かなりの割合でmeta要素の存在が期待できる。
最終決裁者が、テキストだ。meta要素やレスポンスヘッダがなにを書いていようと、テキストが文字化けしていればそれは文字化けである。なにしろ世の中には、HTMLをメモ帳で手書きするよう指導する呪われた入門サイトがあるので（彼らに三度アナテマ）、呪われた人々が「charset=x-euc-jp」とmeta要素に書き込みつつUTF-8で保存しているかもしれない。こういう呪われたHTMLは表示できないようにすべきだったが、もし人々がそれほどまでに正しかったなら、人間は天使と区別がつかないだろう。
このような状況のもとで、webページの文字コードを判別する仕組みをサーブレットに組み込むには、どうすればいいか。まず大まかな流れを考えよう。
正しい人は、正しい方法を尊重する。レスポンスヘッダにもしcharsetが設定されていれば、これがmeta要素やテキストに優先されるべきだ。もしなければ、次にmeta要素が来る。そして最後の手段が、テキストデータからの推測だ。
では早速そのようなアルゴリズムを実装しよう――などと思った人はプログラマではない。プログラミングとは、不労それ自体によって生産する技芸である。
レスポンスヘッダのcharsetを最小限のコードで取得できるのは、おそらく、Jakarta Commons HTTPClientである。これをちょっといじり、レスポンスヘッダのcharsetのあるなしを取得できるようにする。
レスポンスヘッダにcharsetがなければmeta要素を当たる。これをもっとも簡単確実にやってくれるのはおそらく、NekoHTMLだ。ここでもまた、meta要素にcharsetのあるなしを取得できるようにいじる必要がある。
自動判別は、私の知る限り、jchardetのほかに選択肢がない。StringのコンストラクタのJISAutoDetectは、UTF-8やMS932でこける。
さて諸君、ここで残念な知らせがある。
これだけやってもまだ、これほどやってもまだ、満足のいく判別にはたどりつけない。たとえば、上の仕組みを素のままでhttp://www.yahoo.co.jpに適用すると、GB2312と判別される。どうやらEUC-JPはその仕組み上、自動判別を間違えやすいらしい。一応の救済策はあり、jchardetに日本語判別を指定すると、正しく判別される。が、日本語判別を指定した状態では、他の文字コードをまったく判別できなくなる。
もしサーバ上にIE6さえあれば、こんな苦労はすべてなくなるのだ。この世のサーバがすべてWindowsになる日も、そう遠くないだろう。
前言撤回。
中身を開けてみたら、NekoHTMLよりもHTMLParserのほうがいい。これだとHTTPClientがいらないので、話がずっと簡単になる。
また、http://www.yahoo.co.jpのレスポンスヘッダにはcharsetが設定されていた。なぜ設定されていないと思ったのか、いまではよくわからない。
二十世紀初頭のモスクワでは、反政府活動で逮捕された学生を非難するような人は少なく、同情と共感をもって迎えられたという。戦後の日本で、チャタレイ事件や「悪徳の栄え」事件の被告人がけっして孤独でなかったのと同じく、彼らは孤独ではなかった。
賢明なる読者諸氏には、司法判断に注目しているような、ずれた人はいないと信じたい（国益のために「電気は物だ」と言い切り、さらにはそれに合わせて法律のほうを変えてしまうお国柄である）。47氏をどう迎えるか――これは、ただそれだけの問題だ。
ベトナム戦争はテト攻勢が転回点になった。
といっても、ベトナムの戦場では、注目すべきことはなにも起こらなかった。例によって北は甚大な被害を出し、南の戦線は小揺るぎもしなかった。決戦は、アメリカのＴＶと視聴者のうえで起こり、そこでアメリカは最終的に敗北した。
現在では、「メディア上での決戦」という概念はありふれたものになった。もちろん現在でもメディアは重要な戦場である。ボスニア紛争では、クロアチアがメディア工作で先手を取り、そのまま終始優位に戦いを進めた。
そして今、新たな決戦場が発見された。捕虜収容所だ。
日本のメディアではまったく報道されないが、この写真をご覧になれば、アメリカの敗北がはっきり読み取れることと思う。
写真にあるような虐待は重大な罪だが、罪だけならまだ決定的ではない。決定的なのは、この写真に写っているアメリカ人たちが、間抜けで、想像力に乏しく、頼りない人々に見える、ということだ。征服者にとってこれは最悪のイメージである。残虐な征服者からは逃げ出したくなるが、頼りない征服者には逆らいたくなる。
ティーンズハートを置いている本屋がめっきり少なくなった。廃刊間際の学研レモン文庫といった趣だ。発行点数はまだそこまでひどくはないが、隔月刊である。詳しくはこちらをご覧いただきたい。賞の募集ページ（巻末）にも投げやり感が漂う。「原稿がよければ随時」というのは、定期的に賞を出せるほどの原稿が集まらない、という意味としか取れない。
原稿が集まらないのが先か、それとも、本屋でのプレゼンスが低下したのが先か。花井愛子と折原みとの全盛期からすでに、新人作家の登場しない・長続きしないレーベルだったので、原稿が集まらないのが先だと思える。
それはともかく内容について。
文章を書くときにはいつも、「描写」というモデルのよしあしを考える。「個性」「事実」といった固有の実体がまず存在し、その実体に対応して任意の「描写」がある――というモデルは、文章としてどうなのか。どうなのか、といつも考えつつ、結局いつも結論を出せずにいる。
この本を読みながら考え、今度もまた結論が出ない。
文章技術としては、実体―描写モデルはクソだ。上手な文章は、「なにを書くか」と「どう書くか」を区別できない。理想的には、上手な文章とは、「ここで作者が表現しているのは～」などという議論が成り立たないものだ。聖書がそうであるように、文章そのものが固有の実体として扱われる（聖書が上手な文章かどうかはともかく）。
皆川ゆかは、逆をいく。描写される実体があるかのように書く。
当然の結果として、文章がしばしばわかりにくい。実体―描写モデルは、いわば絵を立体に起こすようなもので、ものによっては、「この顔の一体どこが観鈴ちん？」ということになる。複数の主観からの描写がある部分、それも同時進行する部分など最悪だ。
が、実体―描写モデルには、小さからぬメリットがある。
文章が長くなると、「実体」なるものを想定するほうが、わかりやすくなるのだ。文章を、文章それ自体よりはるかに単純な「実体」へと非可逆圧縮してしまうわけだ。本作『運命のタロット』のような大長編では、このような非可逆圧縮は避けがたい。
実体―描写モデルは大長編専用、で終わるなら話が早いが、それで終わらないからこそ考える値打ちがある。
実体―描写モデルが適切な範囲には、上限があるのではないか。その上限とは、「実体」の複雑性によって決定されるのではないか。本作『運命のタロット』は、その上限を超えてはいないか。
ようやく本題である――
実体の複雑性に対応しようとして、実体を不可逆圧縮した「根源」なるものを想定し、根源―実体―描写の三段構えのモデルをとったとき、そこにはなにかひどく不吉なものが現れはしないか。
言い換えれば、一段階の不可逆圧縮と、多段階の不可逆圧縮のあいだには、きわめて重大な落差があるのではないか。
もしあるとしたら、それは何か。
答はまだ出ていない。そして、もしかすると、この答そのものが、忌まわしい多段階の不可逆圧縮であるかもしれない。
…………というような議論を超能力バトルで展開する話、それが『運命のタロット』です（大嘘）。
Webアプリに初挑戦している。
とりあえず、Webアプリでなにかしようとすると、必ずデータベース（PostgreSQL、MySQL）が必要になることに気づいた。なにしろ同期処理があるので、永続性の必要なデータはみなデータベース行きになる。このごろ本屋にSQLの本が多いと思ったら、どうやらみなWebアプリを書いているらしい。