簡単に文字コードを変えられ無いか?No.00004
Iranoan さん 06/12/27 18:14
 
 秀まるおさん今日は、Iranoan です。
 ヘッダの記述と実際のコードが一致していないとき、簡単に適切なコードに
変換することは出来ないでしょうか?

 具体的には、例えばヘッダに
Content-Type: text/plain; charset=iso-2022-jp
とあっても、実際にはエンコードされていない EUC で送られてきたメールが
あるとします。このメールは、「文字コード」は既に「日本語」になっている
ので、ここの認識は意味を持ちません。現状は、ログを開いてヘッダを
Content-Type: text/plain; charset=euc-jp
と書き直してから、「受信解析のやり直し」をしています。

 もちろんこれは、第一に送信側が悪い事は解っています。また個人的にはこ
の様なメールの数も多くないので、それほど困っているわけではありません。
しかし、多くの人はこんな細かいことは気が付きませんし、秀丸エディタの
「エンコードの種類」の様に、「自動判定で読込し直し」の様に、簡単にでき
れば、多くの人にとって有り難いのではないでしょうか?

[ ]
RE:00004 簡単に文字コードを変えられ無いNo.00005
秀まるお さん 06/12/27 20:38
 
 「受信解析のやり直し」で文字コードを強制的に指定してやるって手があるか
もしれませんが…。やるとしたら、「受信解析のやり直し - 文字コードはユー
ザー指定」とかってコマンドでも追加してやるのでしょうか。

 現状でなんとかユーザー様に対処してもらうとしたら、「ログをOutlook
Expressで開く」としてからエンコードをいろいろいじって見てもらうしか無い
という形になってしまいます。


 こういう、文字コードがおかしいメールというのは昔は多く存在していつつも、
インターネットメールが枯れた技術になった今となっては滅多に出てくる物じゃ
ないと思うので、今さらそういうややこしい対応をするというのもどうかと思い
ますけど。というか、一応現状でも、文字コードの指定と実情が合ってるかどう
か、例えばEUCと指定されてても本当はShift-JISなんじゃないかと疑ってやるよ
うな処理までやってるので、しいて今さらややこしいコマンドを追加してまで対
応するのはどうかなぁと思います。

 しいてなんとかして欲しいということであれば、その辺の自動判定の精度向上
に努めるというか、具体的にそういうEUC指定だけどShiftJIS文字コードのメー
ルとかのサンプルをもらって対応するって方がいいんじゃないかと思います。

[ ]
RE:00005 簡単に文字コードを変えられ無いNo.00006
Iranoan さん 06/12/27 23:35
 
 秀まるおさん今日は、Iranoan です。
>  しいてなんとかして欲しいということであれば、その辺の自動判定の精度向上
> に努めるというか、具体的にそういうEUC指定だけどShiftJIS文字コードのメー
> ルとかのサンプルをもらって対応するって方がいいんじゃないかと思います。
 そうですね。MUA はエディタと違って、「文字コード」という言葉を知らな
い人も使うでしょうから、そのほうが良いかもしれませんね。
 ただ困っているのは、「EUC 指定だけど....」では無く、
>  具体的には、例えばヘッダに
> Content-Type: text/plain; charset=iso-2022-jp
> とあっても、実際にはエンコードされていない EUC で送られてきたメール
です。そもそも Shift_JIS は疑っても、EUC の可能性は疑っていないのでは?
 出来れば、日本語の場合、
Content-Type: text/plain; charset=iso-2022-jp
とあるのに、本文エリアにあるはずのエスケープ・コードが無ければ、秀丸エ
ディタと同じ方法でよいので、Shift_JIS と EUC の自動認識をしていただけ
ればと思います。

[ ]
RE:00006 簡単に文字コードを変えられ無いNo.00007
秀まるお さん 06/12/28 13:00
 
 具体的なサンプルが分からないとなんですが、文字コード指定がiso-2022-jp
となっていたとしても、EUCコードかどうかの自動判定をしています。具体的に
は、iso-2022-jp指定されたメール本文から\x1Bの文字コードを検索してそれが
無ければ、

    if( CheckMaybeEUC( pszBody ) && !CheckMaybeSjis( pszBody ) ) {
        EUCと判定
    }

 みたいな処理をしています。

 CheckMaybeEUC/CheckMaybeSjisの関数内部がどういう判定になってるかまで詳
しく書いてたら大変なので書きませんけど。

 っと自動判定しても、ヘッダの部分はまた別なので、ヘッダは化けるケースは
あります。(僕の所でテストしたらヘッダだけは化けた)



 ということで、具体的にダメなケースのサンプルメールを僕に送って頂ければ、
それなりに対応可能なら対応出来るし、対応出来なければ対応しないです。

[ ]
RE:00007 簡単に文字コードを変えられ無いNo.00008
秀まるお さん 06/12/28 15:25
 
 一応コメントしますが、この件は秀丸メール側のEUC文字コード判定のバグと
いうことでした。3バイトEUC文字が「EUC文字として不正である」と判断されて
しまってました。

 次のバージョン(V4.70β11)で直します。

[ ]