ヘッダの文字化けNo.00437
Firak さん 01/04/08 15:01
 
こんにちは

 お世話になります。

 ふぃらくともうします。メイリングリストのモディレータをしている
関係で、承認要求のメールを加工して再度送りなおすという作業をする
必要があります。
 承認要求のメールは、サブジェクトが以下のように、JISコード
で記述されたまま、本文に取り込まれて送られてくるので、エディタ
で不要部分をカット、リストに送りなおします。
 そのときサブジェクトが以下のようになっています。

Subject:  Re: [sannyas-jp] [snml 12795] =?iso-2022-jp?B?GyRCI08jcyNoI28hJSNj
GyhC?==?iso-2022-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=

 これを受信すると、=?iso-2022-jp? が付いているので、文字コード
を変換して正常に見えるようになるのですが、鶴亀では、ヘッダが長す
ぎるのが原因なのか、以下のようになってしまいました。

Subject:  [snml 12797] Re:  =?iso-2022-jp?B?GyRCI08jcyNoI28hJSNjGyhC?==?iso-
2022-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=

 [sannyas-jp] [snml 12795]は、削除するように、サーバ側の設定で
消えているのは正常なのですが、=?iso-2022-jp? 以下が正常にコード
変換されていないのは、何故でしょうか。
 ちなみに、このメールはサブジェクトのコード変換に失敗していま
すが、多くの場合は成功します。

 さらにこのメールをエクスポートで外に出し、再度取り込むと、サブ
ジェクトの文字化けは解消し以下のようになります。

Subject:  [snml 12797] Re:  Osho.comのマルチ メディア



[ ]
RE:00437 ヘッダの文字化けNo.00446
ひろ さん 01/04/09 00:30
 
 Firak さん今日は、ひろです。
 ちょっとお聞きしたいことがあります。
> Subject:  Re: [sannyas-jp] [snml 12795] =?iso-2022-jp?B?GyRCI08jcyNoI28hJSNj
> GyhC?==?iso-2022-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=
 このメールヘッダの実際の改行位置はどうなっているのでしょうか?
おそらく
>  さらにこのメールをエクスポートで外に出し、再度取り込むと、サブ
> ジェクトの文字化けは解消し以下のようになります。
とのことなので、元々は改行が無いと思いますが、それでは長すぎるので、
本来は、
> Subject:  [snml 12797] =?iso-2022-jp?B?GyRCI08jcyNoI28hJSNjGyhC?=
>  =?iso-2022-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=
というように処理すべきだと思います。
 よって相手のメーラかサーバの処理がおかしいのだと思います。

 さて
>  さらにこのメールをエクスポートで外に出し、再度取り込むと、サブ
> ジェクトの文字化けは解消し以下のようになります。
という事なので、実現は比較的簡単だと思いますが、こういった長いヘッダ
のデコードに対応すべきなのやら。

[ ]
RE:00437 ヘッダの文字化けNo.00461
秀まるお2 さん 01/04/09 11:00
 
 そちらの状況を確認させていただきますが、つまり、メール本文中に

> Subject:  XXXXXX

 と書かれたメールを受け取って、その「XXXXX」部分をカットアンドペーストなど
の方法によって「新規作成」のメールのSubject:ヘッダ部分に貼り付けて送信してい
るということですね。

 だとすると、つまり、題名として「=?iso-2022-jp?B?...」と書いた物は、そのま
ま送られる場合と、それがさらにiso-2022-jpでエンコードされて送られる場合と2
通りありえます。

 具体的には、題名が長い場合にはエンコードされてしまい、短い場合はエンコード
されずに送られます。

 で、解決方法としてどうすればいいかですが、鶴亀メールに限らず、本来なら本文
中に入っている

    Subject:  =?iso-2022-jp?B?....

 の部分をデコードしてから、そのデコードされた内容をあらためて題名として送る
のがいいと思います。

 そのためには、その本文中の「=?iso-2022-jp?B?...」をデコードする何かが必要
です。しかし、それは実際問題、難しい話です。

 マクロでなんとかなると思います。ってことで、挑戦してみます。

[ ]
RE:00437 ヘッダの文字化けNo.00464
秀まるお2 さん 01/04/09 11:08
 
 追加ですが、送信用メールのSubject:ヘッダに、「=?iso-2022-jp?B?...」と書い
て、それがそのままエンコードされずに送られる方(題名が短い場合)が、しいて言
うならバグです。

 ってことで、次のV1.03では「=?」を含む場合は必ずエンコードして送信するよう
にします。したがって、「=?iso-2022-jp?...」で届く内容を題名に貼り付けしたい
場合には、マクロか何かで必ずデコードすることが必要です。

 ってことで、まずはそのマクロを今から作ってみます。

[ ]
RE:00446 ヘッダの文字化けNo.00467
Firak さん 01/04/09 11:46
 
> ちょっとお聞きしたいことがあります。
>> Subject:  Re: [sannyas-jp] [snml 12795] =?iso-2022-jp?B?GyRCI08jcyNoI28hJSNj
>> GyhC?==?iso-2022-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=
> このメールヘッダの実際の改行位置はどうなっているのでしょうか?

 改行なしで一文になっています。


>本来は、
>> Subject:  [snml 12797] =?iso-2022-jp?B?GyRCI08jcyNoI28hJSNjGyhC?=
>>  =?iso-2022-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=
>というように処理すべきだと思います。
> よって相手のメーラかサーバの処理がおかしいのだと思います。

 僕もこんな長いサブジェクトなんか送って欲しくはないのですが、
最近は、とんでもない長いサブジェクトが飛んできます。

ふぃらく

[ ]
RE:00461 ヘッダの文字化けNo.00468
Firak さん 01/04/09 12:14
 
> そちらの状況を確認させていただきますが、つまり、メール本文中に
>
>> Subject:  XXXXXX
>
> と書かれたメールを受け取って、その「XXXXX」部分をカットアンドペーストなど
>の方法によって「新規作成」のメールのSubject:ヘッダ部分に貼り付けて送信してい
>るということですね。
>
 というより、メールの中にメールが入った状態で送られてくるので、
サーバが付加した情報を削り、さらに転送時についてしまった情報を
削って送ります。
 ちょっと判りにくいかもしれませんが例をあげると

 転送で未送信状態のメールを作ります、直接エディタで見るとこんな状態ですと

Message-Id: <200104090253.AA01291@shoza-762y46ws0.net.email.ne.jp>
From: Deva Firak <xxxxx@net.email.ne.jp>
Date: Mon, 09 Apr 2001 11:53:50 +0900
To: xxx@ml.asahi-net.or.jp
Subject: Fwd: BOUNCE sij: Approval required
MIME-Version: 1.0
X-Mailer: AL-Mail32 Version 1.12
Content-Type: text/plain; charset=iso-2022-jp

空白行1行をはさみ、ここから下がサーバから転送されるメールになります
>From sij-owner  Sat Apr  7 22:05:01 2001
Return-Path: <xxxxxx@chive.ocn.ne.jp>
Received: from chive.ocn.ne.jp (chive.ocn.ne.jp [210.232.239.75])
by ml.asahi-net.or.jp (8.8.8/3.7W) with ESMTP id WAA100926
for <xxx@ml.asahi-net.or.jp>; Sat, 7 Apr 2001 22:05:01 +0900
Received: from [211.122.97.115] (p114-dnb19tutuji.miyagi.ocn.ne.jp
[211.122.97.115])
by chive.ocn.ne.jp (8.9.1a/OCN/) with ESMTP id WAA29559
for <xxx@ml.asahi-net.or.jp>; Sat, 7 Apr 2001 22:12:14 +0900 (JST)
User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2106
Date: Sat, 02 Jan 1904 00:34:24 +0800
Subject: =?ISO-2022-JP?B?GyRCM1BAQyRORjsbKEo=?=
From: prayas <xxxxxx@chive.ocn.ne.jp>
To: <xxx@ml.asahi-net.or.jp>
Message-ID: <15570.226E%xxxxxx@chive.ocn.ne.jp>
In-Reply-To: <200103241254.xxxxxxxx@ml.asahi-net.or.jp>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit

 転送時についたヘッダを削除、最終的に、こんな形に強引に
整形してしまいます。From やら日付、Message-ID:は、そのまま
流用してしまいます。

>From sij-owner  Sat Apr  7 22:05:01 2001
Return-Path: <xxxxxx@chive.ocn.ne.jp>
Date: Sat, 02 Jan 1904 00:34:24 +0800
Subject: =?ISO-2022-JP?B?GyRCM1BAQyRORjsbKEo=?=
From: prayas <@chive.ocn.ne.jp>
To: <xxx@ml.asahi-net.or.jp>
Message-ID: <15570.226E%xxxxxx@chive.ocn.ne.jp>
In-Reply-To: <200103241254.xxxxxxxx@ml.asahi-net.or.jp>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-2022-JP"
Content-transfer-encoding: 7bit

 現在は、Al-mailから外部エディタで秀丸を開き直接編集していまし
たが、鶴亀メールは、不要なヘッダを削っていくと、かってに本文中
のヘッダがヘッダ情報として採用されるので、エディタを使って問題
なく作業できてしまいます。

 それほど長くないサブジェクトだと鶴亀でも問題なくエンコード
してくれるので、受信するとまともなサブジェクトになります。

 今回は、長すぎることが原因かと思われます。

 同じメールを別のメーラで受信すると、まともなサブジェクトに
なっています。

>
>    Subject:  =?iso-2022-jp?B?....
>
> の部分をデコードしてから、そのデコードされた内容をあらためて題名として送る
>のがいいと思います。
>
> そのためには、その本文中の「=?iso-2022-jp?B?...」をデコードする何かが必要
>です。しかし、それは実際問題、難しい話です。
>
 上記の例でわかるとおもいますが、僕としては、本文中の

 Subject:  =?iso-2022-jp?B?.... 

 を無条件に変換する必要はなく、送信するときサブジェクトがその
まま出て行って受信時に漢字になってくれれば良いので、本文中での
対応は、もっと別の問題を起こしそうなので、やらない方が良いとお
もいます。

[ ]
RE:00464 ヘッダの文字化けNo.00472
Firak さん 01/04/09 12:56
 
>
> ってことで、次のV1.03では「=?」を含む場合は必ずエンコードして送信するよう
>にします。したがって、「=?iso-2022-jp?...」で届く内容を題名に貼り付けしたい
>場合には、マクロか何かで必ずデコードすることが必要です。
>
 とくに送信時にエンコードしなくても、受信時にちゃんとシフト
JISになっていれば、問題は起きないとおもいます。

 わざわざ実装する必要は無いと考えますがいかがでしょうか?

 「=?」の後にデコードができないようなコード、たとえば
ラテンフォントが来てしまうこともあるとおもいますしね。

[ ]
RE:00472 ヘッダの文字化けNo.00480
秀まるお2 さん 01/04/09 13:21
 
>  わざわざ実装する必要は無いと考えますがいかがでしょうか?

 たしかにOutlook Expressで今「=?iso-2022^jp?...」という題名でメールを送った
ら、それはそのまま送られて、受信した側ではデコードされた物が出てきました。こ
れが普通の動作なのでしょか?>詳しい人

 だとしたら、例えば「=?」を含んでいる場合はあえてエンコードせずに送る仕様に
しないといけなくなります。???

 で、この件は別にして、一応デコード用のマクロを作りました。でも、結局デコー
ドそのものの処理はマクロでは無理だったので、tkinfo.dllにDecodeHeader関数を追
加して対処してしまいました。そういうわけで、次のV1.03からの対応となります。

 V1.03が出たらそれに入れ替えていただいて、ヘルプの「DecodeHeader」関数の
ページを開いてほしいです。そこにサンプルマクロがあるので、そのマクロをそのま
ま使えばいいです。

[ ]
RE:00480 ヘッダの文字化けNo.00481
"y.iida" さん 01/04/09 13:52
 
>>  わざわざ実装する必要は無いと考えますがいかがでしょうか?
>
> たしかにOutlook Expressで今「=?iso-2022^jp?...」という題名で
>メールを送ったら、それはそのまま送られて、受信した側ではデコード
>された物が出てきました。これが普通の動作なのでしょか?>詳しい人

全然詳しくないですけど、江戸だと一度日本語になってから(デコして)
再度エンコして送っているみたいです(送信済みは読める形になっています)

でも、わざわざ「=?iso-2022云々」を書く人もいないだろうから
あえて加工せずそのまま送ってしまっても良いと思いますね。

[ ]
RE:00480 ヘッダの文字化けNo.00488
Firak さん 01/04/09 17:03
 
>
> だとしたら、例えば「=?」を含んでいる場合はあえてエンコードせずに送る仕様に
>しないといけなくなります。???
>
 あえてなにもしなくても「=?」の後は通常の半角文字なので、送信
の際は意識しなくても問題は起こらないはずです。
 受信の際、=?・・・・ を参照して適切なエンコードをおこなって
いれば、指摘した事象はおきないとおもいます。
 
 結論は、デコードしてもデコードしなくても同じ、なら何もしない
方が余計な問題も起きないからいいに決まっているという意見です。
 でも、少しイレギラーなヘッダでエンコードがうまくいかなかった
のは何故でしょうか、この辺は対応が必要と思われます。


[ ]
RE:00488 ヘッダの文字化けNo.00491
秀まるお2 さん 01/04/09 17:26
 
>  でも、少しイレギラーなヘッダでエンコードがうまくいかなかった
> のは何故でしょうか、この辺は対応が必要と思われます。

 他の多くのメールソフトでは、例えばSubject:部分が「AAAAA…」ととても長い英
数字のみの場合でも、それをそのまま(80桁以内で改行せずに)送ってしまう仕様
のようです。

 鶴亀メールでもそのように(改行しないで送信)すれば解決すると思いますけど、
果たしてそれでいいのやら?。反論が無いようでしたらとりあえずそうします。

 今は、72桁を越える場合は英数字のみの場合でもiso-2022-jpにエンコードして
送ってしまってます。(折り返すためにはエンコードせざるを得ないので)

[ ]
RE:00480 ヘッダの文字化けNo.00492
ひろ さん 01/04/09 17:31
 
 秀まるおさん今日は、ひろです。
 単なる好奇心からの質問になっている気もしますが、
>  だとしたら、例えば「=?」を含んでいる場合はあえてエンコードせずに送る仕様に
> しないといけなくなります。???
 「=?」に限らず、ヘッダが ASCII で定義されているコードだけなら、エ
ンコードする必要はないのではありませんか?

[ ]
RE:00492 ヘッダの文字化けNo.00501
秀まるお2 さん 01/04/09 18:11
 
>  「=?」に限らず、ヘッダが ASCII で定義されているコードだけなら、エ
> ンコードする必要はないのではありませんか?

 世の中そうなってるみたいなので、そうします。

[ ]
RE:00491 ヘッダの文字化けNo.00503
Firak さん 01/04/09 18:20
 
>
> 他の多くのメールソフトでは、例えばSubject:部分が「AAAAA…」ととても長い英
>数字のみの場合でも、それをそのまま(80桁以内で改行せずに)送ってしまう仕様
>のようです。
>
 誤解されているようなので、僕の指摘は、以下のように長いヘッダ
を受信した場合にちゃんと日本語にならないでそのまま出力されるの
は困るという話で、送信時の話をしているのではありません。

Subject:  [snml 12797] Re:=?iso-2022-jp?B?GyRCI08jcyNoI28hJSNjGyhC?==?iso-20
22-jp?B?GyRCI28jbSROJV4layVBGyhCIBskQiVhJUclIyUiGyhC?=

> 鶴亀メールでもそのように(改行しないで送信)すれば解決すると思いますけど、
>果たしてそれでいいのやら?。反論が無いようでしたらとりあえずそうします。
>
> 今は、72桁を越える場合は英数字のみの場合でもiso-2022-jpにエンコードして
>送ってしまってます。(折り返すためにはエンコードせざるを得ないので)

 本来は、折り返すのが正しい仕様だと思いますが、最近のサーバは
80桁を超えても問題なく通過できるので、実際面で問題は起きない
とはおもいます。

 しかし鶴亀メーラでは、送信時、長いヘッダを80桁以下になるよ
うに折りたたんでいるとしたら、それは正しい処理をしているので、
変えない方が良いと思います。

 僕が指摘しているのは、他のヤクザなメーラが80桁を超えるサブ
ジェクト、しかもその中に、=?iso-2022-jp? が繰り返し出現するよ
うな状態で送りつけてきた場合でもちゃんと処理をして欲しいという
ことです。
 単に、上記事例がなんかよくわからない原因で偶発的におきたもの
なら、当面、対応の必要は無いとおもいます。
 =?iso-2022-jp? は、半角、全角を混在させると何回でも出てきま
す。

  

[ ]
RE:00503 ヘッダの文字化けNo.00535
秀まるお2 さん 01/04/10 09:16
 
>  しかし鶴亀メーラでは、送信時、長いヘッダを80桁以下になるよ
> うに折りたたんでいるとしたら、それは正しい処理をしているので、
> 変えない方が良いと思います。

 折り返すために、英数字のみであるにも関わらず「iso-2022-jp」とエンコードし
てしまっているので、必ずしも折り返す方が正解とも言えないです。特に今回のよう
なケースで問題が出るのも、無理矢理折り返しているからなので…。

 (早めにV1.03アップロードしたいんですけど、もうちょっとお待ちを)

[ ]