The ISO-2022-JP encoding is already in 7-bit form, so it is not
necessary to use a Content-Transfer-Encoding header. It should be
noted that applying the Base64 or Quoted-Printable encoding will
render the message unreadable in current JUNET software.
The human user (not implementor) should try to keep lines within 80
display columns, or, preferably, within 75 (or so) columns, to allow
insertion of ">" at the beginning of each line in excerpts.
MS-Wordで送ればいいやん (スコア:2, すばらしい洞察)
サブジェクトは暴論でない。ただし、タレコミレベルの話をする場合において。
タレコミに書いている内容は、一見文字コードの話をしているように見えるが、実際の内容は「読める人がいるから使ってよいのでは?」ですよね。
それならばMS-Wordで良い。図だって使えるし。(実際はPDFあたりが最適と思う)
たとえば「メールにおける文字コード問題は昔はだいぶ議論されたものですが(Shift_JISで送るな！とか)、最近は全く聞かれなくなりました。」を理由に持ってくることは間違です。
いま問題が無いのは、きっちりとコードなどの各種規格を整備した結果であって、ほかの文字コードの
ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:1, 興味深い)
MS-Wordはともかく、前にどこかのメーリングリストで、嫌われ者のHTMLメールだが
多言語利用時には便利だよ、という話があってなるほどと思ったことがある。
Re: (スコア:0)
＞多言語利用時にはHTMLメールが便利
それって、普通にUTFなメールじゃ駄目なんですか？
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:3, すばらしい洞察)
ダメです。メールのフォーマットに関しては素人なので以下に挙げる問題点を解決できる仕様があれば教えてもらいたいです。
例えば、現在のプレーンテキストのメールの仕様では、あらゆる言語で使いやすい、受信側のMUAで都合の良い場所で改行して表示する仕様がありません。76文字程度で改行することで大抵の環境で読みやすい、なんていう話も昔はありましたが、携帯電話のように想定外のデバイスが出てくると、このような話は成り立たなくなります。欧米の言語のようにスペースで単語を分かち書きする場合には"format=flowed"で自動改行の問題を解決できますが、これはスペースを利用しない言語のことは考えていない仕様なので、日本語や中国語等では意図しない場所に勝手にスペースが挿入されてレンダリングされることになるので日本人的には使い物になりません。
また、国際的なWebアプリケーションを作成する場合には、送信側のWebアプリケーションの開発が非常に大変である、という問題もあります。例えば(詳しくは知りませんが)タイ語は辞書がなければ改行位置が決まりませんし、そこまで複雑ではないとしても日本語には禁則処理もあります。Web用にtextareaから自由に投げられたテキストをメール送信のために適当な場所で改行してプレーンテキストのメールを作るだけでかなり大変な処理が必要になり、その分、Webサーバの負荷も大きくなります。ですが、HTMLメールで送信する場合は受信側の各レンダリングエンジンが自動改行を解決してくれますので、送信側が改行位置を気にする、という必要がなくなります(受け取り側のMUAがその人の利用する言語の処理が弱いとは考えにくい)。
また、プレーンテキストでは文字から言語を特定することができませんが、HTMLではlang属性が適切に設定されていればレンダリング時にその言語情報を利用することができます。例えば、日本語と中国語が混在しているメールを適切にレンダリングすることができるようになることを意味しますので、ビジネス等でそのような利用がよくある方には便利でしょう。
HTMLメールを使うと、セキュリティが不安だという都市伝説的な話や、スタイル指定で派手なものを送りつけられるのが鬱陶しいという話を聞きますが、どちらも受信側で再現する情報を取捨選択すれば済む話で、例えばMUA側でjavascriptや画像をオフにしたり、ユーザスタイルシートで作成者のスタイルシートを無効化する、ということが理論上はできます。
このように、HTMLメールは作成側には便利で、受信側にとっても意味のあるものを受け取ることができる、という点でプレーンテキストのメールよりも有利ですが、HTMLメールに対応していない資産を活用できなくなる、というあたりが最大の難点でしょうか。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:2, 興味深い)
quoted-printableやbase64でエンコードすればいいと思います。実際添付ファイルはプレーンテキストでもエディタが都合のいい場所で改行して表示できます。日本語メールの本文をquoted-printableやbase64でエンコードしないのは、これまたRFC 1468が禁止しているからに過ぎません。で、禁止の根拠が「quoted-printableやbase64は対応していない環境もあるけど76文字程度で改行することで大抵の環境で読みやすい」だったりするのがもう…。
Thunderbirdは実際にそうしてますよね。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:2, 参考になる)
禁止というほど強くはないんですけどね。RFC 1468 [ietf.org] によると：
ということで
という程度でしょう。それから15年も経っているのだから、状況は変わっているはずです。
これも、原文は
とあります。80カラムの制限が出てきたのは、当時は1行80カラムのディスプレイ端末（ウィンドウシステムですらない）が多く使われていたことの反映で、今では状況も違いますね。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:1)
フォローどうもです。なるほど、確かにbodyがエンコードされればプレーンテキストの制約を受けなくなりますね。でもRFCを堂々と破るわけにもいかないのは悩ましいですね……
Tb以外のMUA、特に外部のブラウザのエンジンを埋め込みで利用しているようなMUAがどこまでコントロール可能なのか知らないのでぼかしてみました(Tbもあまり細かい仕様は知りませんが)。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:1)
RFC3676ではDelSpが定義されており、"format=flowed" と共に "delsp=yes" が設定されている場合、行末に付加される空白は削除して表示されるべきです。 DelSpの要否をどのようにしてMUAが判断するか、以下のように、DelSpの要否が異なる言語が一つのtext/plainパートに書かれていた場合どうするのか、と言う問題はありますが…。
Re: (スコア:0)
いや、だから、本文をUTF8にするのはまだちょっと抵抗がある、という前提での話なので。