Заголовок письма Python странное поведение

Question

Декодер заголовка электронной почты Python для python2.7 или python3, похоже, имеет странное поведение при переключении между закодированным и некодированным текстом.

from email.header import decode_header
print decode_header("=?ISO-8859-1?B?QA==?=example.com");
print decode_header("=?ISO-8859-1?B?QA==?= example.com");
print decode_header("=?ISO-8859-1?Q?=40example?= .com");
print decode_header("=?ISO-8859-1?Q?=40example?=.com");

Вот результат

[('=?ISO-8859-1?B?QA==?=example.com', None)]
[('@', 'iso-8859-1'), ('example.com', None)]
[('@example', 'iso-8859-1'), ('.com', None)]
[('=?ISO-8859-1?Q?=40example?=.com', None)]

Во всех входных примерах кодированный текст является просто знаком @, и он должен интерпретироваться правильно, но это не так. Я думаю, что интерпретация RFC 1342 кажется мне неправильной. Python ожидает пробел или символ новой строки как конец закодированного текста. Я не вижу этого в RFC, RFC только говорит, что нужно пространство между несколькими закодированными текстами, когда я читаю это, а не между закодированным текстом и незакодированными частями текста. Поэтому всякий раз, когда вы видите «? =», Вы должны рассматривать это как конец закодированного текста, чего не делает python. Я хочу спросить экспертов, если это ошибка здесь или если я ошибся?

Виджай

Answer 1

Это со страницы 6 из RFC1342 :

Кодированное слово можно отличить от обычного «слова», «текста», или "ctext", как показано ниже: закодированное слово начинается с "=?", заканчивается на "? =", содержит ровно четыре "?" символы, включая разделители, и , за которым следует пробел или новая строка . Если «слово», «текст» или «ctext» не соответствует вышеуказанным критериям, он должен отображаться как появляется в заголовке сообщения.

Итак, пробел или символ новой строки требуется после закодированного текста.

Примеры закодированных заголовков из того же RFC:

   From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
   CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be>
   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

Answer 2

RFC 2047 определяет 3 местоположения, в которых может появляться «закодированное слово». Это требует разделения пробелов почти во всех случаях, даже между «закодированным словом» и незашифрованным текстом, и в большинстве случаев, когда разделение пробелов не требуется, это ошибки. Текст выглядит так (без применения опечаток и с ручным форматированием):

«Кодированное слово» может появиться в заголовке сообщения или части тела. заголовок по следующим правилам:

1. «Кодированное слово» может заменить «текстовый» токен (как определено в RFC 822). в любом поле заголовка Subject или Comments, любое сообщение расширения поле заголовка или любое поле части тела MIME, для которого тело поля определяется как «* текст». «Закодированное слово» может также появляться в любом определяемое пользователем ("X-") поле заголовка сообщения или части тела.

   Обычный текст ASCII и «закодированное слово» могут появляться вместе в то же поле заголовка. Однако «закодированное слово», которое появляется в Поле заголовка, определенное как '* text', ДОЛЖНО быть отделено от любого смежного 'кодированное слово' или 'текст' с помощью 'линейного пробела'.

2. «Кодированное слово» может появляться внутри «комментария», ограниченного «(» и «)», то есть везде, где разрешен «ctext». Точнее, RFC 822 Определение ABNF для «комментария» изменяется следующим образом:

   comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"
   

   Закодированное «Q» «кодированное слово», которое появляется в «комментарии», НЕ ДОЛЖНО содержать символы "(", ")" или " «кодированное слово», которое появляется в «комментарии», ДОЛЖНО быть отделено от любое смежное 'кодированное слово' или 'ctext' с помощью 'linear-white-space'.

   Важно отметить, что «комментарии распознаются только внутри «структурированные» полевые органы. В полях, тела которых определены как '* text', "(" и ")" рассматриваются как обычные символы, а не как ограничители комментариев, и применяется правило (1) этого раздела. (См. RFC 822, разделы 3.1.2 и 3.1.3)

3. В качестве замены «слова» сущности внутри «фразы», ​​например, тот, который предшествует адресу в заголовке From, To или Cc. АБНФ определение для «фразы» из RFC 822 становится таким:

   phrase = 1*( encoded-word / word )
   

   В этом случае набор символов, которые могут использоваться в кодировке "Q" «кодированное слово» ограничено: <upper and lower case ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_" (underscore, ASCII 95.)>. «закодированное слово», которое появляется внутри «фраза» ДОЛЖНА быть отделена от любого смежного «слова», «текста» или 'special' от 'linear-white-space'.