https://tools.ietf.org/html/rfc5321 [ietf.org] > 2.3.1. Mail Objects ... > Although SMTP extensions (such as > "8BITMIME", RFC 1652 [22]) may relax this restriction for the content > body, the content header fields are always encoded using the US-ASCII > repertoire.
ビット落ち (スコア:1)
もともと伝送経路で8bit目が落ちるのでISO-2022やUTF-7が使われていたんじゃなかったっけ？
今はもう大丈夫なの？
Re: (スコア:1)
伝送経路というよりはSMTPの規格ですね。
ESMTPで8BITMIME対応ならボディパートは8bitで送信してOK。
(ヘッダパートはUS-ASCII固定なのでMIMEエンコード必須)
Re:ビット落ち (スコア:0)
MIMEエンコードされていないヘッダーはUTF-8として処理する、というのは受信したMUAだけで、送信はダメなんだっけ？
Re:ビット落ち (スコア:2)
https://tools.ietf.org/html/rfc5321 [ietf.org]
> 2.3.1. Mail Objects
...
> Although SMTP extensions (such as
> "8BITMIME", RFC 1652 [22]) may relax this restriction for the content
> body, the content header fields are always encoded using the US-ASCII
> repertoire.
なんで、ダメなんではないかと。
Re: (スコア:0)
MIMEエンコードされていないヘッダーはUTF-8として処理するMUAなんてある？ 何か勘違いしてそう
本文のエンコード方式を指定するヘッダのエンコード方式はUS-ASCII決め打ちにしておかないと不都合でしょ
// 本文のエンコード方式を指定するヘッダのエンコード方式を指定するメタヘッダのエンコード方式の……
Re: (スコア:0)
MIMEエンコードされていないヘッダーはUTF-8として処理するMUAなんてある？
既存のメールを.emlファイルとして保存し、Subject:などを生のUTF-8に書き換え、Thunderbirdで開いてみてください。文字化けしないと思います。この仕様変更は、Thunderbird 38からで、RFC 5335によるものだそうです。
Re: (スコア:0)
確かに文字化けしない。RFC 5335 [ietf.org]を読む限り、本来は Content-Type: message/global を指定した場合にUTF-8を含むものとして処理する意図のようだけど、Thunderbirdはmessage/rfc822やtext/plainでも気を利かせてくれるということか
Re: (スコア:0)
気を利かすんなら文字タイプ変更が2連続した程度でエンコードエラー文字を生成するような真似やめりゃいいのに。
そこかしこでファイル名の途中に文字化け文字が挟まってて嫌になる。
Re: (スコア:0)
ESMTPの「UTF8SMTP」に対応してるならオッケー
受信についてはRFC 5335
送信についてはRFC 5336