Подтвердить что ты не робот

System.Net.Mail и =? Utf-8? B? XXXXX.... Заголовки

Я пытаюсь использовать приведенный ниже код для отправки сообщений через System.Net.Mail и am иногда, получая такие темы, как "=? 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;

Я хотел бы подчеркнуть, что это не происходит все время.

Что я делаю неправильно?

4b9b3361

ОТВЕТЫ

Ответ 1

Если ваш субъект содержит символы вне диапазона ASCII, тогда программное обеспечение для почтовой рассылки должно кодировать их (почта RFC2822 не допускает не-ASCII-символы в заголовках). Существует два способа сделать это:

  • Quoted Printable (тема начинается с "=? utf-8? Q" )
  • Base64 (тема начинается с "=? utf-8? B" )

Похоже, что структура показала, что кодировка Base64 более эффективна (= короче), чем кодирование с кавычками. Это имеет смысл, когда ваш объект содержит относительно много символов вне диапазона ASCII.

Чтобы ответить на ваш вопрос: вы ничего не делаете неправильно. Это должно выглядеть как интернет-почта с символами, отличными от ASCII. Конечно, программное обеспечение, которое читает такую ​​почту, должно обнаруживать и декодировать такие поля темы.

Ответ 2

Я столкнулся с этим сообщением, когда я отлаживал идентичную проблему, и на основании моих дальнейших исследований я могу предоставить альтернативное объяснение Андреасу:

Проблема может заключаться в том, что ваше почтовое клиентское программное обеспечение (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})

Тем не менее, следующий объект отображается как "=? utf-8? B" -прерывный мусор в Outlook:

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

Разница в том, что эта третья строка темы составляет 256 байтов при кодировании UTF-8. Я предполагаю, что Outlook должен обрезать строку темы до 255 символов перед ее отображением... что было бы хорошо, за исключением того, что она делает это, обрезая закодированную строку до 255 байтов, которая отключает терминатор кодирования ( "? =" ), что делает его неприемлемым.

Это ошибка в Outlook, а не для вашего почтового провайдера или .NET; вы можете увидеть полную, необрезанную строку темы в кодировке UTF-8 в Outlook, щелкнув правой кнопкой мыши сообщение в списке сообщений и выбрав "Параметры..." в контекстном меню, затем прокручивая его в поле "Заголовки Интернета" до тех пор, пока вы видите строку, начинающуюся с "Subject:".

В отличие от ситуации, о которой говорит Андреас, проблема проявляется не только в том случае, когда имеется много символов, отличных от ASCII, но при наличии одного или нескольких символов, отличных от ASCII, и строка темы длинна. Обходной путь может заключаться в использовании более короткой строки темы или для выделения всех символов, отличных от ASCII, в вашем объекте.

(Эта ошибка была особенно сложной для меня, потому что, как и выше, данные проблемы не содержали очевидных символов, отличных от ASCII, - всего несколько разрывающих пробелов. Они отображают то же, что и обычные пространства ASCII при печати Кроме того, если вы измените значение строковой переменной в отладчике Visual Studio, оно тихо заменяет их обычными пробелами.)

Ответ 3

Ответ может быть в остальной части обрезанного объекта - раздел, который вы предоставили, декодируется как "[p13n] File", но есть ли у вас какие-либо символы, отличные от ASCII, тогда я бы ожидал, что он будет кодироваться как он имеет

Ответ 4

Хотя я не уверен, может быть, эта статья о MIME в wikipedia может помочь получить дополнительную справочную информацию.