アカウント名:
パスワード:
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは最初に検出したエンコードで全体をデコードするためsubjectのエンコードと異なるcontent-typeでは問題がでるなど、MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などでエンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、メール全体が同じエンコーディングであることを仮定したハックによる対応が行われているものが散在し、Content-Typeに従った対応が全般に渡ってされていると仮定するのは無理があります。
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは 最初に検出したエンコードで全体をデコードするため subjectのエンコードと異なるcontent-typeでは問題がでるなど、 MIMEの扱いはぼろぼろです。
とは言いますが、そもそもSubjectフィールドとContent-Typeフィールドは、同じ形式でエンコードしておくべきでは？ 更に言えば、Subeject/Content-Typeフィールドに別々のエンコードをしてしまうというのは、 新米Emacsen使いな方々の設定ミスが主な原因と記憶していましたが。 Emacsを利用していると、各国語のエンコードが入り混ったメールでも良き
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
現状のContent-Type対応は十分ではありません (スコア:4, 参考になる)
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
最初に検出したエンコードで全体をデコードするため
subjectのエンコードと異なるcontent-typeでは問題がでるなど、
MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
エンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、
メール全体が同じエンコーディングであることを仮定したハックによる
対応が行われているものが散在し、Content-Typeに従った対応が
全般に渡ってされていると仮定するのは無理があります。
Re: (スコア:1, 興味深い)
とは言いますが、そもそもSubjectフィールドとContent-Typeフィールドは、同じ形式でエンコードしておくべきでは？
更に言えば、Subeject/Content-Typeフィールドに別々のエンコードをしてしまうというのは、 新米Emacsen使いな方々の設定ミスが主な原因と記憶していましたが。
Emacsを利用していると、各国語のエンコードが入り混ったメールでも良き
Re:現状のContent-Type対応は十分ではありません (スコア:1)
MIMEのミニマムな文字集合を使用すべし、という原則に従うと必ずしも同じとならんでも仕方ありません。
(元々ヘッダとボディの扱いが独立なのですから、非US-ASCII文字のエンコード方法については。)