charset=iso-2022-jp (maybe) の付加につ - 秀丸メール・バグ関係 - スレッド09832, 2003/12/26

charset=iso-2022-jp (maybe) の付加につ

ぱとさん　03/12/26 10:33

秀まるおさん

鶴亀ユーザーのぱとと申します。

使っているのは、 V3.07β35 です。(これの前はβ28を使っていました。)

私は外国語スパム対策で以下のようなフィルタを使っています。

"Date:" が "0900" を含まないかつ
"Content-Type:" が "2022" を含まない
→ 既読+通知無し+"\\User\\ジャンクメール"に移動する

これで、これまでかなりうまく機能していました。しかし、鶴亀の最近のバージ
ョンでは、charset が指定されていないメールについては、鶴亀の側で、charset
を強制付加するようになったようなのですが、一定の html メールについて、
charset=iso-2022-jp (maybe) が付加されてしまいます。

ちょっと戸惑っているのですが、charset が不確実なら、これをあえて付加しな
いなどのオプションは難しいでしょうか？

----
ぱと

RE:09832 charset=iso-2022-jp (maybe) の

Iranoan さん　03/12/26 12:41

　ぱとさん今日は、Iranoan です。
> 鶴亀の側で、charset
> を強制付加するようになったようなのですが、一定の html メールについて、
> charset=iso-2022-jp (maybe) が付加されてしまいます。
>
> ちょっと戸惑っているのですが、charset が不確実なら、これをあえて付加しな
> いなどのオプションは難しいでしょうか？
　ぱとさんの使い方なら、新たにそれ用の振り分けを追加すればよいのでは?
HTML メールに限定したければ、``「X-Html」が「」でない'' とすれば良いで
すし。

RE:09833 charset=iso-2022-jp (maybe) の

ぱとさん　03/12/26 12:50

Iranoan さん

鶴亀ユーザーのぱとと申します。

>　ぱとさんの使い方なら、新たにそれ用の振り分けを追加すればよいのでは?
>HTML メールに限定したければ、``「X-Html」が「」でない'' とすれば良いで
>すし。

というか思いもかけなかった仕様変更に戸惑っているというところが正直なとこ
ろなのです。

もちろん、私の振分け設定をチューニングしていけば、今回の問題は回避できる
でしょうけれど、非常にシンプル(というのは、例えばよその環境に行ってもごく
簡単に再現できるという意味も含まれます。)であるところが気に入って使ってい
たものでしたし。

また、charset=iso-2022-jp (maybe) というのが、結果として間違った情報にな
ってしまっているのだからあえて付けないでもなあという気持ちもあります。

----
ぱと

RE:09832 charset=iso-2022-jp (maybe) の

秀まるお さん　03/12/26 12:57

　charsetを付加しない仕様に戻すのはよくないです。

　そもそも、外国からの英文のメールが、charset=iso-2022-jpと断定されてし
まうことが問題です。出来ればそれを直したいと思います。

　できればその問題のメールを僕に教えて欲しいです。

　１．問題のメールを選択して、「関連するメールを開く・受信ログ」とする。
　２．開く方法を聞かれるので、「そのまま開く」とする。
　３．出てきたエディタ上で、「ファイル・名前を付けて保存...」とする。
　４．保存されたファイルを添付ファイルにして、斉藤秀夫宛に送る。

　ということでお願いしたい所です。送り先は maruo@mitene.or.jp です。

　メールで送られない内容でしたら、こちらで適当なサンプルを探してみます。

RE:09835 charset=iso-2022-jp (maybe) の

ぱとさん　03/12/26 13:11

秀まるおさん

鶴亀ユーザーのぱとと申します。

>　charsetを付加しない仕様に戻すのはよくないです。
>
>　そもそも、外国からの英文のメールが、charset=iso-2022-jpと断定されてし
>まうことが問題です。出来ればそれを直したいと思います。

対応いただけるようでありがとうございます。押し迫ってから、こんな投稿して
しまってごめんなさい。

>　できればその問題のメールを僕に教えて欲しいです。
>
>　１．問題のメールを選択して、「関連するメールを開く・受信ログ」とする。
>　２．開く方法を聞かれるので、「そのまま開く」とする。
>　３．出てきたエディタ上で、「ファイル・名前を付けて保存...」とする。
>　４．保存されたファイルを添付ファイルにして、斉藤秀夫宛に送る。
>
>　ということでお願いしたい所です。送り先は maruo@mitene.or.jp です。
>
>　メールで送られない内容でしたら、こちらで適当なサンプルを探してみます。

それでは該当するメールを何点か送付させていただきます。スパムですので、も
ちろん送って困るような内容のものはありません。

よろしくお願いします。

----
ぱと

RE:09836 charset=iso-2022-jp (maybe) の

秀まるお さん　03/12/26 14:30

　サンプルありがとうございます。

　charset=の指定が無くて、日本語または欧文のメール（文字コード0x80以上を
含むメール）での自動判定のことばかり考えてまして、今回のような単純な英文
メールのことをすっかり忘れてました。

　これはこれで、charset=us-ascii (maybe) を付け加えるように修正させてい
ただきます。

RE:09840 charset=iso-2022-jp (maybe) の

ぱとさん　03/12/26 14:35

秀まるおさん

鶴亀ユーザーのぱとと申します。

>　charset=の指定が無くて、日本語または欧文のメール（文字コード0x80以上を
>含むメール）での自動判定のことばかり考えてまして、今回のような単純な英文
>メールのことをすっかり忘れてました。
>
>　これはこれで、charset=us-ascii (maybe) を付け加えるように修正させてい
>ただきます。

秀まるおさんのコメントによると、それほどややこしくなく、私が希望する形で
の対応が取れそうなのでほっとしました。

実際の作業はもちろん、来年以降で十分です。

そろそろ仕事納めにして下さいな。

----
ぱと

RE:09841 charset=iso-2022-jp (maybe) の

秀まるお さん　03/12/26 14:46

> そろそろ仕事納めにして下さいな。

　サイトー企画は１２月３０日まで仕事の予定です。

RE:09835 charset=iso-2022-jp (maybe) の

Iranoan さん　03/12/26 18:04

　ぱとさん今日は、Iranoan です。
> もちろん、私の振分け設定をチューニングしていけば、今回の問題は回避できる
> でしょうけれど、非常にシンプル(というのは、例えばよその環境に行ってもごく
> 簡単に再現できるという意味も含まれます。)であるところが気に入って使ってい
> たものでしたし。
　こちらへの投稿=常連、ということで(^^)、付加しているのはそれなりの理
由があることは、履歴や過去の投稿内容から解り、
> 　charsetを付加しない仕様に戻すのはよくないです。
ということは理解いただけるだろうということで、先の投稿をしました。
　って、次のヴァージョンでは us-ascii になりそうなので、問題解決のよう
ですね。

RE:09840 charset=iso-2022-jp (maybe) の

ぱとさん　04/01/05 10:31

秀まるおさん鶴亀フォーラムの皆様、本年もよろしくお願いいたします。

鶴亀ユーザーのぱとと申します。

>　サンプルありがとうございます。
>
>　charset=の指定が無くて、日本語または欧文のメール（文字コード0x80以上を
>含むメール）での自動判定のことばかり考えてまして、今回のような単純な英文
>メールのことをすっかり忘れてました。
>
>　これはこれで、charset=us-ascii (maybe) を付け加えるように修正させてい
>ただきます。

この件の処理の変更ありがとうございました。多くの英文スパムに、charset=us-
ascii (maybe) がつくようになったので、私のスパムフィルターも元のように使
うことができるようになりました。(Ver3.10で確認)

が、まだ(今日受信した1500通！ほどの英文スパムのうち50通ほどの)いくつかの
メールについては、charset=iso-2022-jp (maybe) と判定されてしまったような
ので、サンプルのログを秀まるおさん宛に送らせていただきます。

よろしくお願いいたします。

----
ぱと

RE:09878 charset=iso-2022-jp (maybe) の

秀まるお さん　04/01/05 14:19

　毎度情報ありがとうございます。送って頂いたメールがすべて欧文扱いとなる
ように修正できました。

　自動判定の処理を改良した訳じゃなくて、特定の条件下で欧文か日本語かの自
動判定をする以前に日本語メール扱いとなってました。そこを修正しました。

　これとは別に、欧文かどうかの自動判定も、昨日少しいじりました。具体的に
は、Unicodeに変換して0x7F～0x9Fまでの文字（Unicodeでの制御コードらし
い？）になる文字を含む場合は、その文字コードを候補外とするようにしました。
さらに、0x80以上の文字コードが８個以上連続する場合は欧文じゃないという判
定も入れました。これで、タイ語メールや中国語メールが欧文と誤判定される
ケースが減りました。

RE:09880 charset=iso-2022-jp (maybe) の

Kengo さん　04/01/06 12:09

3.11で、
・Content-Type: 無し
・本文の大部分がASCIIで、一部にISO-2022-JPを含む
なメールが charset=iso-8859-1 (maybe) と判定されていました。
同種の他のメールでは、期待通り charset=iso-2022-jp (maybe) と
判定されるものもありますので、「欧文かどうかの自動判定」に
よるものだと思います。

問題のメールは、機械的に自動送信されるもので、iso-8859-1 と
判定されても特に不都合は無いのですが、一応別便で送らせて
いただきます。
「対処しない」でも結構ですので。

RE:09888 charset=iso-2022-jp (maybe) の

秀まるお さん　04/01/06 14:54

　わざわざデータ送っていただきありがとうございます。

　カタカナやひながらのみだと、どうしても欧文文字と文字コードが重なって自
動判定が難しいです。

　カタカナ／ひらがなが、それなりの文字数連続してたら日本語扱いにするよう
にしてるんですが、その辺の判定をもうすこし改良してみます。

RE:09891 charset=iso-2022-jp (maybe) の

秀まるお さん　04/01/06 17:06

　全角ひらがなの１バイト目の0x82や、カタカナの0x83の文字は、欧文では極め
て使用頻度の低い文字みたいなので、ひらがなの２文字連続またはカタカナの２
文字連続を見つけたら、ほとんどそれは日本語という扱いにしてみます。

　さらに、秀丸でやってる処理の、JIS第１水準と第２水準の文字の比率を調べ
る方法も取り入れました。これでさらに精度アップとなる予定です。