Hiro Yoshioka
hyosh****@mirac*****
2006年 5月 19日 (金) 18:51:01 JST
よしおかです。 メールのフォローがまさに周回遅れでもうしわけないのです。 > 成瀬です。 > 昨日はおつかれさまでした。 おつかれさまでした。 > とりあえず、昨日の会と今日のメール群を見て、 > このプロジェクトの方向性について、 > 概要なりなんなりに追記する必要があると考えました。 > > 勝手にWikiに追記しようとも思ったのですが、 > とりあえずWikiにFAQという項を作っておきました。 > http://legacy-encoding.sourceforge.jp/wiki/index.php?FAQ おおおお、ありがとうございます。 まさにバザールモデル。 > 途中からこのMLを読んでいる方に、 > MLのログを全て読んでもらうのはつらいと思われるので、 > FAQを最初に読めば一通りの流れがわかるようにするとよいかな、と。 素晴しいです。 > ところで、わたしの解釈で、「このプロジェクトの意義」案。 > > 「Legacy Encoding Project」とは、そもそも、 > レガシーエンコーディングを混乱なくフェードアウトさせようというもの。 > > （ミーディングでの乾杯の時に言われていた通り、 > 「レガシーエンコーディングの更なる発展と繁栄を祈る」 > ものではないと、笑。） 皆様のご健勝を祈りますが、レガシーエンコーディングは…(笑 > > これを実現する手段として、[LE-talk-ja 118]にも挙げられている、 > > Windows Codepage 932 で使用可能な文字を Unicode 経由で、日本語EUC > > 符号化方式、7ビットJIS(ISO-2022-JP)符号化方式に変換できるようにする。 > > これが手段となる前提として以下がある。 > * レガシーエンコーディングはJIS系、SJIS系、EUC系の三つ > * 今時の文字コード変換はUnicodeによるUCS正規化で行われる > * よって「キャラクタセット」とはUnicodeとの変換表のこと > * 既に"ISO-2022-JP", "Shift_JIS", "EUC-JP"といった名前の変換表は、 > 各OSSが提供しているが、独自の変更が加えられていて、変更できない。 > * 変換表のデファクトとしてWindows系のものがある。 > > 以上のような事情から、 > 変換表の名前（キャラクタセット名）は既存のものを使えない > ∵既存のものは別の変換表を指しているから > →別の名前を定義する必要がある > →かと言って全く新しいものを定義するのは混乱を助長する > →CP932, CP51932, eucJP-ms, CP50221 > （CP*の典拠はMicrosoftの実装、eucJP-msはTOG/JVC） よ -- Hiro Yoshioka CTO/Miracle Linux Corporation http://blog.miraclelinux.com/yume/
