今日、ミラクルリナックスの吉岡さん主催の
「文字コードヲタクで集まってピザとビールを楽しむ会」に参加してきた。
（うそ、本当はレガシーエンコーディング変換機能の開発オフラインミーティング）

ちょっと（だいぶ)遅刻してしまいご迷惑をおかけしてしまったのだが、
いやー、ヲタク同士の極めて濃ゆい会話を堪能させていただいた。
普段リアルで顔を会わせる面子で文字コードで盛り上がるなんて不可能だから
こういう集まりは素直にうれしい。


さて、あの場で酒の勢いでいろいろと放言してしまったのだが、
たぶん、今日の酒の量だとほとんどの人は明日には忘れ去られていると思うので
改めてこのブログで意思表明をしたい。



・ISO2022-JP-MSは撤回してほしい、世の中で求められているのは

  Outlook Expressが送ってくる拡張ISO2022-JPを受信できることであって

  それ以外のエンコーディングは必要ない。

  スジがいいとか悪いとかは関係ない。CP5022xでいいじゃん。

  現実重視！

・英語ホームページを作って欲しい。アメリカ人の

  「なぜUnicode.orgに登録されているマッピングテーブルではダメなの？」

  という疑問に答えることはコミュニティに受け入れられる上で極めて重要。

  （あってるかどうか自分では確認できないコードをacceptしろと言われるメンテナ

    の気持ちを考えよう。そら嫌がるよ）

  また、ドキュメントがなければ結局新規ソフトはどんどん森山さん実装と

  非互換の実装をしていくので事態はどんどん悪化していく。

・今回開発したレガシーにやさしい変換方式は、

  Unicode.orgに登録されているマッピングテーブルと同じファイル形式でも

  公開してほしい。

  世の中のソフト会社のi18n対応ってのは極めて冷遇されていて、１流の技術者は

  コア部分の開発、２流の技術者がnlsサポートみたいなアサインは珍しくない。

  するとどうなるかというと、現状、Unicode.orgのマッピングテーブルからコードを

  自動生成して対応する。みたいな話は腐るほどある

  （特に僕が以前いた組み込みの世界のミドルウェアでは）

  だから、ファイルフォーマットに不備があろうがなかろうが、Unicode.orgの

  形式重要。ある種のデファクトだから。

・日本の技術者にも、なんでこんなにマッピングがいるのか理解していない技術者は

  腐るほどいる。

  だから、レガシーエンコーディングWikiに、これこれこういう状況ではｘｘという

  ソフトがこういう送り方をしてくるから受信側でこの変換方式をしていしないと

  非互換になって困ってしまうんだ、的な使い方の情報必要。

  これがないとマッピングテーブルが増えた分だけ混乱して、

  間違った使い方をする人が必ず出てきて非互換がより悪化する

・これはコミュニティの働きかけの問題になってしまうが、

  現在の、Windows互換にしようと思ったら、

  ｘｘというソフトではCP932と指定する必要があり、

  ｙｙというソフトではSJIS-msと指定する必要があり

  ｚｚというソフトではMS932と指定する必要があり

  また、別のソフトではCP943Cと指定する必要があり、

  かつそれをやってもｘという文字とｙという文字は変換ルールが違うので

  文字化け。という状況は無くさなければならないという強い意志をもって欲しい。

  （現状、バッドノウハウの塊）

  私はWindows31Jと指定したときにソフト・言語によらずマッピングルールが一意に

  定まる世界を望む。

  そうでなければ、相互運用など出来ない。名前重要！

  同じものに同じ名前が付くように働きかけをして欲しい。

・今回進めているレガシーエンコーディングプロジェクトを知らない人はまだ

  いっぱいいる。

  （てゆーか、僕は知らなかったっす（＞＜；）

  もっと宣伝、宣伝。


無論、僕も出来る範囲でお手伝いさせていただきますゆえ・・・


ところで、僕はeucJP-msとCP50932がなぜ両方必要なのかをまだ理解できてません。
だれか教えてくださませ。
お願い


P.S. 芝野いいんちょーと初めて議論させていただきました。やっぱいいんちょーは違うぜ




委員長！ ランキング！