アカウント名:
パスワード:
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では、送るときは
という動作をするのです。また、受け取るときは
たびたび誤解を招く書き方をしてすみません。添付ファイルのContent-Typeで指定されるべき「文字エンコーディング」と、それを伝送路上に流すときのContent-Transfer-Encodingとを分離して、前者の話だけをしたつもりでした。私の書き方が足りなかったので、元ACさんはContent-Transfer-Encodingの話だと思われたのでしょう。
Outlookは、Shift_JISの添付ファイルを送る際に、Content-Transfer-Encodingをquoted-printableにしているということですね。それはいいのです。8bitテキストを生で伝送路上に流すべきではない、というのもいいのです。
JISで書いたテキストを添付して送ると、
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
現状の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: (スコア:1)
曖昧な書き方をしていたので補足します。
Content-Transfer-Encodingの話ではなく、Content-Typeの話をしたつもりでした。 つまり、Outlookでは、送るときは
という動作をするのです。また、受け取るときは
テストしてみましたか? (スコア: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テキストを生で伝送路上に流すべきではない、というのもいいのです。
Re:テストしてみましたか? (スコア:0)
したいという固定観念があるようですね。
> たびたび誤解を招く書き方をしてすみません。
いいえ、私が誤解しているのではなく、あなたが誤解しています。
>添付ファイルのContent-Typeで指定されるべき「文字エンコーディング」と、それを
> 伝送路上に流すときのContent-Transfer-Encodingとを分離して、前者の話だけをしたつもりでした。
それではだめです。
もともとは、一つの本文テキストに複数の文字コードが混ざる話でした。
別次元の添付ファイルに関して変だ、ということ自体が間違っています。
>> JISで書いたテキストを添付して送ると、メモ帳で化けるという話ですか?
>> それは、Outlookのお仕事ですか?
> Outlookのお仕事だと思います。
ですから、違いますって。
添付ファイルは、文字どおり、メールに添えられて付いているファイルです。
メールにWORDファイルや一太郎ファイルが付いていたとして、それを正しく
表示するのはOutlookのお仕事ではないですよね?
それと全く同じです。
添付ファイルはいろんな種類があるんですから、メールソフトは適切なソフトに
引き渡して上げられればいいんです。
さらにいえば、勝手に別の形式に変換しちゃだめです。
>少なくとも、Content-Type: text/plain; charset=iso-2022-jpと添付ファイルのヘッダーに書いて
>あったのであれば、ファイルを「開く」または「保存する」ときにはコード変換すべきでしょう。
メール関係のRFCはたくさんあり、全部を把握してはいないので知りませんが、
その「すべき」は標準的な決まりでしょうか?
そもそもContent-Typeとは、そのコンテンツがどのような種類で、どのようなファイル
であるかを示しているものです。
それを、たとえばShift_JISで書いたテキストをcharset=iso-2022-jpと書いたからと言え、
Outlookが変換すべきなんて決まりはありません。
「このファイルはプレインテキストで、JISコードで書いてあります」と宣言されている
だけなのですから。
むしろ、そのような嘘のMIMEヘッダを付けるメールソフトが問題でしょう。
百歩譲って、charset=iso-2022-jpと書かれたUTF-8のテキストファイルが添付され、
それを中身を見てUTF-8toJISの変換をする必要があるとします。
しかし、文字によっては文字コードの識別ができないこともあるので、完璧な変換を
することはできません。
やはり文字化けを生じるケースがあります。
ですから、そのためにcharsetで予め文字コードを教えてあげるのが本当の意味です。
嘘のContent-Typeを付けちゃいけません。
>送ってくる相手はShift_JISや
> UTF-8で送ってくれるとは限らないわけですから。
それは、送信する側が配慮すべきことです。受信側が全部に対応していては、
とんでもないことになることにお気づきでしょうか?
QuickTimeのムービーを送ってくるかもしれないからOutlookでQT方式に対応し、
一太郎ファイルを送ってくるかもしれないからOutlookで一太郎ファイルを表示する?
送信元は一太郎ファイルを持っていないから、WORDのファイルを添付して、
Content-TypeでWord文書であると記載しておけば、受信側のメールソフトで
WORDに変換する必要がありますか?
無いですよね?
受信したメールソフトができることは、添付ファイルをそのままの形で保存するか、
適切なソフトを選択して引き渡すだけなんです。
> たとえば、Windowsでは改行がCRLFですけれどUNIXではLFだったりするので、
> テキストファイルであっても、場合によっては、最低限のデータ変換は必要になるのです
>(ネットワークに流すときの改行はCRLFにする必要があります)。
ですから、それはcharsetの指定ではありませんよ。
CR+LFで送られた添付ファイルは、最終的にはCR+LFになります。
ちなみにSMTPではCR+LFなので、テキストをLFに変換するとしたら、やはりそれは
メールソフトのお仕事ではありません。
>受信側のOSがUNIXで、ユーザーがEUC-JPの文字エンコーディングを使っているのであれば、
>受け取ったユーザーは、送られてきたテキストファイルは改行をLFにして、
>文字エンコーディングはEUC-JPにしたいと思うでしょう。
それは受信者のエディタなり、nkfなりで変換すべきでしょう。
SMTP上の決まりでもMIME指定の決まりでもありません。
UNIXユーザがShjft_JISのテキストとして取り扱いたい場合だってあります。
それなのに、勝手にEUCに変換されていいと思いますか?
> もし、勝手な変換をされたくないなら、Content-Typeをtext/plainではなく
> application/octet-streamにすべきなのです。
なんか、最後に捨て台詞として気にバカなことを言ってますね。
Content-Typeの用途を自分勝手に考えないでください。
勝手に変換をされたくないなら、最初から適切なコードに変換してから送るべきです。
不適切な間違った考えが広まると、Outlookなんかよりも変な問題のあるメールソフトが
出てくるじゃないですか。迷惑です。
何度も言うように、Content-Typeは、そのファイルの種類を教えてくれているだけです。
変換する必要があるときに使うということは、あ り ま せ ん。
Outlookにできることは、Content-Type: text/plain; charset=iso2-22-jp であれば、
JISコードが表示できるテキストエディタ等に引き渡すことだけです。
他のメールソフトも同じです。
メモ帳だとEUCやJISが化けますから、TeraPadでもインストールして関連付けしておけば
幸せになりますよね。
それとも、どうしてもOutlookを悪者にしたい理由があるのでしょうか?
それならわかります。