アカウント名:
パスワード:
MIMEにすることで一行が長いメールを送ることは可能なはず。原因はMIMEにする必要があるのに、やっていないということでは。
RFC 1468によるとメールの本文はMIMEエンコードするなということになっている。おかげで添付ファイルはなんでもありなのに本文に限ってわけのわからない制約が山盛りという現状
MIMEで規定されているものはたくさんあるのに、そのどれのことかを指さずに「MIME」って一言で片付けちゃってるからすれ違いが発生してる感じですね。
RFC1468 に従うと、本文は Content-Type: text/plain; charset=ISO-2022-JP になる。これは 7bit で伝送可能なので、Content-Transfer-Encoding を base64 や quoted-printable にしなくてもいい。というのが
> RFC 1468によるとメールの本文はMIMEエンコードするなということになっている。
この文章の意図かな。
一方、元コメの
> MIMEにすることで一行が長いメールを送ることは可能なはず。
についてですが、MIMEの規格に従うと、text/plain、Content-Transfer-Encoding: 7bit のままでも、RFC3676で規定された format=flowed; delsp=yes; [geocities.jp]を使えば、RFC1468に反しない形式で一行998文字を超えたテキストを表現できます。
これは、行が長いテキストは、送信時に「スペースと改行」を適宜埋め込み、受信側では「スペースと改行」は取り除く、というもの。非対応な旧来のMUAでみた場合には「自動的に改行整形されたテキスト」に見えるし、対応MUAなら元の長大行が復元される、というしくみです。
今回の問題の場合、相手は携帯電話ですが、古い携帯電話だとUTF-8とかquoted-printableには非対応な機種もあります。quoted-printableやbase64でも長大行は実現できますが、そうではなくRFC1468の範囲内で対応するのが無難でしょう。
RFC1468の時点で存在すらしなかったRFC3676とか飛び道具にもほどがある。それこそ対応してないMUA山盛りだと思うが。たぶんquoted-printable未対応のMUAよりはるかに多いよ
RFC3676は互換性を考慮した規格ですよ。UTF-8 や quoted-printable なメールは、非対応のMUAで受信すると文字化けしてしまいますが、format=flowedなメールは、非対応なMUAでも文字化けなく受信することができます。
そもそも、RFC1468自体、「MIME の規定に従った形式」で「MIME登場前の旧来の日本語MUAで問題なく受信できる日本語のメール」を送信するにはどうすれば良いのか、というMIME登場以前のMUAからすれば後付けのRFCです。
RFC3676を飛び道具と言うなら、RFC1468だってMIME非対応な古いメーラから見れば飛び道具になってしまいますな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
直接の原因はMIMEにしてないことじゃないの (スコア:0)
MIMEにすることで一行が長いメールを送ることは可能なはず。原因はMIMEにする必要があるのに、やっていないということでは。
Re: (スコア:0)
RFC 1468によるとメールの本文はMIMEエンコードするなということになっている。
おかげで添付ファイルはなんでもありなのに本文に限ってわけのわからない制約が山盛りという現状
Re:直接の原因はMIMEにしてないことじゃないの (スコア:4, 参考になる)
MIMEで規定されているものはたくさんあるのに、そのどれのことかを指さずに「MIME」って一言で片付けちゃってるからすれ違いが発生してる感じですね。
RFC1468 に従うと、本文は Content-Type: text/plain; charset=ISO-2022-JP になる。
これは 7bit で伝送可能なので、Content-Transfer-Encoding を base64 や quoted-printable にしなくてもいい。というのが
> RFC 1468によるとメールの本文はMIMEエンコードするなということになっている。
この文章の意図かな。
一方、元コメの
> MIMEにすることで一行が長いメールを送ることは可能なはず。
についてですが、MIMEの規格に従うと、text/plain、Content-Transfer-Encoding: 7bit のままでも、RFC3676で規定された format=flowed; delsp=yes; [geocities.jp]を使えば、RFC1468に反しない形式で一行998文字を超えたテキストを表現できます。
これは、行が長いテキストは、送信時に「スペースと改行」を適宜埋め込み、受信側では「スペースと改行」は取り除く、というもの。
非対応な旧来のMUAでみた場合には「自動的に改行整形されたテキスト」に見えるし、対応MUAなら元の長大行が復元される、というしくみです。
今回の問題の場合、相手は携帯電話ですが、古い携帯電話だとUTF-8とかquoted-printableには非対応な機種もあります。
quoted-printableやbase64でも長大行は実現できますが、そうではなくRFC1468の範囲内で対応するのが無難でしょう。
Re: (スコア:0)
RFC1468の時点で存在すらしなかったRFC3676とか飛び道具にもほどがある。それこそ対応してないMUA山盛りだと思うが。たぶんquoted-printable未対応のMUAよりはるかに多いよ
Re:直接の原因はMIMEにしてないことじゃないの (スコア:1)
RFC3676は互換性を考慮した規格ですよ。
UTF-8 や quoted-printable なメールは、非対応のMUAで受信すると文字化けしてしまいますが、
format=flowedなメールは、非対応なMUAでも文字化けなく受信することができます。
そもそも、RFC1468自体、「MIME の規定に従った形式」で「MIME登場前の旧来の日本語MUAで問題なく受信できる日本語のメール」を送信するにはどうすれば良いのか、というMIME登場以前のMUAからすれば後付けのRFCです。
RFC3676を飛び道具と言うなら、RFC1468だってMIME非対応な古いメーラから見れば飛び道具になってしまいますな。