email — 电子邮件和 MIME 处理包 — Python 文档
email — 电子邮件和 MIME 处理包
源代码： :source:`Lib/email/__init__.py`
email 包是一个用于管理电子邮件消息的库。 它专门用于向 SMTP (RFC 2821)、NNTP 或其他服务器发送电子邮件； 这些是模块的功能，例如 smtplib 和 nntplib。 email 包尝试尽可能符合 RFC，支持 RFC 5322 和 RFC 6532，以及与 MIME 相关的 RFC，如 RFC 2045、RFC 2046、[X2520X]RFC 7X 、RFC 2183 和 RFC 2231。
电子邮件包的整体结构可分为三个主要组件，以及控制其他组件行为的第四个组件。
该包的核心组件是代表电子邮件消息的“对象模型”。 应用程序主要通过 message 子模块中定义的对象模型接口与包交互。 应用程序可以使用此 API 询问有关现有电子邮件的问题、构建新电子邮件或添加或删除本身使用相同对象模型接口的电子邮件子组件。 也就是说，根据电子邮件及其 MIME 子组件的性质，电子邮件对象模型是一个对象树结构，所有对象都提供 EmailMessage API。
该包的另外两个主要组件是 parser 和 generator。 解析器获取电子邮件消息的序列化版本（字节流）并将其转换为 EmailMessage 对象树。 生成器采用 EmailMessage 并将其转换回序列化的字节流。 （解析器和生成器也处理文本字符流，但不鼓励这种用法，因为很容易以一种或另一种方式结束无效的消息。）
控制组件是 policy 模块。 每个 EmailMessage、每个 generator 和每个 parser 都有一个关联的 policy 对象来控制其行为。 通常应用程序只需要在创建 EmailMessage 时指定策略，通过直接实例化 EmailMessage 来创建新电子邮件，或者通过使用 解析输入流解析器。 但是当使用 生成器 序列化消息时，可以更改策略。 例如，这允许从磁盘解析通用电子邮件消息，但在将其发送到电子邮件服务器时使用标准 SMTP 设置对其进行序列化。
电子邮件包尽力向应用程序隐藏各种管理 RFC 的详细信息。 从概念上讲，应用程序应该能够将电子邮件消息视为 unicode 文本和二进制附件的结构化树，而不必担心这些在序列化时如何表示。 然而，在实践中，通常需要至少了解一些管理 MIME 消息及其结构的规则，特别是 MIME“内容类型”的名称和性质以及它们如何识别多部分文档。 在大多数情况下，只有更复杂的应用程序才需要这种知识，即便如此，它也应该只是所讨论的高级结构，而不是如何表示这些结构的细节。 由于 MIME 内容类型在现代互联网软件（不仅仅是电子邮件）中被广泛使用，这对于许多程序员来说将是一个熟悉的概念。
以下部分描述了 email 包的功能。 我们从 message 对象模型开始，这是应用程序将使用的主要接口，然后是 parser 和 generator 组件。 然后我们覆盖了policy控件，就完成了对库主要组件的处理。
接下来的三个部分涵盖了包可能引发的异常以及 解析器 可能检测到的缺陷（不符合 RFC）。 然后我们介绍了 headerregistry 和 contentmanager 子组件，它们分别提供了对头和有效载荷进行更详细操作的工具。 这两个组件都包含与使用和生成非平凡消息相关的功能，但也记录了它们的可扩展性 API，这对高级应用程序很重要。
下面是一组使用前面部分中介绍的 API 基本部分的示例。
以上代表了电子邮件包的现代（unicode 友好）API。 其余部分，从 Message 类开始，涵盖了遗留的 compat32 API，它更直接地处理电子邮件消息的表示方式的细节。 compat32 API 不会 向应用程序隐藏 RFC 的详细信息，但对于需要在该级别运行的应用程序，它们可能是有用的工具。 本文档也与出于向后兼容性原因仍在使用 compat32 API 的应用程序相关。
3.6 版更改： 文档重组和重写以推广新的 EmailMessage/EmailPolicy API。
email 包文档的内容：
email.message：表示电子邮件email.parser：解析电子邮件email.generator：生成 MIME 文档email.policy：策略对象email.errors：异常和缺陷类email.headerregistry：自定义标题对象email.contentmanager：管理 MIME 内容email：示例
旧版 API：
