送信添付ファイルが壊れる - 秀丸メール情報交換会議室 - スレッド08613, 2002/08/08

送信添付ファイルが壊れる

ながさわ さん　02/08/08 20:18

こんにちは、長澤です。

末尾のようなファイルをメールに添付して送信すると、受信側で添付ファイルが
化けます。と、云うよりも送信時点でファイルを壊すキーワードを埋め込んでし
まっています。

ファイル自体はencoding指定に則ってEUCなんですが、送信ログを確認すると
Content-Type: text/html; charset=shift_jis; name="test.xml"
になっちゃってます。当然（？）JIS(iso-2022-jp)でも同じで、Shift_JISでは
壊れません。

<?xml version="1.0" encoding="euc-jp"?>
<root>
<email address="curly@ic-net.or.jp">
<name first="Kaoru" second="Nagasawa" middle=""/>
<web>http://www.ic-net.or.jp/home/curly/</web>
<message>ウェブページにて、駅名当てクイズ実施中！</message>
</email>
</root>

RE:08613 送信添付ファイルが壊れる

ながさわ さん　02/08/08 20:21

こんにちは、長澤です。

>Content-Type: text/html; charset=shift_jis; name="test.xml"

Content-Type: text/xml; charset=shift_jis; name="test.xml"

です。あーコピペすればよかった。

RE:08614 送信添付ファイルが壊れる

秀まるお2 さん　02/08/09 02:08

　すみません。たしかにバグです。

　文字コードの自動判定処理に、そもそもEUCが配慮されてませんでした。eucの
ファイルは全部shift_jisとなって送られてしまいます。

　この辺はもっと正確に判定するようにし、２種類以上に判定可能な場合は
charset=を付けないようにします。

RE:08617 送信添付ファイルが壊れる

むーこ さん　02/08/09 11:06

>　この辺はもっと正確に判定するようにし、２種類以上に判定可能な場合は
>charset=を付けないようにします。

それはまずいんじゃないでしょうか。
charsetの省略は、charset=US-ASCIIを指定するのと同じです。

そこで、例えばDatulaは、text/*なコンテンツに対して
charset=UNKNOWN-8BITと書いて送るようです。
charset=UNKNOWN-8BITは「charset不明」という意味で
RFC1428で規定されています。
ftp://ftp.isi.edu/in-notes/rfc1428.txt
IANAにも登録されています。
http://www.iana.org/assignments/character-sets

ただ、Datula方式にも問題があって、RFC1428をよく読むと、

The use of the "unknown-8bit" label is intended only by mail gateway
agents which cannot determine via out-of-band information the
intended character set.

charset=UNKNOWN-8BITを使用してよいのは、(使用者に
charsetを尋ねる手段を持たない)mail gateway agentだけである。

This character set is not intended to be used by mail composers. It
is assumed that the mail composer knows the character set in use and
will mark it with a character set value as specified in [1], as
amended by current Assigned Numbers documents [6].

(使用者にcharsetを尋ねる手段を持ち得る)mail composerは、
正確なcharsetを指定すると仮定される。

(注)底流にあるRFC作成者の意図を汲み取った訳です。

日本語だけでなく、charset=ISO-8859-1とかcharset=GBKの場合も
考慮すると、charsetを常に自動判定する、というやり方がまずいと
思います。
むしろ、自動判定の結果、有力候補と考えられるcharsetの一覧を
使用者に提示し、最終的には使用者がcharsetを決定できるように
したほうがいいと思います。

RE:08621 送信添付ファイルが壊れる

秀まるお2 さん　02/08/09 14:19

　iso-8859-1とか中国語についてはさすがに自動判定の限界なので、実はメール
自体の文字コードが日本語以外の場合はcharsetを付けないようにしました。

　しかし、そもそもcharset=の指定なしがダメと言うなら、やはりメールソフト
として出来ることはDatulaのように「unknown-8bit」とする程度かと思います。

　ユーザー側でcharsetを指定できるようにするとなると、そういう特別な仕組
みやユーザーインタフェースを作らないといけないので、かなりややこしい話に
なると思います。しいて必要なら作ってもいいですけど。

　ほかのメールソフトでもそこまで指定できるソフトは無いと思うし、だいたい
にして、textだろうが何だろうが、全部「application/octet-stream」で送る
メールソフトも多々あります。

RE:08623 送信添付ファイルが壊れる

むーこ さん　02/08/09 15:32

>　ユーザー側でcharsetを指定できるようにするとなると、そういう特別な仕組
>みやユーザーインタフェースを作らないといけないので、かなりややこしい話に
>なると思います。しいて必要なら作ってもいいですけど。

ぜひ作っていただきたいです。
多くのcharsetを使う人にとっては、正しいcharsetを
指定できるメールソフトかどうか、という点が、
メールソフト選択の重要なポイントになります。
文字化けして相手に迷惑をかけたら大変ですから。

>　ほかのメールソフトでもそこまで指定できるソフトは無いと思うし、だいたい
>にして、textだろうが何だろうが、全部「application/octet-stream」で送る
>メールソフトも多々あります。

そうですね。
この件に関して、ほかのメールソフトと比較して
鶴亀メールが劣っているわけではありません。
私が期待しているのは、鶴亀メールが率先して
まじめにMIME対応してほしい、ということです。

ちなみに、誤ったcharsetをつけるくらいなら、
何でもかんでもapplication/octet-streamにして
しまったほうが、文字化けする恐れが少なくて安心、
という話もあります。

RE:08624 送信添付ファイルが壊れる

ながさわ さん　02/08/09 19:58

むーこさん、こんにちは。長澤です。

なんだか難しい話になっちゃってますが、メンド臭くなくて正常に送受信できれ
ばいいです、私としては。

RE:08629 送信添付ファイルが壊れる

むーこ さん　02/08/09 21:14

>なんだか難しい話になっちゃってますが、メンド臭くなくて正常に送受信できれ
>ばいいです、私としては。

すみません。話を難しくしちゃって。

私が指摘しているのは、秀まるお2さんが提示された方法では
根本的な問題の解決には至らず、それでもまだ文字化けが発生
する可能性がある、ということです。
それでは私は困ります。

きっちりRFCを読んで作られた安全なメールソフトを探している
のですが、なかなか見つからなくて・・・
バージョンアップが頻繁に行われている鶴亀メールに期待しています。

RE:08631 送信添付ファイルが壊れる

秀まるお2 さん　02/08/10 23:12

　とりあえず手元のバージョンは文字コード不明の場合には「unknown-8bit」で
送ることにしました。

　ある程度の長さの日本語文字列が含まれていれば、ほとんどのケースで自動認
識は成功するはずです。日本語文字列が非常に短い場合や、意図的に不正な文字
コードを入れた場合でなければほとんど大丈夫なはずです。

　最終的には文字コード（か、あるいはそもそも添付ファイルのContent-type）
をユーザー側が指定できるようにしたいと思いますが、いろいろ内部的な仕組み
も考えないといけないので将来検討予定としておきます。

RE:08641 送信添付ファイルが壊れる

むーこ さん　02/08/12 12:42

>　ある程度の長さの日本語文字列が含まれていれば、ほとんどのケースで自動認
>識は成功するはずです。日本語文字列が非常に短い場合や、意図的に不正な文字
>コードを入れた場合でなければほとんど大丈夫なはずです。

*日本語に限定すれば* 確かにそうですね。
ただ、本文が日本語だからと言って、添付テキストファイルが
日本語であるとは限らないのです。
また、JIS X 0201カナとEUC-JPの漢字のように、自動判別が
困難なケースもあります。

>　最終的には文字コード（か、あるいはそもそも添付ファイルのContent-type）
>をユーザー側が指定できるようにしたいと思いますが、いろいろ内部的な仕組み
>も考えないといけないので将来検討予定としておきます。

ぜひお願いします。

■鶴亀メールの紹介
http://hidemaru.xaxon.co.jp/software/tkdoc.html
のページで「多国語対応」と宣伝されていますが、
現状では、MIMEが多国語対応メールソフトに要求
している条件を完全には満たしていないと思います。

RE:08654 送信添付ファイルが壊れる

秀まるお2 さん　02/08/12 16:36

　どっちにしても、今はテンプレート関係で忙しいのでしばらくお待ちを。

>のページで「多国語対応」と宣伝されていますが、
>現状では、MIMEが多国語対応メールソフトに要求
>している条件を完全には満たしていないと思います。

　そもそも「多国語対応メールに要求している条件」というのを知らないです。
もしそういうのが掲載されているホームページがあったらURLなど教えて欲しい
です。

RE:08666 送信添付ファイルが壊れる

むーこ さん　02/08/12 19:34

>　そもそも「多国語対応メールに要求している条件」というのを知らないです。
>もしそういうのが掲載されているホームページがあったらURLなど教えて欲しい
>です。

RFCを読んでください。

RE:08679 送信添付ファイルが壊れる

Stream さん　02/08/13 13:56

>RFCを読んでください。

RFCって、HTMLや、何やらインターネット上でのやりとりに
関する方法（Protocols）を記載しているものですよね。
かなりの量になると思いますし、鶴亀メールの範囲外の部分も
かなり含むと思いますので、RFC番号を書き込まれたほうが
よろしいのではないでしょうか。

ただ、RFC[2277](http://www.ietf.org/rfc/rfc2277.txt)などに
ざっと目を通した限りでは、送信する側が、
なんでもかんでもすべてのキャラクターセットに対応しなければ、
「多言語対応メール」じゃないとは言っていないんじゃないでしょうか？
あえて言えば、IETF（Internet Engineering Task Force）は、
鶴亀がUnicodeに完全対応していない段階で既に、
多言語対応メールじゃない、ってことに言うんじゃないでしょうか？

ソフトの開発には、それだけで相当時間がかかることだと思います。
その上、サポートにも多くの時間を割いていただいているのが、
書き込みへの対応を拝見しているだけでもよく分かります。
これだけの恩恵を、わずか2000円のフィーで受けられるかと
考えると、本当に頭が下がります。

鶴亀メールの機能が向上すれば嬉しい、と考える思いは同じです。
そのためにも、せめてRFC番号(リファレンス番号？)を明記することで、
協力することができるのではないでしょうか。

RE:08680 送信添付ファイルが壊れる

秀まるお2 さん　02/08/13 14:13

　Streamさん＆むーこさんどうも。とりあえずRFC2277番が重要なことは分かり
ました。

　どっちにしても今は対応どころか勉強する暇も無いので、RFC2277番およびそ
の他RFCを参照すればＯＫとの話で十分です。