System.Net.Mail 和 =?utf-8?B?XXXXX.... 标头

发布于 2024-07-13 04:36:09 字数 892 浏览 4 评论 0原文

我尝试使用下面的代码通过 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;

我想强调的是,这种情况并不总是发生。

我究竟做错了什么?

I'm trying to use the code below to send messages via System.Net.Mail and am sometimes getting subjects like '=?utf-8?B?W3AxM25dIEZpbGV...' (trimmed). This is the code that's called:

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;

I'd like to emphasize that this does not happen all of the time.

What am I doing wrong?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

煞人兵器 2024-07-20 04:36:09

当您的主题包含 ASCII 范围之外的字符时,邮件软件必须对它们进行编码(RFC2822 邮件不允许标头中包含非 ASCII 字符)。 有两种方法可以做到这一点:

  • 引用的可打印(主题以 "=?utf-8?Q" 开头)
  • Base64(主题以 "=?utf-8?Q" 开头 ) "=?utf-8?B")

框架似乎认为 Base64 编码比引用打印编码更有效(=更短)。 当您的主题包含相对较多 ASCII 范围之外的字符时,这是有意义的。

回答你的问题:你没有做错任何事。 这就是带有非 ASCII 字符的互联网邮件的样子。 当然,读取此类邮件的软件应该检测并解码此类主题字段。

When your subject contains characters outside the ASCII range, then the mailing software must encode them (RFC2822 mail does not permit non-ASCII characters in headers). There are two ways to do this:

  • Quoted Printable (subject starts with "=?utf-8?Q")
  • Base64 (subject starts with "=?utf-8?B")

It appears that the framework has figured that the Base64 encoding is more efficient (=shorter) than the quoted-printable encoding. This makes sense when your subject contains relatively many characters outside the ASCII range.

To answer your question: You're doing nothing wrong. That's how internet mail with non-ASCII characters is supposed to look like. Of course, the software that reads such mail should detect and decode such subject fields.

凉世弥音 2024-07-20 04:36:09

我在调试相同问题时遇到了这篇文章,根据我的进一步调查,我可以为 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 时,第三个主题行为 256 字节- 编码。 我假设 Outlook 必须在显示主题行之前将其截断为 255 个字符...这很好,只不过它是通过将编码字符串截断为 255 个字节来实现的,这会切断编码终止符 (“?=”) ,使其无法解码。

这是 Outlook 中的错误,而不是您的邮件提供商或 .NET 中的错误; 您可以在 Outlook 中查看完整的、未截断的 UTF-8 编码主题行,方法是右键单击邮件列表中的邮件并从上下文菜单中选择“选项...”,然后在“Internet 标头”框中向下滚动,直到您会看到以“主题:”开头的行。

与 Andreas 所建议的情况相反,不仅当有许多非 ASCII 字符时,而且当有一个或多个非 ASCII 字符且主题行很长时,问题就会显现出来。 解决方法可能是使用较短的主题行或删除主题中的所有非 ASCII 字符。

(这个错误对我来说特别难以追踪,因为如上所述,问题数据不包含明显的非 ASCII 字符——只有一些不间断的空格。当您将它们打印到此外,如果您在 Visual Studio 调试器中更改字符串变量的值,它会默默地将它们替换为常规空格。)

I came across this post when I was debugging an identical problem, and based on my further investigations I can provide an alternate explanation to Andreas's:

The problem may be that your e-mail client software (Outlook 2003, in my case) is incorrectly decoding the subject line. In other words, it's a bug in Outlook, not in .NET or your program.

If you use a subject value like this (the letter "c" repeated 256 times), it displays fine in Outlook:

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

Likewise, if you use a subject like this (the letter "c" repeated 178 times, with a Unicode non-breaking space character appended), it also displays as expected in Outlook:

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

However, the following subject displays as "=?utf-8?B"-prepended garbage in Outlook:

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

The difference is that this third subject line is 256 bytes when UTF-8-encoded. I assume that Outlook must be truncating the subject line to 255 characters before displaying it... which would be fine except that it is doing this by truncating the encoded string to 255 bytes, which cuts off the encoding terminator ("?="), making it undecodable.

This is a bug in Outlook and not your mail provider or .NET; you can see the full, untruncated UTF-8 encoded subject line in Outlook by right-clicking on the message in your message list and selecting "Options..." from the context menu, then scrolling down in the "Internet Headers" box until you see the line starting with "Subject:".

Contrary to the situation that Andreas suggests, the problem manifests itself not only when there are many non-ASCII characters, but when there is one or more non-ASCII characters and the subject line is long. A workaround might be to use a shorter subject line or to strip out all the non-ASCII characters in your subject.

(This bug was particularly tricky for me to track down because, as above, the problem data included no obvious non-ASCII characters -- just a few non-breaking spaces. These display the same as regular ASCII spaces when you print them out to the console. Moreover, if you change the value of the string variable in the Visual Studio debugger, it silently replaces them with regular spaces.)

清眉祭 2024-07-20 04:36:09

答案可能在修剪主题的其余部分中——您提供的部分解码为“[p13n]文件”,但是如果您其中有任何非 ASCII 字符,那么我希望它能够按原样进行编码

The answer might be in the rest of the trimmed subject -- the section you provided decodes as "[p13n] File", but is you've any non-ASCII characters in there, then I would expect it to encode as it has

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文