цитируемая ошибка продолжения строки для печати? - PullRequest
Новая
       81

цитируемая ошибка продолжения строки для печати?

0 голосов
/ 02 ноября 2019

Я пишу код для генерации отчета и отправки его по электронной почте. В этом случае я пытаюсь встроить отчет в HTML-текст, но Outlook не правильно отображает части отчета. В частности, это, кажется, артефакты из цитируемой кодировки для печати. Я не вижу ничего плохого в своем зашифрованном тексте.

Я сузил проблему до следующего примера: 

Content-Type: multipart/mixed; boundary="===============0525238969=="
MIME-Version: 1.0
Subject: Your Message(s) from 11/15/2018 04:48:45 PM to 11/01/2019 04:48:45 PM
From: test@foo.com
To: test@foo.com,foo@test.com
Date: Fri, 01 Nov 2019 16:48:46 -0500
Content-Disposition: inline

--===============0525238969==
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable

<br/>
Your report:<br/>
<br/>
<table border=3D1>
<tr><td colspan=3D"11">Found 1 record(s) between 11/15/2018 04:48:45 PM and=
 11/01/2019 04:48:45 PM<br/></td></tr>
</table><br/>
=09=09=09
--===============0525238969==--

Сохранение этого файла в формате * .eml и открытие его вoutlook, я замечаю две проблемы:

1) Текст внутри ячейки таблицы имеет знак равенства вместо пробела перед 2-й датой: 

Found 1 record(s) between 11/15/2018 04:48:45 PM and=11/01/2019 04:48:45 PM
                                                    ^

он должен выглядеть следующим образом:

Found 1 record(s) between 11/15/2018 04:48:45 PM and 11/01/2019 04:48:45 PM
                                                    ^

2) В конце "= 0", предположительно, артефакт из символов табуляции, закодированный как = 09. Автоматическое удаление этих вкладок проблематично, поскольку отчет генерируется из редактируемого пользователем шаблона. Трудно понять, может ли символ табуляции быть релевантным в некоторых ситуациях.

На самом деле я могу решить 2-ю проблему, добавив дополнительный \ n в конце html-контента, но я включил его здесь вЕсли это важно для понимания проблемы №1 выше.

PS Я загрузил файл в «eM Client», и он не испытывает ни одного из этих глюков. Я склонен думать, что это может быть ошибка в Outlook, но было бы намного проще (и более вероятно), если бы это была моя ошибка.

1 Ответ

0 голосов
/ 10 ноября 2019

Проблема оказалась в том, что в содержании электронной почты использовались LF для перевода строки вместо CRLF, что требуется RFC. Очевидно, что Outlook пытается работать с содержимым LF, но в нем есть некоторые ошибки.

Если вы генерируете электронную почту из Python и столкнулись с этой проблемой, помните, что вам необходимо преобразовать ее выходные данные из LF в CRLF, прежде чем сохранять их в. eml файл или передача сообщения через SMTP. Это верно даже для Linux, потому что спецификация требует CRLF.

...