email
——电子邮件和MIME处理包¶
这个 email
包是用于管理电子邮件的库。具体来说 not 设计用于向SMTP发送任何电子邮件 (RFC 2821 ,nntp或其他服务器;这些是模块的功能,例如 smtplib
和 nntplib
. 这个 email
包尝试尽可能符合RFC,支持 RFC 5233 和 RFC 6532 以及与mime相关的rfc RFC 2045 , RFC 2046 , RFC 2047 , RFC 2183 和 RFC 2231 .
电子邮件包的总体结构可以分为三个主要组件,以及控制其他组件行为的第四个组件。
包的中心组件是一个表示电子邮件消息的“对象模型”。应用程序主要通过中定义的对象模型接口与包进行交互。 message
子模块。应用程序可以使用此API询问有关现有电子邮件的问题,构造新电子邮件,或者添加或删除自己使用相同对象模型接口的电子邮件子组件。也就是说,根据电子邮件及其mime子组件的性质,电子邮件对象模型是一个对象的树结构,所有这些对象都提供 EmailMessage
应用程序编程接口。
包的其他两个主要组件是 parser
以及 generator
. 解析器获取电子邮件消息的序列化版本(字节流),并将其转换为 EmailMessage
物体。生成器需要 EmailMessage
并将其转换回序列化的字节流。(解析器和生成器也处理文本字符流,但不鼓励这种用法,因为这样很容易以某种方式无效的消息结束。)
控制组件是 policy
模块。每个 EmailMessage
,每一个 generator
和每一个 parser
有关联的 policy
控制其行为的对象。通常应用程序只需要在 EmailMessage
通过直接实例化 EmailMessage
创建新电子邮件,或通过使用 parser
. 但是当使用 generator
.例如,这允许从磁盘分析通用电子邮件,但在将其发送到电子邮件服务器时,可以使用标准的SMTP设置对其进行序列化。
电子邮件包尽其所能隐藏应用程序中各种管理的RFC的详细信息。从概念上讲,应用程序应该能够将电子邮件视为Unicode文本和二进制附件的结构化树,而不必担心在序列化时如何表示这些内容。然而,在实践中,通常需要了解至少一些管理mime消息及其结构的规则,特别是mime“内容类型”的名称和性质以及它们如何识别多部分文档。在大多数情况下,这种知识应该只需要用于更复杂的应用程序,即使这样,它也应该只是有问题的高层结构,而不是那些结构如何表示的细节。由于mime内容类型在现代互联网软件中被广泛使用(不仅仅是电子邮件),这将是许多程序员熟悉的概念。
以下各节介绍了 email
包裹。我们从 message
对象模型,它是应用程序将使用的主要接口,然后使用 parser
和 generator
组件。然后我们来报道 policy
控件,完成对库的主要组件的处理。
接下来的三个部分涵盖了包可能提出的例外情况以及 parser
可以检测到。然后我们来报道 headerregistry
以及 contentmanager
子组件,分别提供用于对头段和有效负载进行更详细操作的工具。这两个组件都包含与消费和生成非琐碎消息相关的特性,而且还记录了它们的可扩展性API,这将是高级应用程序感兴趣的。
下面是一组使用前面部分介绍的API基本部分的示例。
上述内容代表了电子邮件包的现代(Unicode友好)API。其余部分,从 Message
类,覆盖遗产 compat32
更直接地处理如何表示电子邮件的细节的API。这个 compat32
API做 not 从应用程序中隐藏RFC的详细信息,但对于需要在该级别操作的应用程序,它们可以是有用的工具。此文档也与仍在使用 compat32
出于向后兼容性的原因。
在 3.6 版更改: 重新组织和重写文档以促进新的 EmailMessage
/EmailPolicy
应用程序编程接口。
内容 email
封装文件:
遗留API: