アカウント名:
パスワード:
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは最初に検出したエンコードで全体をデコードするためsubjectのエンコードと異なるcontent-typeでは問題がでるなど、MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などでエンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、メール全体が同じエンコーディングであることを仮定したハックによる対応が行われているものが散在し、Content-Typeに従った対応が全般に渡ってされていると仮定するのは無理があります。
そういう変なメールを作成するメールソフト
というのが、まさにOutlookなのが問題なのですよ。
……で、しかも、相手が同様の対応をすることを期待するから:
……ということになるわけで。はあ。
今やってみましたが、Outlook 2003からUTF-8のテキストファイルを添付して送信し、OSXのMail.appで開きましたが普通に開けます。テキストファイルのエンコーディングはUTF-8のままです。添付ファイルのnameはiso-2022-jpでエンコードされており、ファイル自体はContent-Transfer-Encoding: base64Content-Disposition: attachment;です。
何が問題なんでしょ?
添付ファイルのContent-Typeはどうなっていましたか?
Content-Type: text/plain; charset=utf-8
ならいいんですが、往々にしてcharsetが付いていないのですよ。
添付ファイルのnameはiso-2022-jpでエンコードされており、
nameパラメタにiso-2022-jpがそのままエンコードされていたのでしょうか。 それとも、=?ISO-2022-JP?B?....?=みたいな形式になっていたのでしょうか。 前者ならば規約違反です。
Content-Disposition: attachment;
このヘッダーフィールドにfilenameパラメタは付いていませんでしたか? RFC2231では、ファイル名はContent-Dispositionにfilenameパラメタで付けることになっているのです。
とりあえず、どのバージョンのOutlookの話をしているか(SPも含めて)はっきりした方がいいぞ。バージョン間やSP前後での非互換は日常茶飯事だからな。
あと、Outlook Expressの話じゃないよな? OutlookとOutlook Expressは、JavaとJavascriptくらい違うぞ。
>添付ファイルのContent-Typeはどうなっていましたか?>>Content-Type: text/plain; charset=utf-8>ならいいんですが、往々にしてcharsetが付いていないのですよ。
ファイルの文字コードを正確に判断できるアプリケーションを私は一つも知りません。Outlookは添付ファイルの中身が何かなんてわからないんじゃないですか?Content-Type: text/plain;は単に拡張子がtxtだからつけたんでしょう。
ちなみに、notepad.exeをnotepad.txtにリネームして添付してもContent-Type: text/plain;になります。
本当にOutlookの問題ですか?
>nameパラメタにiso-2022-jp
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
現状のContent-Type対応は十分ではありません (スコア:4, 参考になる)
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
最初に検出したエンコードで全体をデコードするため
subjectのエンコードと異なるcontent-typeでは問題がでるなど、
MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
エンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、
メール全体が同じエンコーディングであることを仮定したハックによる
対応が行われているものが散在し、Content-Typeに従った対応が
全般に渡ってされていると仮定するのは無理があります。
Re: (スコア:0)
> 最初に検出したエンコードで全体をデコードするため
> subjectのエンコードと異なるcontent-typeでは問題がでるなど、
> MIMEの扱いはぼろぼろです。
まず、Mozilla系を持ち上げてOEをコケ下ろす前に、そういう変な
メールを作成するメールソフトを糾弾すべきじゃないかと思うのは
私だけでしょうか?
タレコミ人のケースでも、テキストエディタで書いたものを
貼り付けたら別の文字コードで混ざったんですよね。
Windowsではあまり考えられないケースですが、Linuxとか使ってた
ということではないですか?
タレコミ人の書きようも、「そんなの読めないほうが悪いんじゃね?」
とでも言いたげに感じられるし。
Re: (スコア:2, 参考になる)
というのが、まさにOutlookなのが問題なのですよ。
……で、しかも、相手が同様の対応をすることを期待するから:
……ということになるわけで。はあ。
Re: (スコア:0)
今やってみましたが、Outlook 2003からUTF-8のテキストファイルを添付して送信し、OSXのMail.appで開きましたが普通に開けます。
テキストファイルのエンコーディングはUTF-8のままです。
添付ファイルのnameはiso-2022-jpでエンコードされており、
ファイル自体は
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
です。
何が問題なんでしょ?
Re:現状のContent-Type対応は十分ではありません (スコア:1)
添付ファイルのContent-Typeはどうなっていましたか?
ならいいんですが、往々にしてcharsetが付いていないのですよ。
nameパラメタにiso-2022-jpがそのままエンコードされていたのでしょうか。 それとも、=?ISO-2022-JP?B?....?=みたいな形式になっていたのでしょうか。 前者ならば規約違反です。
このヘッダーフィールドにfilenameパラメタは付いていませんでしたか? RFC2231では、ファイル名はContent-Dispositionにfilenameパラメタで付けることになっているのです。
Re: (スコア:0)
とりあえず、どのバージョンのOutlookの話をしているか(SPも含めて)はっきりした方がいいぞ。バージョン間やSP前後での非互換は日常茶飯事だからな。
あと、Outlook Expressの話じゃないよな? OutlookとOutlook Expressは、JavaとJavascriptくらい違うぞ。
Re: (スコア:0)
>添付ファイルのContent-Typeはどうなっていましたか?
>>Content-Type: text/plain; charset=utf-8
>ならいいんですが、往々にしてcharsetが付いていないのですよ。
ファイルの文字コードを正確に判断できるアプリケーションを私は一つも知りません。
Outlookは添付ファイルの中身が何かなんてわからないんじゃないですか?
Content-Type: text/plain;は単に拡張子がtxtだからつけたんでしょう。
ちなみに、notepad.exeをnotepad.txtにリネームして添付してもContent-Type: text/plain;になります。
本当にOutlookの問題ですか?
>nameパラメタにiso-2022-jp