web-dev-qa-db-ja.com

System.Net.Mailおよび=?utf-8?B?XXXXX ....ヘッダー

以下のコードを使用してSystem.Net.Mail経由でメッセージを送信しようとしていますが、時々'=?utf-8?B?W3AxM25dIEZpbGV...'(トリミング)のような件名を取得しています。これは呼ばれるコードです:

MailMessage message = new MailMessage()
{
    From = new MailAddress("[email protected]", "Service"),
    BodyEncoding = Encoding.UTF8,
    Body = body,
    IsBodyHtml = true,
    ReplyTo = new MailAddress("[email protected]"),
    SubjectEncoding = Encoding.UTF8
};

foreach (string emailAddress in addresses)
{
    message.To.Add(new MailAddress(emailAddress.Trim(), "Person"));
}

message.Subject = subject;

これが常に発生するわけではないことを強調したいと思います。

私は何が間違っているのですか?

22

件名にASCIIの範囲外の文字が含まれている場合、メールソフトウェアはそれらをエンコードする必要があります(RFC2822メールではヘッダーに非ASCII文字を使用できません)。これを行うには2つの方法があります。

  • Quoted Printable(件名は"=?utf-8?Q"で始まります)
  • Base64(件名は"=?utf-8?B"で始まります)

フレームワークは、Base64エンコーディングがquoted-printableエンコーディングよりも効率的(=短い)であると考えているようです。これは、件名にASCIIの範囲外の比較的多くの文字が含まれている場合に意味があります。

あなたの質問に答えるために:あなたは何も悪いことをしていません。これは、ASCII以外の文字を含むインターネットメールがどのように見えるかを示しています。もちろん、そのようなメールを読み取るソフトウェアは、そのような件名フィールドを検出してデコードする必要があります。

35
user49572

同じ問題をデバッグしているときにこの投稿に出くわしました。さらに調査した結果、Andreasに別の説明を提供できます。

問題は、電子メールクライアントソフトウェア(私の場合はOutlook 2003)が件名を誤ってデコードしていることである可能性があります。つまり、これはOutlookのバグであり、.NETやプログラムのバグではありません。

このような件名の値(文字「c」が256回繰り返される)を使用すると、Outlookで正常に表示されます。

subject = New String("c"c, 256)

同様に、このような件名を使用すると(文字「c」が178回繰り返され、Unicodeの改行なしスペース文字が追加されます)、Outlookでも期待どおりに表示されます。

subject = New String("c"c, 178) + System.Text.Encoding.UTF8.GetChars(New Byte() {194, 160})

ただし、次の件名はOutlookで「=?utf-8?B」が付加されたゴミとして表示されます。

subject = New String("c"c, 179) + System.Text.Encoding.UTF8.GetChars(New Byte() {194, 160})

違いは、UTF-8でエンコードされた場合、この3番目の件名は256バイトであるということです。 Outlookは、件名を表示する前に255文字に切り捨てる必要があると思います...エンコードされた文字列を255バイトに切り捨ててエンコードターミネーター( "?=")を切り捨てることを除いて、これは問題ありません。 、解読不能にします。

これはOutlookのバグであり、メールプロバイダーや.NETではありません。メッセージリストのメッセージを右クリックし、コンテキストメニューから[オプション...]を選択してから、[インターネットヘッダー]ボックスを下にスクロールすると、Outlookで完全な切り捨てられていないUTF-8エンコードされた件名を表示できます。 「Subject:」で始まる行が表示されます。

アンドレアスが示唆する状況とは逆に、問題は非ASCII文字が多い場合だけでなく、1つ以上の非ASCII文字があり、件名が長い場合に現れます。回避策は、短い件名を使用するか、件名のすべての非ASCII文字を削除することです。

(このバグは、上記のように、問題のデータに明らかな非ASCII文字が含まれていなかったため、追跡するのが特に困難でした。これらは、通常のASCIIスペースと同じように表示されます。それらをコンソールに出力します。さらに、Visual Studioデバッガーで文字列変数の値を変更すると、サイレントに通常のスペースに置き換えられます。)

14
jcl

答えは、トリミングされた件名の残りの部分にある可能性があります。指定したセクションは「[p13n]ファイル」としてデコードされますが、そこに非ASCII文字が含まれている場合は、そのままエンコードされると思います。

2
Rowland Shaw