email — Email 和 MIME 处理包 ¶

源代码： Lib/email/__init__.py

---

email 包是用于管理电子邮件消息的库。具体来说，它是 not 旨在将电子邮件消息发送给 SMTP ( RFC 2821 )、NNTP (网络新闻传输协议)、或其它服务器；这些是模块函数，譬如 smtplib and nntplib 。 email 包试图尽可能兼容 RFC，支持 RFC 5322 and RFC 6532 ，及这种 MIME 相关 RFC 如 RFC 2045 , RFC 2046 , RFC 2047 , RFC 2183 ，和 RFC 2231 .

email 包的整体结构可分为 3 个主要组件，加控制其它组件行为的第 4 个组件。

包的中心组件是表示 Email 消息的对象模型。应用程序与包交互首要透过对象模型接口，定义于 message 子模块。应用程序可以使用此 API 询问有关现有 Email 的问题、构建新的 Email、添加或移除自身使用相同对象模型接口的 Email 子组件。也就是说，遵循 Email 消息及其 MIME 子组件的性质，Email 对象模型是对象的树结构，全部提供 EmailMessage API.

包的其它 2 主要组件是 parser 和 generator 。剖析器接受 Email 消息的序列化版本 (字节流) 并将其转换成树 EmailMessage 对象。生成器接受 EmailMessage 并将其转换回序列化字节流 (剖析器和生成器还处理文本字符流，但这种用法不受鼓励，因为很容易按一种或另一种方式结束无效消息)。

控制组件是 policy 模块。每个 EmailMessage ，每个 generator ，和每个 parser 有关联 policy 对象 (控制其行为)。通常，应用程序只需指定策略当 EmailMessage 被创建，要么通过直接实例化 EmailMessage 以创建新的 Email，或通过剖析输入流使用 parser 。但可以改变策略当序列化消息使用 generator 。例如，这允许从磁盘剖析一般 Email 消息，但使用标准 SMTP 设置将其序列化，当将它发送给 Email 服务器时。

email 包尽最大努力对应用程序隐藏各种支配 RFC 的细节。从概念上讲，应用程序应该能够将 Email 消息视为 Unicode 文本和二进制附件的结构化树，而不必担心这些在序列化时如何表示。不管怎样，在实践中，经常有必要知道支配 MIME 消息及其结构的至少一些规则，具体来说，MIME 内容类型的名称和性质，及它们如何识别多部分文档。在大多数情况下，仅更复杂应用程序才要求这种知识，即便如此，它也应该只是有问题的高级结构，而不是如何表示这些结构的细节。由于 MIME 内容类型在现代 Internet 软件 (不仅仅是 Email) 中的广泛使用，因此对于很多程序员来说这是很熟悉的概念。

以下章节描述的功能源于 email 包。开始于 message 对象模型，这是应用程序将使用的首要接口，之后采用 parser and generator 组件。然后覆盖 policy 控件，完成对库主要组件的处理。

接下来的 3 章节涵盖包可能引发的异常和缺陷 (不符合 RFC) parser 可能检测。然后涵盖 headerregistry 和 contentmanager 子组件，分别提供对 Header 头和负载做更详细操纵的工具。这 2 组件包含消耗和产生非通俗消息的相关特征，但也文档化了它们的可扩展性 API，高级应用程序对此很感兴趣。

紧接着是使用之前章节涵盖的基础 API 部分的一组范例。

上文表示 email 包的现代 (Unicode 友好) API。其余章节，开始于 Message 类，覆盖传统 compat32 API 更直接处理 Email 消息的表示细节。 compat32 API does not 对应用程序隐藏 RFC 细节，但对于需要在该级别运转的应用程序，它们可以是有用工具。此文档编制还相关的应用程序仍在使用 compat32 API 出于向后兼容性原因。

内容源于 email 包文档编制：

传统 API：

上一话题

互联网数据处理

下一话题

email.message ：表示 Email 消息