アカウント名:
パスワード:
Mozilla系のMUAはRFCに近い実装ですが Outlook Expressは最初に検出したエンコードで全体をデコードするためsubjectのエンコードと異なるcontent-typeでは問題がでるなど、MIMEの扱いはぼろぼろです。
さらにIMAPでは検索などでサーバ側でもMIMEを扱うためこちらの対応状況も問題になります。
メーリングリストでも、アーカイブ作成時の変換やSubjectの書換などでエンコード/デコードが必要となります。
これらについて、現状ではiso-2022-jpであることや、メール全体が同じエンコーディングであることを仮定したハックによる対応が行われているものが散在し、Content-Typeに従った対応が全般に渡ってされていると仮定するのは無理があります。
そういう変なメールを作成するメールソフト
というのが、まさにOutlookなのが問題なのですよ。
……で、しかも、相手が同様の対応をすることを期待するから:
……ということになるわけで。はあ。
曖昧な書き方をしていたので補足します。
ShiftJISそのままではないですね。
Content-Transfer-Encodingの話ではなく、Content-Typeの話をしたつもりでした。 つまり、Outlookでは、送るときは
という動作をするのです。また、受け取るときは
のです。
という動作をしてくれるなら文句は言いません。
本文に異なる文字コードで混ざると言っているのだから。
これについては #1494067 [srad.jp]参照。
たびたび誤解を招く書き方をしてすみません。添付ファイルのContent-Typeで指定されるべき「文字エンコーディング」と、それを伝送路上に流すときのContent-Transfer-Encodingとを分離して、前者の話だけをしたつもりでした。私の書き方が足りなかったので、元ACさんはContent-Transfer-Encodingの話だと思われたのでしょう。
Outlookは、Shift_JISの添付ファイルを送る際に、Content-Transfer-Encodingをquoted-printableにしているということですね。それはいいのです。8bitテキストを生で伝送路上に流すべきではない、というのもいいのです。
JISで書いたテキストを添付して送ると、メモ帳で化けるという話ですか? それは、Outlookのお仕事ですか?
Outlookのお仕事だと思います。少なくとも、Content-Type: text/plain; charset=iso-2022-jpと添付ファイルのヘッダーに書いてあったのであれば、ファイルを「開く」または「保存する」ときにはコード変換すべきでしょう。送ってくる相手はShift_JISやUTF-8で送ってくれるとは限らないわけですから。
いくらテキストデータとはいえ、本文とは別に添付するのですから、元の通りに 受信者が復元できればいいですし、そうすべきです。
たとえば、Windowsでは改行がCRLFですけれどUNIXではLFだったりするので、テキストファイルであっても、場合によっては、最低限のデータ変換は必要になるのです(ネットワークに流すときの改行はCRLFにする必要があります)。受信側のOSがUNIXで、ユーザーがEUC-JPの文字エンコーディングを使っているのであれば、受け取ったユーザーは、送られてきたテキストファイルは改行をLFにして、文字エンコーディングはEUC-JPにしたいと思うでしょう。逆に、Windowsで受信するときには、ユーザーは、テキストファイルは改行をCRLFにして、文字エンコーディングはShift_JISにして欲しいと思うでしょう。
もし、勝手な変換をされたくないなら、Content-Typeをtext/plainではなくapplication/octet-streamにすべきなのです。
より多くのコメントがこの議論にあるかもしれませんが、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の場合、ShiftJISのテキストファイルを添付すると
Content-Transfer-Encoding: quoted-printable
と付けられて、7bitに変換されてます。
ShiftJISそのままではないですね。
添付ファイルなので本文の表示とは無関係で文字化けには影響しませんし、
添付ファイルなので、あとは取りだしたメールソフトやOSがこのファイルを
どう処理するか次第。
補足すると、Outlookでも設定を変えればBASE64に変換して添付することも
もちろんできます。
それでも他のメールソフトより変ですか?
#正しい情報でも、MS製品バッシングに対する反論はプラスモデされませんねえ。
Re:現状のContent-Type対応は十分ではありません (スコア:1)
曖昧な書き方をしていたので補足します。
Content-Transfer-Encodingの話ではなく、Content-Typeの話をしたつもりでした。 つまり、Outlookでは、送るときは
という動作をするのです。また、受け取るときは
のです。
という動作をしてくれるなら文句は言いません。
これについては #1494067 [srad.jp]参照。
テストしてみましたか? (スコア:0)
> 曖昧な書き方をしていたので補足します。
> ShiftJISそのままではないですね。
> Content-Transfer-Encodingの話ではなく、Content-Typeの話をしたつもりでした。つまり、Outlookでは、送るときは
ですから、文字コードは知らんけどquoted-printableで送る、という
印になっているのですから、そんなに問題なの?って書いたつもりでした。
> □ 添付ファイルはContent-Type: text/plainでcharset指定がない。中身はShift_JISそのまま
何度も書くようですが、
Content-Transfer-Encoding: quoted-printab
Re:テストしてみましたか? (スコア:1)
たびたび誤解を招く書き方をしてすみません。添付ファイルのContent-Typeで指定されるべき「文字エンコーディング」と、それを伝送路上に流すときのContent-Transfer-Encodingとを分離して、前者の話だけをしたつもりでした。私の書き方が足りなかったので、元ACさんはContent-Transfer-Encodingの話だと思われたのでしょう。
Outlookは、Shift_JISの添付ファイルを送る際に、Content-Transfer-Encodingをquoted-printableにしているということですね。それはいいのです。8bitテキストを生で伝送路上に流すべきではない、というのもいいのです。
Outlookのお仕事だと思います。少なくとも、Content-Type: text/plain; charset=iso-2022-jpと添付ファイルのヘッダーに書いてあったのであれば、ファイルを「開く」または「保存する」ときにはコード変換すべきでしょう。送ってくる相手はShift_JISやUTF-8で送ってくれるとは限らないわけですから。
たとえば、Windowsでは改行がCRLFですけれどUNIXではLFだったりするので、テキストファイルであっても、場合によっては、最低限のデータ変換は必要になるのです(ネットワークに流すときの改行はCRLFにする必要があります)。受信側のOSがUNIXで、ユーザーがEUC-JPの文字エンコーディングを使っているのであれば、受け取ったユーザーは、送られてきたテキストファイルは改行をLFにして、文字エンコーディングはEUC-JPにしたいと思うでしょう。逆に、Windowsで受信するときには、ユーザーは、テキストファイルは改行をCRLFにして、文字エンコーディングはShift_JISにして欲しいと思うでしょう。
もし、勝手な変換をされたくないなら、Content-Typeをtext/plainではなくapplication/octet-streamにすべきなのです。
Re: (スコア:0)
したいという固定観念があるようですね。
> たびたび誤解を招く書き方をしてすみません。
いいえ、私が誤解しているのではなく、あなたが誤解しています。
>添付ファイルのContent-Typeで指定されるべき「文字エンコーディング」と、それを
> 伝送路上に流すときのContent-Transfer-Encodingとを分離して、前者の話だけをしたつもりでした。
それではだめです。
もともとは、一つの本文テキストに複数の文字コードが混ざる話でした。
別次元の添付ファイルに関して変だ、ということ自体が間違っています。
>