MORIYAMA Masayuki
moriy****@mirac*****
2006年 4月 10日 (月) 11:23:20 JST
森山です。 > 森山さんの > http://webdav-jp.ml.nemui.org/msg00810.html > にもう少し情報がありましたが、Outlook Express の実装は95区以降が > 入力されることを想定していない単純なバグ、Becky! は独自路線だと > 思えます。 > > それらは個々のアプリケーションの問題で、送られてきたデータを救済 > するとかよりも、アプリケーション側に修正してもらうべき話だと > 思います。 Becky! に対しては、次の例を出して修正依頼を出しておきました。 http://www2d.biglobe.ne.jp/~msyk/cgi-bin/charcode/bbs.cgi?c=gr&n=361 次期バージョンで修正するとの事です。 >>Becky! で シフトJIS の0xF040(0xF09F) 以上のコードを処理した時のコード >>を読める必要はないと思っています。 > > > Becky! に限らず 95区以降読める必要はないでしょうし、 > 通す(送る)必要もないはずですが...。 CP5022X でのユーザ定義文字は、JIS X 0208 が G0 集合に指示されている状態 で、0x7F〜0x92 が来るわけですが、これを ISO 2022 として正しく解釈して1バ イトコードとして処理すると、ユーザ定義文字の2バイト目が取り残されてしま います。その取り残されたバイトを JIS X 0208 の 1 バイト目だとして処理す る事になってしまいます。その事により、それ以降の文字が文字化けしてしま うという事になってしまいます。 CP932 の F040 (ユーザ定義文字) 82A0 (あ) を CP5022X へ変換し、それを正規 の ISO 2022 で解釈すると次のようになります。 あ ----- ----- CP932 F0 40 82 A0 ----- ----- CP5022X 1B 24 42 7F 21 24 22 -- ----- -- ↑ ↑ │ ユーザ定義文字の2 バイト目と次の文字の1バイト目 │ が JIS X 0208 の文字として解釈されてしまう。 │ 1バイトコード(制御コード)として解釈 ユーザ定義文字のエスケープシーケンスとして、ESC $ ( ? を使う ISO-2022-JP-MS では、CP5022X のユーザ定義文字は救済しない代わりに、 ISO/IEC 2022(JIS X 0202) の枠組みの中で、ユーザ定義文字を安全に扱うた めの方法を提示してみました。 RFC化の事を視野に入れて、ISO 2022 から逸脱するものは排除して、新たに ISO 2022 の枠組みの中で、ユーザ定義文字の扱いを提示することにより、 Windows のCP5022X のような実装を行う事への歯止めにならないかとも考えま した。 しかし、「過去の資産の継承」を考えるなら、CP5022X でのユーザ定義文字に よって、ユーザ定義文字に続く JIS X 0208 の文字が文字化けしてしまう事を 避ける意味でも、ISO 2022 から逸脱している CP5022X のユーザ定義文字を Unicode に変換できるようにしておいた方が良いのかもしれません。 (この場合、Unicode から 7ビットJIS への変換では、ユーザ定義文字は変換 しない。) -- 森山 将之 moriy****@mirac***** ミラクル・リナックス株式会社
