2.2 版新增。
The email 包是用于管理电子邮件的库，包括 MIME 和其它 RFC 2822 -based message documents. It subsumes most of the functionality in several older standard modules such as rfc822 , mimetools , multifile , and other non-standard packages such as mimecntl . It is specifically not 旨在将电子邮件消息发送给 SMTP ( RFC 2821 )、NNTP (网络新闻传输协议)、或其它服务器；这些是模块函数，譬如 smtplib and nntplib 。 email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822 , such MIME-related RFCs as RFC 2045 , RFC 2046 , RFC 2047 ，和 RFC 2231 .
The primary distinguishing feature of the email package is that it splits the parsing and generating of email messages from the internal object model representation of email. Applications using the email package deal primarily with objects; you can add sub-objects to messages, remove sub-objects from messages, completely re-arrange the contents, etc. There is a separate parser and a separate generator which handles the transformation from flat text to the object model, and then back to flat text again. There are also handy subclasses for some common MIME object types, and a few miscellaneous utilities that help with such common tasks as extracting and parsing message field values, creating RFC-compliant dates, etc.
以下章节描述的功能源于 email package. The ordering follows a progression that should be common in applications: an email message is read as flat text from a file or other source, the text is parsed to produce the object structure of the email message, this structure is manipulated, and finally, the object tree is rendered back into flat text.
It is perfectly feasible to create the object structure out of whole cloth — i.e. completely from scratch. From there, a similar progression can be taken as above.
Also included are detailed specifications of all the classes and modules that the email package provides, the exception classes you might encounter while using the email package, some auxiliary utilities, and a few examples. For users of the older mimelib package, or previous versions of the email package, a section on differences and porting is provided.
内容源于 email 包文档编制：
另请参阅
This table describes the release history of the email package, corresponding to the version of Python that the package was released with. For purposes of this document, when you see a note about change or added versions, these refer to the Python version the change was made in, not the email package version. This table also describes the Python compatibility of each version of the package.
| email version | distributed with | compatible with |
|---|---|---|
| 1.x | Python 2.2.0 to Python 2.2.1 | no longer supported |
| 2.5 | Python 2.2.2+ and Python 2.3 | Python 2.1 to 2.5 |
| 3.0 | Python 2.4 | Python 2.3 to 2.5 |
| 4.0 | Python 2.5 | Python 2.3 to 2.5 |
Here are the major differences between email version 4 and version 3:
All modules have been renamed according to PEP 8 standards. For example, the version 3 module email.Message 被重命名为 email.message in version 4.
A new subpackage email.mime was added and all the version 3 email.MIME* modules were renamed and situated into the email.mime subpackage. For example, the version 3 module email.MIMEText 被重命名为 email.mime.text .
Note that the version 3 names will continue to work until Python 2.6 .
The email.mime.application module was added, which contains the MIMEApplication 类。
Methods that were deprecated in version 3 have been removed. These include Generator.__call__() , Message.get_type() , Message.get_main_type() , Message.get_subtype() .
Fixes have been added for RFC 2231 support which can change some of the return types for Message.get_param and friends. Under some circumstances, values which used to return a 3-tuple now return simple strings (specifically, if all extended parameter segments were unencoded, there is no language and charset designation expected, so the return type is now a simple string). Also, %-decoding used to be done for both encoded and unencoded segments; this decoding is now done only for encoded segments.
Here are the major differences between email version 3 and version 2:
Here are the differences between email version 2 and version 1:
The email.Header and email.Charset modules have been added.
The pickle format for 消息 instances has changed. Since this was never (and still isn’t) formally defined, this isn’t considered a backward incompatibility. However if your application pickles and unpickles 消息 instances, be aware that in email version 2, 消息 instances now have private variables _charset and _default_type .
Several methods in the 消息 class have been deprecated, or their signatures changed. Also, many new methods have been added. See the documentation for the 消息 class for details. The changes should be completely backward compatible.
The object structure has changed in the face of message/rfc822 content types. In email version 1, such a type would be represented by a scalar payload, i.e. the container message’s is_multipart() returned false, get_payload() was not a list object, but a single 消息 实例。
This structure was inconsistent with the rest of the package, so the object representation for message/rfc822 content types was changed. In email version 2, the container does return True from is_multipart() ，和 get_payload() returns a list containing a single 消息 项。
Note that this is one place that backward compatibility could not be completely maintained. However, if you’re already testing the return type of get_payload() , you should be fine. You just need to make sure your code doesn’t do a set_payload() 采用 消息 instance on a container with a content type of message/rfc822 .
The Parser constructor’s strict argument was added, and its parse() and parsestr() methods grew a headersonly 自变量。 strict flag was also added to functions email.message_from_file() and email.message_from_string() .
Generator.__call__() is deprecated; use Generator.flatten instead. The 生成器 class has also grown the clone() 方法。
The DecodedGenerator 类在 email.generator module was added.
The intermediate base classes MIMENonMultipart and MIMEMultipart have been added, and interposed in the class hierarchy for most of the other MIME-related derived classes.
The _encoder 自变量到 MIMEText constructor has been deprecated. Encoding now happens implicitly based on the _charset 自变量。
The following functions in the email.Utils module have been deprecated: dump_address_pairs() , decode() ，和 encode() . The following functions have been added to the module: make_msgid() , decode_rfc2231() , encode_rfc2231() ，和 decode_params() .
The non-public function email.Iterators._structure() 被添加。
The email package was originally prototyped as a separate library called mimelib . Changes have been made so that method names are more consistent, and some methods or modules have either been added or removed. The semantics of some of the methods have also changed. For the most part, any functionality available in mimelib is still available in the email package, albeit often in a different way. Backward compatibility between the mimelib package and the email package was not a priority.
Here is a brief description of the differences between the mimelib 和 email packages, along with hints on how to port your applications.
Of course, the most visible difference between the two packages is that the package name has been changed to email . In addition, the top-level package has the following differences:
The 消息 class has the following differences:
The Parser class has no differences in its public interface. It does have some additional smarts to recognize message/delivery-status type messages, which it represents as a 消息 instance containing separate 消息 subparts for each header block in the delivery status notification [1] .
The 生成器 class has no differences in its public interface. There is a new class in the email.generator module though, called DecodedGenerator which provides most of the functionality previously available in the Message.getpayloadastext() 方法。
The following modules and classes have been changed:
The MIMEBase class constructor arguments _major and _minor have changed to _maintype and _subtype 分别。
The Image class/module has been renamed to MIMEImage 。 _minor argument has been renamed to _subtype .
The 文本 class/module has been renamed to MIMEText 。 _minor argument has been renamed to _subtype .
The MessageRFC822 class/module has been renamed to MIMEMessage . Note that an earlier version of mimelib called this class/module RFC822 , but that clashed with the Python standard library module rfc822 on some case-insensitive file systems.
Also, the MIMEMessage class now represents any kind of MIME message with main type message . It takes an optional argument _subtype which is used to set the MIME subtype. _subtype 默认为 rfc822 .
mimelib provided some utility functions in its address and date modules. All of these functions have been moved to the email.utils 模块。
The MsgReader class/module has been removed. Its functionality is most closely supported in the body_line_iterator() function in the email.iterators 模块。
脚注
| [1] | Delivery Status Notifications (DSN) are defined in RFC 1894 . |
