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: (スコア:3, すばらしい洞察)
ダメです。メールのフォーマットに関しては素人なので以下に挙げる問題点を解決できる仕様があれば教えてもらいたいです。
例えば、現在のプレーンテキストのメールの仕様では、あらゆる言語で使いやすい、受信側のMUAで都合の良い場所で改行して表示する仕様がありません。76文字程度で改行することで大抵の環境で読みやすい、なんていう話も昔はありましたが、携帯電話のように想定外のデバイスが出てくると、このような話は成り立たなくなります。欧米の言語のよう
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もあまり細かい仕様は知りませんが)。