アカウント名:
パスワード:
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を利用していると、各国語のエンコードが入り混ったメールでも良きに図らってくれる為、 単なるリーダとして利用している分には、誰が使おうと構わないのですが。 Emacsで、いざメールを書くとなると設定のあやしい新米さんの場合、 Subjectやメール本文をエンコードせずに送信したり、あちこち異なった形式でエンコードしたりと、 色々と迷惑をかけるので困りものです。 Emacsで読んでいる為、読むことには何の支障もないので、自分では気づきにくい、 というか、他人から指摘されるまで気づかないので本当に困ります。 ＃ 自称ギークな上司が正にこのパターンで、分かってもらうのにとても苦労したAC ＃ 何年もやりとりしていた取引先の方が、実は我慢してやりとりしていた事実を知って、本人も流石に凹んでいましたが…
> とは言いますが、そもそもSubjectフィールドとContent-Type> フィールドは、同じ形式でエンコードしておくべきでは？
同じじゃなくても、ちゃんと規格通り動作するべき。
それって RMAIL ?
# 「Emacs でメール」って「Windows でメール」って言うくらい漠然とした言い方だな
そもそも、一時期セキュリティまわりでかなり叩かれていたOutlook Expressを使ってる人って割合としてどれくらいなんでしょう。企業によっては普通に「Outlook Expressは禁止」なんてところも多いように思えますが。
http://www.itmedia.co.jp/bizid/articles/0703/09/news103.html各社の調査によると、マイクロソフトのOutlook ExpressとOutlookを合わせると8割近いシェアに達すると見られており、残りを有償のメールソフトやThunderbirdなどが分け合っている状況。
http://www.itmedia.co.jp/bizid/articles/0703/09/news103.html
各社の調査によると、マイクロソフトのOutlook ExpressとOutlookを合わせると8割近いシェアに達すると見られており、残りを有償のメールソフトやThunderbirdなどが分け合っている状況。
その記事にも書かれてますけど、実は最大シェアはWebメールだったりしませんか?デスクトップ型のクライアントだけで比較されても参考になりません。Windows 7からはWindowsメールが付属しなくなりますし。
Windows 7 に Windows Mail は付属しませんが、既に置き換え目的の Windows Live Mail はリリース版が配布されています。
# どっちにしろ Outlook 2007 と Sylpheed の共用なので使ってませんが。
解決方法もありますよ、ということで。一応ご案内。mew-fake-cdp-sending.el [meadowy.org]
あ、そんないいものがあるのか、と思いましたがmew-1.95betaでは不要と書いてありますね。マージしたけど今はやっぱりなくなったとかですかね。
4.2使ってますが、日本語のファイル名のファイルを添付するときはDを押して拡張子を削除したDescriptionを追加してます。
世の中に出回っている暗黙の了解の所為でこの手の問題は表面化しないんでしょう。
普通のユーザは、デフォルトの設定でメールが表示できれば正常動作と考えるのが普通ですから。
「そういえば規格上はこういうことができるはずだよな」と弄ってみるととたんに爆発。しかも周りがことごとく間違っているからそれに合わせるしかなく手も足も出ない。
そういえば、暗黙の了解とか不文律に寄りかかってしまうと、もうそこから進まなくなってしまうんですよね。
そういう変なメールを作成するメールソフト
というのが、まさに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にすべきなのです。
今やってみましたが、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
タレコミ人のケースでも、テキストエディタで書いたものを 貼り付けたら別の文字コードで混ざったんですよね。 Windowsではあまり考えられないケースですが、Linuxとか使ってた ということではないですか？
よくあるパターンは、次のどちらかでしょう。
半角カタカナは多くのMUAの実装では全角カタカナに直してしまいますね。少なくとも、日本製のMUAで半角カタカナの処置を間違うようでは堕落と言われてしまうのでは？それに、私は半角カタカナが大嫌いなので使っていません。
> 「JIS X 0208で表現できない文字（「彅」とか）」が混じっていたこちらが正解。あと、Unicodeで定義された記号が混じっていたようです。
より多くのコメントがこの議論にあるかもしれませんが、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, 興味深い)
とは言いますが、そもそもSubjectフィールドとContent-Typeフィールドは、同じ形式でエンコードしておくべきでは？
更に言えば、Subeject/Content-Typeフィールドに別々のエンコードをしてしまうというのは、 新米Emacsen使いな方々の設定ミスが主な原因と記憶していましたが。
Emacsを利用していると、各国語のエンコードが入り混ったメールでも良きに図らってくれる為、 単なるリーダとして利用している分には、誰が使おうと構わないのですが。
Emacsで、いざメールを書くとなると設定のあやしい新米さんの場合、 Subjectやメール本文をエンコードせずに送信したり、あちこち異なった形式でエンコードしたりと、 色々と迷惑をかけるので困りものです。
Emacsで読んでいる為、読むことには何の支障もないので、自分では気づきにくい、 というか、他人から指摘されるまで気づかないので本当に困ります。
＃ 自称ギークな上司が正にこのパターンで、分かってもらうのにとても苦労したAC
＃ 何年もやりとりしていた取引先の方が、実は我慢してやりとりしていた事実を知って、本人も流石に凹んでいましたが…
Re:現状のContent-Type対応は十分ではありません (スコア:1)
MIMEのミニマムな文字集合を使用すべし、という原則に従うと必ずしも同じとならんでも仕方ありません。
(元々ヘッダとボディの扱いが独立なのですから、非US-ASCII文字のエンコード方法については。)
Re: (スコア:0)
> とは言いますが、そもそもSubjectフィールドとContent-Type
> フィールドは、同じ形式でエンコードしておくべきでは？
同じじゃなくても、ちゃんと規格通り動作するべき。
Re: (スコア:0)
それって RMAIL ?
# 「Emacs でメール」って「Windows でメール」って言うくらい漠然とした言い方だな
Re:現状のContent-Type対応は十分ではありません (スコア:1)
そもそも、一時期セキュリティまわりでかなり叩かれていたOutlook Expressを使ってる人って割合としてどれくらいなんでしょう。
企業によっては普通に「Outlook Expressは禁止」なんてところも多いように思えますが。
神社でC#.NET
Re:現状のContent-Type対応は十分ではありません (スコア:4, 参考になる)
Re: (スコア:0)
毎日百通程メールが届くのですが、Outlook Express
とOutlookを合わせて良くて4割程度。MUA程多様な
ソフトが使われている分野は他にないかもしれません。
Re: (スコア:0)
その記事にも書かれてますけど、実は最大シェアはWebメールだったりしませんか?
デスクトップ型のクライアントだけで比較されても参考になりません。
Windows 7からはWindowsメールが付属しなくなりますし。
Re:現状のContent-Type対応は十分ではありません (スコア:2, 参考になる)
Windows 7 に Windows Mail は付属しませんが、既に置き換え目的の Windows Live Mail はリリース版が配布されています。
# どっちにしろ Outlook 2007 と Sylpheed の共用なので使ってませんが。
Re:現状のContent-Type対応は十分ではありません (スコア:1)
認識できないのをいい加減止めて欲しい。
TomOne
Re:現状のContent-Type対応は十分ではありません (スコア:2, 参考になる)
解決方法もありますよ、ということで。
一応ご案内。
mew-fake-cdp-sending.el [meadowy.org]
Re:現状のContent-Type対応は十分ではありません (スコア:2, 興味深い)
あ、そんないいものがあるのか、と思いましたが
mew-1.95betaでは不要
と書いてありますね。マージしたけど今はやっぱりなくなったとかですかね。
4.2使ってますが、日本語のファイル名のファイルを添付するときはDを押して拡張子を削除したDescriptionを追加してます。
mew-fake-cdp-sending.el (スコア:1)
X-Mailer: Mew version 5.2 on Emacs 22.1.50 / Mule 5.0 (SAKAKI)
です(ちなみに最新は6.2)。
# mewって確か、開発者のkazuさんもMacOSXで使っていたような...(おかげでメールの検索は先にspotlightに対応したんですよね)。
Best regards, でぃーすけ
Re:現状のContent-Type対応は十分ではありません (スコア:1)
世の中に出回っている暗黙の了解の所為でこの手の問題は表面化しないんでしょう。
普通のユーザは、デフォルトの設定でメールが表示できれば正常動作
と考えるのが普通ですから。
「そういえば規格上はこういうことができるはずだよな」と弄ってみるととたんに爆発。
しかも周りがことごとく間違っているからそれに合わせるしかなく手も足も出ない。
そういえば、暗黙の了解とか不文律に寄りかかってしまうと、
もうそこから進まなくなってしまうんですよね。
Re: (スコア:0)
> 最初に検出したエンコードで全体をデコードするため
> subjectのエンコードと異なるcontent-typeでは問題がでるなど、
> MIMEの扱いはぼろぼろです。
まず、Mozilla系を持ち上げてOEをコケ下ろす前に、そういう変な
メールを作成するメールソフトを糾弾すべきじゃないかと思うのは
私だけでしょうか？
タレコミ人のケースでも、テキストエディタで書いたものを
貼り付けたら別の文字コードで混ざったんですよね。
Windowsではあまり考えられないケースですが、Linuxとか使ってた
ということではないですか？
タレコミ人の書きようも、「そんなの読めないほうが悪いんじゃね？」
とでも言いたげに感じられるし。
Re:現状のContent-Type対応は十分ではありません (スコア: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とを分離して、前者の話だけをしたつもりでした。
それではだめです。
もともとは、一つの本文テキストに複数の文字コードが混ざる話でした。
別次元の添付ファイルに関して変だ、ということ自体が間違っています。
>
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
Re:現状のContent-Type対応は十分ではありません (スコア:1)
よくあるパターンは、次のどちらかでしょう。
Re:現状のContent-Type対応は十分ではありません (スコア:1)
半角カタカナは多くのMUAの実装では全角カタカナに直してしまいますね。
少なくとも、日本製のMUAで半角カタカナの処置を間違うようでは堕落と言われてしまうのでは？
それに、私は半角カタカナが大嫌いなので使っていません。
> 「JIS X 0208で表現できない文字（「彅」とか）」が混じっていた
こちらが正解。あと、Unicodeで定義された記号が混じっていたようです。