MORIYAMA Masayuki
moriy****@mirac*****
2006年 4月 12日 (水) 20:37:06 JST
森山です。 Kazuhiro Kazama <kazam****@mac*****> wrote: > > On 2006/04/12, at 12:04, MORIYAMA Masayuki wrote: > > ISO-2022-JP-MS に関しては、ユーザ定義文字の扱いに関して変更になるかも > > しれませんが、現状では ESC $ ( ? としています。 > > なお，次のような別の角度から書かれた図を見つけました． > > http://www2d.biglobe.ne.jp/~msyk/charcode/cp932/cp932mapping.png > > これを見るに，私は検討対象としてはCodepage 50221の方がまだよいと思いま > す． cp50221 互換とする場合、Windows では次のようにユーザ定義文字を 94x94 集合に収まらない領域を使って表現しているので、ここの所の扱いをどうする か明確にする必要があると考えています。 http://legacy-encoding.sourceforge.jp/wiki/index.php?plugin=attach&pcmd=open&file=cp5022x_cp932_map.png&refer=ISO-2022-JP-MS 提案2 では、7ビットJIS から Unicode へ変換する際には、cp5022x のユーザ 定義文字を受け付けるようにし、Unicode から 7ビットJISへの変換では、ユー ザ定義文字は変換しないようになっています。 提案2 http://legacy-encoding.sourceforge.jp/wiki/index.php?%C4%F3%B0%C62 成瀬さんも cp50221 を推していますが、ISO 2022 から逸脱している形でエン コードされているユーザ定義文字に関しては救うが、7ビットJIS へは変換し ないと考えていると理解して、提案2 のようにしました。 "NARUSE, Yui" <narus****@airem*****> wrote: > ユーザ定義文字が ISO 2022 から逸脱するのは、 > 確かに問題だとも思いますが、 > すでに逸脱した形でエンコードされたデータが > 相当数存在するシステムで用いられるのですし、 > ユーザ定義文字を出力しない CP50221 でいい気もします。 Sylpheed は現在、提案2 に近い実装になっています。 当初、Sylpheed での機種依存文字対応は、7bit-eucJP-ms のような実装になっ ていて、私が cp5022x の NEC選定IBM拡張文字対応のパッチを作成したとき、 cp5022x のユーザ定義文字を救うように実装しました。(送信はしません) 7bit-eucJP-ms(?) http://legacy-encoding.sourceforge.jp/wiki/index.php?7bit-eucJP-ms%28%3F%29 提案2 のようにする事で、受信したメールに cp5022x のユーザ定義文字が含 まれていて、それに続く文字が 2バイトコード文字の場合に、それらの文字ま で道連れで文字化けするという事を防げます。 cp50221 互換とする場合、このような動作が期待されるのか否かという所が気 になる所です。 ちなみに、libiconv に実装した ISO-2022-JP-MS は、cp5022x のユーザ定義 文字に関してノータッチです。 cp5022x のユーザ定義文字をケアしなかった場合、どのような文字化けになる かは、Outlook Express でユーザ定義文字の直後に2バイトコードの文字を何 文字か書いてメール送信し、Mozilla Thunderbird で受信すると確認できます。 ユーザ定義文字は、次のファイル(kanjitbl.txt) の 95区〜114区の文字のど れかをカットアンドペーストで Outlook Express に入力する事が出来ます。 http://www2d.biglobe.ne.jp/~msyk/text/kanjitbl.html -- 森山 将之 moriy****@mirac***** ミラクル・リナックス株式会社
