アカウント名:
パスワード:
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは最初に検出したエンコードで全体をデコードするためsubjectのエンコードと異なるcontent-typeでは問題がでるなど、MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などでエンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、メール全体が同じエンコーディングであることを仮定したハックによる対応が行われているものが散在し、Content-Typeに従った対応が全般に渡ってされていると仮定するのは無理があります。
世の中に出回っている暗黙の了解の所為でこの手の問題は表面化しないんでしょう。
普通のユーザは、デフォルトの設定でメールが表示できれば正常動作と考えるのが普通ですから。
「そういえば規格上はこういうことができるはずだよな」と弄ってみるととたんに爆発。しかも周りがことごとく間違っているからそれに合わせるしかなく手も足も出ない。
そういえば、暗黙の了解とか不文律に寄りかかってしまうと、もうそこから進まなくなってしまうんですよね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
未知のハックに一心不乱に取り組んだ結果、私は自然の法則を変えてしまった -- あるハッカー
現状のContent-Type対応は十分ではありません (スコア:4, 参考になる)
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは
最初に検出したエンコードで全体をデコードするため
subjectのエンコードと異なるcontent-typeでは問題がでるなど、
MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などで
エンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、
メール全体が同じエンコーディングであることを仮定したハックによる
対応が行われているものが散在し、Content-Typeに従った対応が
全般に渡ってされていると仮定するのは無理があります。
Re:現状のContent-Type対応は十分ではありません (スコア:1)
世の中に出回っている暗黙の了解の所為でこの手の問題は表面化しないんでしょう。
普通のユーザは、デフォルトの設定でメールが表示できれば正常動作
と考えるのが普通ですから。
「そういえば規格上はこういうことができるはずだよな」と弄ってみるととたんに爆発。
しかも周りがことごとく間違っているからそれに合わせるしかなく手も足も出ない。
そういえば、暗黙の了解とか不文律に寄りかかってしまうと、
もうそこから進まなくなってしまうんですよね。