アカウント名:
パスワード:
サブジェクトは暴論でない。ただし、タレコミレベルの話をする場合において。タレコミに書いている内容は、一見文字コードの話をしているように見えるが、実際の内容は「読める人がいるから使ってよいのでは?」ですよね。それならばMS-Wordで良い。図だって使えるし。(実際はPDFあたりが最適と思う)
たとえば「メールにおける文字コード問題は昔はだいぶ議論されたものですが(Shift_JISで送るな！とか)、最近は全く聞かれなくなりました。」を理由に持ってくることは間違です。いま問題が無いのは、きっちりとコードなどの各種規格を整備した結果であって、ほかの文字コードの
MS-Wordはともかく、前にどこかのメーリングリストで、嫌われ者のHTMLメールだが多言語利用時には便利だよ、という話があってなるほどと思ったことがある。
＞多言語利用時にはHTMLメールが便利
それって、普通にUTFなメールじゃ駄目なんですか？
多言語利用時にはHTMLメールが便利 それって、普通にUTFなメールじゃ駄目なんですか？
多言語利用時にはHTMLメールが便利
ダメです。メールのフォーマットに関しては素人なので以下に挙げる問題点を解決できる仕様があれば教えてもらいたいです。
例えば、現在のプレーンテキストのメールの仕様では、あらゆる言語で使いやすい、受信側のMUAで都合の良い場所で改行して表示する仕様がありません。76文字程度で改行することで大抵の環境で読みやすい、なんていう話も昔はありましたが、携帯電話のように想定外のデバイスが出てくると、このような話は成り立たなくなります。欧米の言語のよう
例えば、現在のプレーンテキストのメールの仕様では、あらゆる言語で使いやすい、受信側のMUAで都合の良い場所で改行して表示する仕様がありません。
quoted-printableやbase64でエンコードすればいいと思います。実際添付ファイルはプレーンテキストでもエディタが都合のいい場所で改行して表示できます。日本語メールの本文をquoted-printableやbase64でエンコードしないのは、これまたRFC 1468が禁止しているからに過ぎません。で、禁止の根拠が「quoted-printableやbase64は対応していない環境もあるけど76文字程度で改行することで大抵の環境で読みやすい」だったりするのがもう…。
MUA側でjavascriptや画像をオフにしたり、ユーザスタイルシートで作成者のスタイルシートを無効化する、ということが理論上はできます。
Thunderbirdは実際にそうしてますよね。
フォローどうもです。なるほど、確かにbodyがエンコードされればプレーンテキストの制約を受けなくなりますね。でもRFCを堂々と破るわけにもいかないのは悩ましいですね……
Tb以外のMUA、特に外部のブラウザのエンジンを埋め込みで利用しているようなMUAがどこまでコントロール可能なのか知らないのでぼかしてみました(Tbもあまり細かい仕様は知りませんが)。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
MS-Wordで送ればいいやん (スコア:2, すばらしい洞察)
サブジェクトは暴論でない。ただし、タレコミレベルの話をする場合において。
タレコミに書いている内容は、一見文字コードの話をしているように見えるが、実際の内容は「読める人がいるから使ってよいのでは?」ですよね。
それならばMS-Wordで良い。図だって使えるし。(実際はPDFあたりが最適と思う)
たとえば「メールにおける文字コード問題は昔はだいぶ議論されたものですが(Shift_JISで送るな！とか)、最近は全く聞かれなくなりました。」を理由に持ってくることは間違です。
いま問題が無いのは、きっちりとコードなどの各種規格を整備した結果であって、ほかの文字コードの
ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:1, 興味深い)
MS-Wordはともかく、前にどこかのメーリングリストで、嫌われ者のHTMLメールだが
多言語利用時には便利だよ、という話があってなるほどと思ったことがある。
Re: (スコア:0)
＞多言語利用時にはHTMLメールが便利
それって、普通にUTFなメールじゃ駄目なんですか？
Re: (スコア:3, すばらしい洞察)
ダメです。メールのフォーマットに関しては素人なので以下に挙げる問題点を解決できる仕様があれば教えてもらいたいです。
例えば、現在のプレーンテキストのメールの仕様では、あらゆる言語で使いやすい、受信側のMUAで都合の良い場所で改行して表示する仕様がありません。76文字程度で改行することで大抵の環境で読みやすい、なんていう話も昔はありましたが、携帯電話のように想定外のデバイスが出てくると、このような話は成り立たなくなります。欧米の言語のよう
Re: (スコア:2, 興味深い)
quoted-printableやbase64でエンコードすればいいと思います。実際添付ファイルはプレーンテキストでもエディタが都合のいい場所で改行して表示できます。日本語メールの本文をquoted-printableやbase64でエンコードしないのは、これまたRFC 1468が禁止しているからに過ぎません。で、禁止の根拠が「quoted-printableやbase64は対応していない環境もあるけど76文字程度で改行することで大抵の環境で読みやすい」だったりするのがもう…。
Thunderbirdは実際にそうしてますよね。
Re:ちょっと話はそれるが、多言語利用時にはHTMLメールが便利 (スコア:1)
フォローどうもです。なるほど、確かにbodyがエンコードされればプレーンテキストの制約を受けなくなりますね。でもRFCを堂々と破るわけにもいかないのは悩ましいですね……
Tb以外のMUA、特に外部のブラウザのエンジンを埋め込みで利用しているようなMUAがどこまでコントロール可能なのか知らないのでぼかしてみました(Tbもあまり細かい仕様は知りませんが)。