Форматы сообщений

Форматы сообщений

29. Форматы сообщений. RFC822. MIME. Правила кодировки base64, quoted-printable.

RFC 822

Сообщения состоят из примитивного конверта (описанного в RFC 821), нескольких полей заголовка, пустой строки и, наконец, тела сообщения. Каждое поле заголовка (логически) состоит из одной строки ASCII-текста, содержащей имя поля, двоеточие и (в большинстве случаев) значение поля. RFC 822 был создан несколько десятилетий назад, и в нем нет четкого разграничения конверта и заголовка. Хотя частично стандарт был пересмотрен в RFC 2822, целиком обновить его было невозможно, поскольку RFC 822 уже был очень широко распространен. Обычно пользовательский агент формирует сообщение и передает его агенту передачи сообщений, который с помощью одного из полей заголовка создает конверт нового вида, представляющий собой некую старомодную смесь сообщения и конверта.

Основные поля заголовка, связанные с транспортировкой сообщения, перечислены в таблице 5.2 . Поле То: содержит DNS-адрес основного получателя. Возможно наличие и нескольких получателей. В поле Сс: указываются адреса дополнительных получателей. С точки зрения качества доставки, никакой разницы между основным и дополнительными получателями нет. Разница между ними чисто психологическая и может быть важна для людей, но совершенно не существует для почтовой системы. Термин Сс: (carbon copy — экземпляр, сделанный «под копирку») несколько устарел, так как при работе с компьютерами копировальная бумага вообще-то не используется, тем не менее, он прочно обосновался в электронной почте. Поле Всс: (Blind carbon copy — слепая копия) аналогично предыдущему, с той разницей, что в последнем случае строка этого поля не видна получателям (как основному, так и дополнительным). Это свойство позволяет рассылать одно письмо одновременно нескольким получателям так, что получатели не будут знать, что это письмо послано еще кому-либо, кроме них.

Таблица 5.2 — Поля заголовка стандарта RFC 822, связанные с транспортировкой сообщения

 

Поле	Значение
То:	Электронный адрес (адреса) основного получателя (получателей)
Сс:	Электронный адрес (адреса) дополнительного получателя (получателей)
Всс:	Электронный адрес (адреса) слепой копии
From:	Автор (авторы) сообщения
Sender:	Электронный адрес отправителя
Received:	Строка, добавляемая каждым агентом передачи сообщений на протяжении маршрута
Return-Path:	Может быть использовано для идентификации обратного пути к отправителю

Следующие два поля, From: и Sender:, сообщают, соответственно, кто составил и отправил сообщение.

Это могут быть разные люди. Например, написать письмо может руководитель предприятия, а отослать — его секретарша. В этом случае руководитель будет числиться в поле From:, а секретарша — в поле Sender. Поле From: является обязательным, тогда как поле Sender: может быть опущено, если его содержимое не отличается от содержимого поля From:. Эти поля нужны на случай, если со-общение доставить невозможно и об этом следует проинфор-мировать отправителя. Кроме того, по адресам, указанным в этих полях, может быть оправлен ответ.

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

Поле Return-Path: добавляется последним агентом передачи сообщений. Предполагалось, что это поле будет сообщать, как добраться до отправителя. Теоретически эта информация может быть собрана из всех полей Received: заголовка (кроме имени почтового ящика отправителя), однако на практике оно редко заполняется подобным образом и обычно просто содержит ад-рес отправителя.

Помимо полей, показанных в таблице 5.2 , сообщения стан-дарта RFC 822 могут также содержать широкий спектр полей заголовка, используемых пользовательским агентом или самим пользователем. Наиболее часто используемые поля заголовка приведены в таблице 5.3 . Информации в таблице достаточно, чтобы понять назначение полей, поэтому мы не станем рассмат-ривать их все подробно.

Таблица 5.3 — Некоторые поля, используемые в заголовке сообщения стандарта RFC 822

 

Поле	Значение
Date:	Дата и время отправки сообщения
Reply-to:	Электронный адрес, на который следует присылать ответ
Message-Id:	Уникальный номер для последующей сообщение ссылки на это
In-Reply-To:	Идентификатор Message-Id сообщения, в ответ на ко-торое посылается это сообщение
References:	Другие важные ссылки (идентификаторы Message-Id)
Keywords:	Ключевые слова, выбираемые пользователем
Subject:	Краткое изложение темы сообщения для отображения в одной строке

 

MIME — многоцелевые расширения электронной почты

Интернет

На заре существования сети ARPANET электронная почта состояла исключительно из текстовых сообщений, написанных на английском языке и представленных символами ASCII.

Для подобного применения стандарта RFC 822 было вполне достаточно: он определял формат заголовков, но оставлял содержимое сообщения полностью на усмотрение пользователей. На сегодняшний день требуется обеспечить возможность отправления сообщений со следующими характеристиками.

1.   Сообщения на языках с надстрочными знаками (напри-
мер, на французском, немецком, испанском и т.д.).

2.      Сообщения на языках, использующих алфавиты, отличные от латинского (например, на иврите или русском).

3.      Сообщения на языках без алфавитов (например, китайском, японском, корейском).

4.      Сообщения, вообще не являющиеся текстом (например, аудио или видео).

    Решение было предложено в документе RFC 1341, а более новая редакция была опубликована в RFC 2045-2049. Это решение, получившее название MIME (Multipurpose Internet Mail Extensions, — многоцелевые расширения электронной почты в Интернете), широко применяется в настоящий мо-мент. Далее приведено его описание. Дополнительную информацию о наборе стандартов MIME смотрите в RFC.

Основная идея стандартов MIME — продолжить использование формата RFC 822, но с добавлением структуры к телу сообщения и с определением правил кодировки He-ASCII-сообщений. Не отклоняясь от стандарта RFC 822, MIME-сообщения могут передаваться с помощью обычных почтовых программ и протоколов. Все, что нужно изменить, — это отправляющие и принимающие программы, которые пользователи могут создать для себя сами.

Стандартами MIME определяются пять новых заголовков сообщения, приведенных в таблице

Заголовок	Описание
MIME-Version:	Указывает версию стандартов MIME
Content-Description:	Описание содержимого. Строка обычного текста, информирующая о содержимом сообщения
Content-Id:	Уникальный идентификатор
Content-Transfer-Encoding:	Указывает способ кодировки тела сообщения для его передачи
Content-Type:	Тип и формат содержимого сообщения

Первый заголовок просто информирует пользовательского агента, получающего сообщение, что тот имеет дело с сообщением MIME, а также сообщает ему номер версии MIME, исполь-зуемой в этом сообщении. Если сообщение не содержит такого заголовка, то оно считается написанным на английском языке и обрабатывается соответствующим образом.

Заголовок Content-Description представляет собой ASCII-строку, информирующую о том, что находится в сообщении. Этот заголовок позволяет пользователю принять решение о том, нужно ли ему декодировать и читать сообщение. Если в строке сказано: «Фотография тушканчика Барбары», а получивший это сообщение не является любителем тушканчиков, то, вероятнее всего, он сразу удалит это сообщение, а не станет перекодировать его в цветную фотографию высокого разрешения.

Заголовок Content-Id содержит идентификатор содержимого сообщения. В нем используется тот же формат, что и в стандартном заголовке Message-Id:.

Заголовок Content-Transfer-Encoding сообщает о способе упаковки тела сообщения для его передачи по сети, которая мо-жет возражать против символов, отличных от букв, цифр и зна-ков препинания. Разработано пять схем (имеется возможность добавления новых схем).

Простейшая из них заключается в передаче просто ASCII-текста. Символы ASCII используют 7 разрядов и могут переда-ваться напрямую протоколом электронной почты при условии, что строка не превышает 1000 символов.

Следующая по простоте схема аналогична предыдущей, но использует 8-разрядные символы, то есть все значения байта от 0 до 255 включительно. Такая схема кодировки нарушает (исходный) протокол электронной почты Интернета, но используется в некоторых частях Интернета, в которых реализовано некоторое расширение исходного протокола. Хотя объявление о способе кодирования не делает его использование автоматически закон-ным, открытое объявление может, по крайней мере, в случае чего объяснить неправильную работу почтовых агентов. Сооб-щения, использующие 8-разрядную кодировку, также должны соблюдать правило о максимальной длине строки.

Еще хуже обстоит дело с сообщениями в двоичной коди-ровке. К ним относятся произвольные двоичные файлы, которые не только используют все 8 разрядов в байте, но еще и не со-блюдают ограничение на 1000 символов в строке. К этой кате-гории относятся исполняемые программные файлы. Не дается никакой гарантии, что эти двоичные сообщения будут доставле-ны корректно, но, тем не менее, очень многие пользователи все равно пересылают их друг другу.

Корректный способ кодирования двоичных сообщений состоит в использовании кодировки base64 (64-символьная кодировка), иногда называемой ASCII armor (ASCII-оплетка). При использовании данного метода группы по 24 бита разбиваются на четыре 6-разрядные единицы, каждая из которых посылается в виде обычного разрешенного ASCII-символа. В этой кодировке 6-разрядный символ 0 кодируется ASCII-символом «А», 1 — ASCII-символом «В» и т.д. Затем следуют 26 строчных букв — это уже 10 разрядов, и наконец, + и / для кодирования 62 и 63 соответственно. Последовательности == и = говорят о том, что последняя группа содержит только 8 или 16 бит соответственно. Символы перевода строки и возврата каретки игнорируются, поэтому их можно вставлять в любом месте для того, чтобы строки выглядели не слишком длинными. Таким способом можно передать любой двоичный код.

Для сообщений, почти полностью состоящих из символов ASCII, но с небольшими включениями не-ASCII-символов, подобный метод несколько неэффективен. Вместо него лучше применять кодировку quoted-printable (цитируемое печатное кодирование). Это просто 7-битный ASCII, в котором символы, соответствующие значениям ASCII-кода свыше 127, кодируются знаком равенства, за которым следуют две шестнадцатеричных цифры — ASCII-код символа.

Последний заголовок в таблице 5.4 представляет наибольший интерес. Он указывает тип тела сообщения. В документе RFC 2045 определены семь типов содержимого сообщений, каждый из которых распадается на несколько подтипов.

Тип	Подтип	Описание
Text	Plain	Неформатированный текст
Enriched	Текст с включением простых команд форматирования
Image	Gif	Неподвижное изображение в формате GIF
Jpeg	Неподвижное изображение в формате JPEG
Audio	Basic	Слышимый звук
Video	Mpeg	Видеофильм в формате MPEG
Application	Octet-stream	Неинтерпретируемая      последовательность байтов
Postscript	Документ для печати в формате PostScript
Message	Rfc822	Сообщение MIME RFC 822
	Partial	Сообщение разбито на части для передачи
External-body	Само сообщение должно быть сети получено по
Multipart	Mixed	Независимые части в указанном порядке
	Alternative	То же сообщение в другом формате
Parallel	Части  сообщения   следует   просматривать одновременно
Digest	Каждая часть является законченным сооб-щением стандарта RFC 822

RFC [АйТи бубен]

RFC (Request for Comments) — запрос комментариев (или заявка на обсуждение или тема для обсуждения). Документы содержащие технические спецификации и стандарты, широко применяемые в Интернет. В настоящее время первичной публикацией документов RFC занимается IETF под эгидой открытой организации Общество Интернета (Internet Society, ISOC). Правами на RFC обладает именно Общество Интернета.

Документация и переводы на русский язык RFC

• RFC

• RFC 2.0 — Русские Переводы RFC

• Репозиторий RFC на русском языке

• RFC и переводы

• Примеры популярных запросов RFC

• RFC на http://tools.ietf.org

Номер RFC	Описание	Ссылка	Примечание
RFC 822	Формат электронной почты, заменён RFC 2822		Bog BOS: Формат сообщений интернет (от RFC822 к RFC2822)
RFC 2822	Формат электронной почты
RFC 3550	Описан RTP -Real-Time Transport Protocol
RFC 3261	Описан Описание RFC протокола SIP: Session Initiation Protocol	3261	Документ довольно объемный, но тем, кто желает стать специалистом в Asterisk, рекомендуем прочитать по крайней мере первые 100 страниц и разобраться,как устанавливать соединения, поскольку эти знания будут необходимы для работы с историей SIP (sip debug из консоли Asterisk) и поиска с ее помощью причины невозможности установления соединений.
RFC 1918	Address Allocation for Private Internets	Описаны частные, серые, фейковый IP	10.0.0.0 — 10.255.255.255 (10/8 prefix) 172.16.0.0 — 172.31.255.255 (172.16/12 prefix) 192.168.0.0 — 192.168.255.255 (192.168/16 prefix)
RFC 1321	The MD5 Message-Digest Algorithm	Наиболее важные детали русского перевода RFC 1321
RFC 2425	MIME Content-Type for Directory Information	RFC 2425
RFC 2426	vCard MIME Directory Profile	RFC 2426
RFC 2516	Описан принцип работы протокола PPPoE (Point to Point Protocol over Ethernet)
3711
3875	The Common Gateway Interface (CGI) Version 1. 1
4771
3330	Special-Use IPv4 Addresses.	Зарезервированные адреса IPv4
1392		Internet Users’ Glossary, например Кто такой хакер?
RFC 2131	RFC 2131	Описание протокола Настройка DHCP сервера Linux, FreeBSD
RFC 2606	RFC 2606		Зарезервированные доменные имена, например example.com, example.net и др.
RFC 821	FQDN	Fully Qualified Domain Name — полностью определённое имя домена
RFC 3761	Технология ENUM
RFC 2068	Описывает протокол Методы и структура протокола HTTP	RFC 2068 Русский- описывает протокол Методы и структура протокола HTTP/1.1. RFC 2616:Hypertext Transfer Protocol — HTTP/1. 1. rfc2068 Протокол передачи гипертекста более подробный перевод на русский.
RFC 959	RFC 959	Описан протокол Раздел FTP: Протокол FTP, серверы, клиенты FTP для Linux и Windows
RFC 4954	RFC 4954	Расширение диалога SMTP — простой протокол передачи почты командой AUTH

[MS-OXCMAIL]: RFC 2822 и алгоритм преобразования MIME в объект электронной почты

Твиттер LinkedIn Фейсбук Эл. адрес

• Статья
• 17.08.2021
• 4 минуты на чтение

Указывает преобразование RFC 2822 и MIME в объект электронной почты. Алгоритм, который преобразует данные из стандартных соглашений электронной почты Интернета в Объекты сообщения.

Эта страница и связанное с ней содержимое могут быть часто обновляется. Рекомендуем подписаться на RSS канал для получения уведомлений об обновлениях.

Опубликованная версия

Дата	Версия протокола	Класс ревизии	загрузок
17.08.2021	22,0	Майор	PDF | ДОКС

Нажмите здесь, чтобы загрузить zip-файл всех PDF-файлов для протокола Exchange Server Документы.

Предыдущие версии

Дата	Версия протокола	Класс ревизии	загрузок
22. 04.2021	21,0	Майор	PDF | ДОКС
01.10.2018	20,0	Майор	PDF | ДОКС
24.07.2018	19,0	Майор	PDF | ДОКС
14.09.2016	18,0	Нет	PDF | ДОКС
13.06.2016	18,0	Нет	PDF | ДОКС
14.09.2015	18,0	Нет	PDF | ДОКС
26.05.2015	18,0	Нет	PDF | ДОКС
16. 03.2015	18,0	Майор	PDF | ДОКС
30.10.2014	17,0	Майор	PDF | ДОКС
31.07.2014	16,1	Нет	PDF | ДОКС
30.04.2014	16,1	Нет	ДОКС
10.02.2014	16,1	Нет	PDF | ДОКС
18.11.2013	16,1	Незначительный	PDF | ДОКС
26.07.2013	16,0	Майор	PDF | ДОКС
11. 02.2013	15,0	Майор	PDF | ДОКС
08.10.2012	14,0	Майор	ПДФ
16.07.2012	13,0	Нет	ПДФ
27.04.2012	13,0	Майор	ПДФ
20.01.2012	12,0	Майор	ПДФ
07.10.2011	11,0	Майор	ПДФ
05.08.2011	10,0	Майор	ПДФ
18. 03.2011	9,0	Майор	ПДФ
03.11.2010	8,0	Майор	ПДФ
04.08.2010	7,0	Майор	PDF | ДОКС
05.05.2010	6.0.0	Майор	PDF | ДОКС
10.02.2010	5.0.0	Майор	PDF | ДОКС
04.11.2009	4.0.0	Майор	PDF | ДОКС
15.07.2009	3,0	Редакция	PDF | ДОКС
10. 04.2009	2,0 ​​	Майор	PDF | ДОКС
04.03.2009	1,05	Редакция	PDF | ДОКС
04.02.2009	1,04	Редакция	PDF | ДОКС
03.12.2008	1,03	Редакция	PDF | ДОКС
03.09.2008	1,02	Редакция	PDF | ДОКС
06.08.2008	1.01	Редакция	PDF | ДОКС
27.06.2008	1,0	Майор	PDF | ДОКС
25. 04.2008	0,2	Редакция	PDF | ДОКС
04.04.2008	1.0.0	Майор	PDF | ДОКС

Предварительные версии

Время от времени Microsoft может опубликовать предварительную или предварительную версию технического задания по открытым спецификациям. документ для рассмотрения и обратной связи сообщества. Чтобы отправить отзыв для предварительного просмотра версия технического документа, пожалуйста, следуйте всем инструкциям, указанным для этот документ. Если к документу не указаны инструкции, пожалуйста, оставляйте отзывы, используя открытые форумы по спецификациям.

Период предварительного просмотра технического документа различается. Кроме того, не каждый технический документ будет опубликован для предварительного просмотра.

Предварительная версия этого документа может быть доступны на бирже Документы протокола сервера — страница предварительных документов. После предварительного просмотра периода самая последняя версия документа доступна на этой странице.

Ресурсы для разработчиков

Найти ресурсы для создания интероперабельных решений для программного обеспечения Microsoft, услуги, оборудование и продукты сторонних производителей:

Плагины и события, инструменты тестирования, Разработка Поддержка и открытые спецификации Центр разработки.

Уведомление о правах на интеллектуальную собственность для документации с открытыми спецификациями

• Техническая документация. Microsoft публикует Open Документация по спецификациям («настоящая документация») для протоколов, файл форматы, переносимость данных, компьютерные языки и поддержка стандартов. Кроме того, обзорные документы охватывают межпротокольные отношения и взаимодействия.

• Авторские права . На эту документацию распространяется Microsoft авторские права. Независимо от любых других условий, содержащихся в условиях использовать для веб-сайта Microsoft, на котором размещена эта документация, вы можете сделать его копии для разработки реализаций технологий, которые описана в этой документации и может распространять ее части в вашем реализации, которые используют эти технологии или в вашей документации как необходимые для надлежащего документирования реализации. Вы также можете распространять в ваша реализация, с изменениями или без них, любые схемы, IDL или код образцы, включенные в документацию. Это разрешение также распространяется на любые документы, на которые есть ссылки в документации Open Specifications.

• Нет коммерческой тайны . Microsoft не претендует на обмен секретные права в этой документации.

• Патенты . У Microsoft есть патенты, которые могут распространяться на ваши реализации технологий, описанных в открытых спецификациях документация. Ни это уведомление, ни доставка корпорацией Майкрософт этого документация предоставляет любые лицензии по этим патентам или любым другим патенты. Однако данный документ с открытыми спецификациями может быть охвачен Открытые спецификации Майкрософт Promise или сообщество Microsoft Обещать. Если вы предпочитаете письменную лицензию или если технологии, описанные в этой документации, не подпадают под действие Open Спецификации обещания или обещания сообщества, в зависимости от обстоятельств, патентные лицензии можно получить, обратившись по адресу iplg@microsoft. com.

• Лицензионные программы . Чтобы увидеть все протоколы в области в соответствии с определенной лицензионной программой и соответствующими патентами, посетите карту патентов.

• Товарные знаки . Названия компаний и продуктов, содержащихся в этой документации могут быть защищены товарными знаками или аналогичными правами на интеллектуальную собственность. права собственности. Настоящее уведомление не предоставляет никаких лицензий в соответствии с этими правами. Список товарных знаков Microsoft см. на странице www.microsoft.com/trademarks.

• Вымышленные имена . Пример компаний, организаций, продукты, доменные имена, адреса электронной почты, логотипы, люди, места и события, которые изображенные в этой документации являются вымышленными. Никакой связи с реальным компания, организация, продукт, доменное имя, адрес электронной почты, логотип, человек, место или событие предназначены или должны быть выведены.

Сохранение прав . Все остальные права защищены, и это уведомление не предоставляет никаких прав, кроме как конкретно описано выше, будь то косвенно, эстоппель или иным образом.

Инструменты . Документация Open Specifications не требует использования Microsoft инструменты программирования или среды программирования, чтобы вы могли разработать реализация. Если у вас есть доступ к инструментам программирования Microsoft и средах, вы можете свободно ими пользоваться. Определенный открытый Документы спецификаций предназначены для использования совместно с общедоступными доступные спецификации стандартов и искусство сетевого программирования и, как таковые, предположить, что читатель либо знаком с вышеупомянутым материалом, либо имеет непосредственный доступ к нему.

Поддержка. По вопросам и поддержке обращайтесь по адресу [email protected].

18.11. rfc822 — Анализ почтовых заголовков RFC 2822 — Редакционная документация

Устарело, начиная с версии 2. 3: пакет электронной почты следует использовать вместо rfc822. модуль. Этот модуль присутствует только для обеспечения обратной совместимости, и был удален в Python 3.

Этот модуль определяет класс Message, который представляет сообщение», как определено стандартом Интернета RFC 2822 . [1] Такие сообщения состоит из набора заголовков сообщения и тела сообщения. Этот модуль также определяет вспомогательный класс AddressList для разбора RFC 2822 адреса. Пожалуйста, обратитесь к RFC для получения информации о конкретном синтаксисе RFC 2822 сообщения.

Модуль почтового ящика предоставляет классы для чтения почтовых ящиков, созданных различные почтовые программы конечного пользователя.

класс rfc822.Message ( файл [ с возможностью поиска ])

Экземпляр Message создается с входным объектом в качестве параметра. Сообщение зависит только от объекта ввода, имеющего метод readline(); в в частности, подходят обычные файловые объекты. Экземпляр читает заголовки из введите объект до строки-разделителя (обычно это пустая строка) и сохраните их в экземпляр. Тело сообщения, следующее за заголовками, не используется.

Этот класс может работать с любым объектом ввода, который поддерживает функцию readline(). метод. Если входной объект имеет возможность искать и говорить, метод rewindbody() будет работать; также недопустимые строки будут отодвинуты назад на входной поток. Если во входном объекте отсутствует поиск, но есть непрочитанный() метод, который может отодвигать строку ввода, Message будет использовать его для отодвинуть незаконные линии. Таким образом, этот класс можно использовать для разбора сообщений, приходящих из буферизованного потока.

Необязательный аргумент с возможностью поиска предоставляется в качестве обходного пути для некоторых stdio. библиотеки, в которых функция tell() отбрасывает буферизованные данные до того, как обнаружит, что системный вызов lseek() не работает. Для максимальной мобильности вы следует установить аргумент поиска равным нулю, чтобы предотвратить этот начальный Tell() при передаче невидимого объекта, такого как файловый объект, созданный из сокета объект.

Строки ввода, считанные из файла, могут завершаться либо CR-LF, либо одиночный перевод строки; завершающий CR-LF заменяется одним переводом строки перед строка сохраняется.

Все сопоставления заголовков выполняются независимо от верхнего или нижнего регистра; например m[‘From’], m[‘from’] и m[‘FROM’] дают один и тот же результат.

класс rfc822.AddressList (поле )

Вы можете создать экземпляр вспомогательного класса AddressList, используя одну строку Параметр, разделенный запятыми список из RFC 2822 адресов для анализа. ( параметр None дает пустой список.)

rfc822.quote( 9ул. 0844 )

Возвращает новую строку с обратной косой чертой в str , замененную двумя обратными косыми чертами и двойные кавычки заменены на обратную косую черту — двойные кавычки.

rfc822.unquote( стр )

Возвращает новую строку, которая представляет собой версию без кавычек строки str . Если стр заканчивается и начинается с двойных кавычек, они удаляются. Аналогично, если str заканчивается и начинается с угловых скобок, они снимаются.

rfc822.parseaddr( адрес )

Разобрать адрес , который должен быть значением некоторого поля, содержащего адрес, например как или , в составляющее его «настоящее имя» и части «адреса электронной почты». Возвращает кортеж этой информации, если синтаксический анализ терпит неудачу, и в этом случае возвращается 2-кортеж (None, None).

rfc822.dump_address_pair( пара )

Функция, обратная функции parseaddr(), принимает двойку вида (настоящее имя, email_address) и возвращает строковое значение, подходящее для или заголовок. Если первый элемент пара ложна, то второй элемент возвращается без изменений.

rfc822.parsedate( дата )

Попытки разобрать дату в соответствии с правилами RFC 2822 . однако некоторые почтовые программы не следуют указанному формату, поэтому функция parsedate() пытается угадывать правильно в таких случаях. date — это строка, содержащая RFC 2822 . дату, например «Пн, 20 ноября 1995 г., 19:12:08 -05:00». Если удастся разобрать дата, parsedate() возвращает 9-tuple, который может быть передан непосредственно в время.mktime(); в противном случае None будет возвращено. Обратите внимание, что индексы 6, 7 и 8 результирующего кортежа нельзя использовать.

rfc822.parsedate_tz( дата )

Выполняет ту же функцию, что и parsedate(), но возвращает либо None, либо 10-кортеж; первые 9 элементов составляют кортеж, который можно передать непосредственно в time.mktime(), а десятый — смещение часового пояса даты от UTC. (что является официальным термином для среднего времени по Гринвичу). (Обратите внимание, что знак смещение часового пояса противоположно знаку time.timezone переменная для того же часового пояса; последняя переменная соответствует стандарту POSIX в то время как этот модуль следует за RFC 2822 . ) Если во входной строке нет часового пояса, последний элемент возвращаемого кортежа — None. Обратите внимание, что индексы 6, 7 и 8 результирующего кортежа непригодны для использования.

rfc822.mktime_tz( кортеж )

Превратите кортеж из 10, возвращенный функцией parsedate_tz(), в отметку времени UTC. Если элемент часового пояса в кортеже равен None, предполагается местное время. Незначительный недостаток: это сначала интерпретирует первые 8 элементов как местное время, а затем компенсирует разницу часовых поясов; это может привести к небольшой ошибке вокруг даты перехода на летнее время. Недостаточно, чтобы беспокоиться об обычном использовании.

См. также

Модуль электронной почты

Комплексный пакет для обработки электронной почты; заменяет модуль rfc822.

Модуль почтового ящика

Классы для чтения различных форматов почтовых ящиков, создаваемых почтовыми программами конечных пользователей.

Модуль mimetools

Подкласс rfc822.Message, который обрабатывает закодированные сообщения MIME.

18.11.1. Message Objects

Экземпляр Message имеет следующие методы:

Сообщение.rewindbody() 908:50

Перейти к началу тела сообщения. Это работает, только если файловый объект доступный для поиска.

Возвращает канонизированное имя поля строки (ключ словаря, который будет использоваться индексировать его), если строка является допустимым заголовком RFC 2822 ; в противном случае возвращает Нет (подразумевается, что синтаксический анализ должен быть остановлен здесь, а строка должна быть возвращена на входной поток). Иногда полезно переопределить этот метод в подкласс.

Сообщение.islast( строка )

Вернуть true, если данная строка является разделителем, на котором сообщение должно остановиться. строка-разделитель потребляется, и место чтения файлового объекта позиционируется сразу после него. По умолчанию этот метод просто проверяет, что строка пустой, но вы можете переопределить его в подклассе.

Возвращает True, если данная строка должна быть полностью проигнорирована, просто пропущена. По по умолчанию это заглушка, которая всегда возвращает False, но вы можете переопределить ее в подкласс.

Возвращает список строк, состоящий из всех заголовков, соответствующих имени , если они есть. Каждый физическая строка, является ли она продолжением строки или нет, представляет собой отдельный список вещь. Вернуть пустой список, если ни один заголовок не соответствует name .

Вернуть список строк, содержащих первый заголовок, соответствующий имени , и его строки продолжения, если таковые имеются. Возвратите None, если нет совпадения заголовка имя .

Возвращает одну строку, состоящую из текста после двоеточия в первом заголовок соответствует имени . Это включает начальные пробелы, конечные перевод строки, а также внутренние переводы строки и пробелы, если есть какое-либо продолжение линия(и) присутствовала. Возвратите None, если нет заголовка, соответствующего имени .

Возвращает одну строку, состоящую из последнего заголовка, совпадающего с именем , но убрать начальные и конечные пробелы. Внутренние пробелы не удаляются. Факультативный аргумент по умолчанию может быть используется для указания другого значения по умолчанию, которое будет возвращено, когда нет заголовка соответствие имени ; по умолчанию нет. Это предпочтительный способ получения проанализированных заголовков.

Message.get( имя [ по умолчанию ])

Псевдоним для getheader(), чтобы сделать интерфейс более совместимым с обычные словари.

Сообщение.getaddr( имя )

Вернуть пару (полное имя, адрес электронной почты), проанализированную из строки, возвращенной получить заголовок (имя). Если заголовок, соответствующий имени , не существует, вернуть (None, Никто); в противном случае и полное имя, и адрес (возможно, пустые) струны.

Пример: Если m первый заголовок содержит строку ‘[email protected] (Джек Янсен)’, то m.getaddr(‘From’) даст пару («Джек Янсен», «[email protected]»). Если заголовок содержал «Джек Янсен ‘, это даст точно такой же результат.

Message.getaddrlist( имя )

Это похоже на getaddr(list), но анализирует заголовок, содержащий список адреса электронной почты (например, заголовок) и возвращает список (полный имя, адрес электронной почты) пары (даже если в шапке был только один адрес). Если нет заголовка, соответствующего имени , верните пустой список.

Если существует несколько заголовков, соответствующих именованному заголовку (например, если имеется несколько заголовки), все анализируются на наличие адресов. Любые строки продолжения именованные заголовки также анализируются.

Message.getdate( имя )

Получить заголовок с помощью getheader() и разобрать его на совместимый с 9 кортежами с time.mktime(); обратите внимание, что поля 6, 7 и 8 не используются. Если нет заголовка, соответствующего name , или он не поддается анализу, верните None.

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

Message.getdate_tz( имя )

Получить заголовок с помощью getheader() и разобрать его на 10-кортеж; в первые 9 элементов сделают кортеж совместимым с time.mktime(), а 10-е число — это число, указывающее смещение часового пояса даты от UTC. Обратите внимание, что поля 6, 7 и 8 не используются. Аналогично getdate(), если есть нет заголовка, соответствующего name , или он не поддается разбору, возвращает None.

Экземпляры сообщений также поддерживают ограниченный интерфейс сопоставления. В в частности: m[name] похож на m.getheader(name), но вызывает KeyError если нет соответствующего заголовка; и len(m), m.get(имя[ по умолчанию]), имя в m, m.keys(), m.values() m.items() и m.setdefault(name[ default]) действует как положено, с одним отличием что setdefault() использует пустую строку в качестве значения по умолчанию. Экземпляры сообщений также поддерживают сопоставление доступного для записи интерфейса m[name] = значение и del m[имя]. Объекты сообщений не поддерживают clear(), copy(), popitem() или update() картографический интерфейс. (Поддержка get() и setdefault() была только добавлено в Python 2.2.)

Наконец, экземпляры Message имеют некоторые общедоступные переменные экземпляра:

Список, содержащий полный набор строк заголовков в том порядке, в котором они были прочитаны (за исключением того, что вызовы setitem могут нарушить этот порядок). Каждая строка содержит конечная новая строка. Пустая строка, завершающая заголовки, не содержится в список.

Сообщение.fp

Файл или файлоподобный объект, переданный во время создания экземпляра. Это можно использовать для прочитать содержание сообщения.

Сообщение.unix от

Строка Unix From, если она была в сообщении, или пустая строка. Это требуется для повторного создания сообщения в некоторых контекстах, таких как mbox-стиль файл почтового ящика.

18.11.2. Объекты AddressList

Экземпляр AddressList имеет следующие методы:

Список адресов.__len__()

Вернуть количество адресов в списке адресов.

Список адресов.__str__() 908:50

Вернуть канонизированное строковое представление списка адресов. Адреса отображается в форме «имя» <хост@домен>, разделенных запятыми.

AddressList.__add__( список )

Вернуть новый экземпляр AddressList, содержащий все адреса в обоих Операнды AddressList с удаленными дубликатами (установить объединение).