X-Mailer: Mozilla 4.6 [en] (WinNT; I)$B$N5-;v(B
to...@lbm.go.jp
「あ」が「#」の後に制御文字「^A」が続いたものに化ける現象の問題です。
In article <837rql$h4t$1...@narans.cc.nara-wu.ac.jp> ni...@ics.nara-wu.ac.jp writes:
>> 今でも高校や大学の漫画、アニメのサークル内のどっかに#^Aるとは思いますが。
>をダンプしてみると、私のところでも化けてるのですが。
>(当該行だけのダンプです)
>0000000 033 $ B : # $ G $ b 9 b 9 ; $ d
>0000020 B g 3 X $ N L ! 2 h ! " % " % K
>0000040 % a $ N % 5 ! < % / % k F b $ N
>0000060 $ I $ C $ + $ K # 001 $ k $ H $ O
>0000100 ; W $ $ $ ^ $ 9 $ , ! # 033 ( B \n
>0000120
> 56・57バイト目が # 001 になってます。ここが「あ」なら $ " になっている
>はずです。
以前にこの話題が出たときに「あ」以外の文字も化けたことがあります。
この化けた文字と「あ」との共通点は
シフトJIS表現の第２バイトが16進「A0」
であることでした。
このことから、以下のメカニズムで化けていることが推定されます。
(1)元々シフトJISでエンコードされたテキストの中に「あ」がある。
従って、「あ」の内部コードは、16進「82A0」である。
(2)第２バイトの16進「A0」はGRの空白文字であるので、
これをGLの空白文字である16進「20」に置き換える
という余計な「お節介」を、何れかのシステムが実行する。
(3)シフトJIS→ISO-2022-JP変換システムが、
前記(2)の処理で化けた結果である16進「8220」を変換しようとする。
(4)まず、第２バイトが16進「9F」未満であることから
JIS奇数区の文字であると判断する。
(5)前記(4)の判断に基づいて、
第１バイトから16進「81」を減じて２を乗じた結果に
16進「21」を加えるという通常の変換規則に従って、
第１バイトを16進「23」即ちASCIIの「#」と算出する。
(6)同じく前記(4)の判断に基づき、
16進「7E」以下の場合は16進「1F」を、
16進「80」以上の場合は16進「20」を減ずる
（シフトJISでは16進「7F」は使わない）
という通常の変換規則に従って、
第２バイトを16進「01」と算出する。
> これを「あ」と正しく読めるニュースリーダって、どんな処理をしているので
>しょうか…考えてみたけどわかりません。
このメカニズムで化けた文字を含む記事を読む環境が
シフトJISを内部コードとしている場合を考えてみましょう。
ISO-2022-JP→シフトJIS変換システムが、
化けた文字の第１バイトのみを見てJIS奇数区の文字であると判断し、
単純に上記(5)(6)の逆変換を行えば、16進「8220」が得られます。
これは不正なシフトJISコードですが、
もし表示環境が
第２バイトが低く外れている（16進「3F」未満）場合には、
その第２バイトの最上位ビットをONにして（＝16進「80」を加えて）
得られる文字を表示する
仕様になっている場合には、正しく「あ」と読めることになります。
In article <8383qj$jr8$2...@news00.iij4u.or.jp> koic...@ss.iij4u.or.jp writes:
>恐らく、日本語版では改修済みながら他の言語版ではそのままになっている
>Mozilla (= Netscape Messenger) のバグでしょう。
>以前「X-Mailer: Mozilla 4.04 [en] (Win95; I; 16bit)」な人が
>同じ文字化けの投稿をしていましたし。
賛成します。
上述の推定メカニズムから言って、
シングルバイト文字圏向けの仕様が紛れ込んだものと推測されますし……
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp