OSC2006Tokyo/Spring 1日目

comp

オープンソースカンファレンス2006 Tokyo/Spring の1日目に行ってきました。
今日は森山さんのセッションのみを聴きました。

強風の影響

強風の影響で電車が遅れたので開始時間に間に合わないかと思いましたが、何とか間に合いました。今日はこのセッションだけを聴きに来ているので遅れたら無駄足になってしまうところでした。

内容以外について

参加者は20人くらいでしょうか。fj.kanjiの時代から文字エンコーディングの問題が絡むと一癖も二癖もありそうな人たちが集まるのですが、今回参加した人たちはどうなのでしょうか。森山さんがいったい何を始めるのか興味があるといったところでしょうか。まあ、私もそうなのですが。
森山さんの声が小さくて聞き取りにくかったです。
マウスのポインタを移動させるつもりが、何回もタッチパッドで不用意にクリックしてしまっていました。ThinkPad信者の私はこういうときにこそThinkPadを(以下略

参加した理由

感想で色々ぐだぐだ書いているので一応参加した理由を書いておきます。

  • 森山さんが以前から文字エンコーディングの問題に関して活動を行っているのを知っているため。私は森山さんがmutt-j MLにiconv-hookパッチを投稿したのでそういう活動をしているのを知りました。直接のやりとりは無いのですけどね。
  • その森山さんがメーリングリストまで作って何をやるのか興味があったため。
  • Windowsのメイラーの実装に関して昔調査を行ったことがあるため。
  • 私自身がMuttの日本語対応で文字エンコーディングの問題には出くわしているため。文字化けを矯正（〓マークに置換したり）することで対処しましたが。
  • 仕事上でJava/PostgreSQLでウェブアプリケーションを作る際に、文字化けを防ぐためにどうしたらよいか調べたことがあるため。

要は文字エンコーディングに関して個人的に興味があるだけです。

感想

吉岡さんからコメントが入っているので感想を書きます。メモを取っていないので覚えている範囲で。
文字コードがらみの問題点の説明自体は取り分けて目新しいものではなく、今までさんざん言われてきたことですのでとりあえずスルー。
実装すべき文字エンコーディングについての説明はWindowsのコードページの話には詳しくないので新たな知見を得ました。
コードポイントについての説明もありましたがこれもスルー。
開発を予定しているOSSの一覧と文字エンコーディングの実装状況については、種類を分けて表を作った方がよいと思うのですが。ライブラリ、開発言語、データベースということですよね。それぞれの用途に応じて実装すべきものが異なるのですから。
ここに集まった人は具体的にどうやって問題に対応していくのかを知りたかったと思うのです。前半はもう少し端折ってもよかったのではと思います。


質疑応答で「何者だ？　この鋭い指摘をする兄ちゃんは？」と思ったらJavaの文字エンコーディング関連で有名な風間さんでしたか。本を持っています。そういえば、Javaのイベントでお姿を拝見した記憶が。
文字エンコーディングの問題の主要な点は風間さんが指摘するようにOSの文字コード変換ライブラリの実装なのですよね。OSによって実装が異なると困るから開発言語やデータベースは独自で変換ライブラリを実装しているのではないかと思います。話を聞きながらMac OS Xや*BSDに対してはどう対応するのかなと思いました。そういえば、Citrus Projectはどうなっているのでしょうか。ホスティングサーバでFreeBSDをjail環境で触るくらいしかしたことないので*BSD方面は知らないのです。
Javaに関してはどうなんだろうと質問しようかなと思ったのですが、風間さんがいるとわかって下手な質問をしなくて良かったと冷や汗をかいていました。


風間さんからの意見でも出ていたISO-2022-JP-MSに関してはあればあるで便利かもしれないけど正直言って無くても困らないです。ISO-2022-JPは実質的にメールとニューズにしか使われていないでしょう。しかも、ニューズはもはや廃れていますし。また、昔はウェブでも使われていました*1が、今はわざわざISO-2022-JPで記述する人はあまりいないでしょう。そういうわけでメールで機種依存文字が化けて困るかということ、実はそれほど困らないのです。文脈でだいたい判断できますから。ちなみに、mutt-j MLでは機種依存文字を扱いたいとの要望があったので一応記しておきます。あればあるなりに使い道はあるということです。言い方を変えれば風間さんが指摘したようにあれば便利で使ってしまうということです。受け取ったメッセージの解析にISO-2022-JP-MSを用いて、送信時にはUTF-8で送るというのであれば問題はない*2でしょうが。
まあ、メールも将来的にはUTF-8へ移行していくのでしょう。主要なMUAではUTF-8への対応は実装されていますし、実装されていないのは古いMUAとRFCを読まないで作ったような質の悪い一部のMUAでしょう。そういえば携帯電話のメールはどうなんだろうか？　自分の携帯宛にUTF-8でメールを送ったら文字が全部化けました orz


開発対象のOSSを絞っていますが、どの状況で文字化けが生じるのを防ぎたいかというターゲットも明確にした方が良いのではないかと思います。切実な問題になっているのは複数の文字エンコーディング処理を行うソフトウェアが連携しているウェブDBアプリだと思いますので、ここら辺が適当ではないでしょうか。

*1:私もISO-2022-JPで記述していました

*2:これはこれで相手のMUAがUTF-8を理解できないと問題があるのですが