email.parser: Parsing email messages
消息对象结构可以通过以下两种方式之一来创建：它们可以通过实例化Message对象并通过attach()和set_payload()调用将它们串在一起来创建，也可以通过解析电子邮件的平面文本表示来创建。
该email软件包提供了一个可理解大多数电子邮件文档结构（包括MIME文档）的标准分析器。您可以将解析器传递给字符串或文件对象，解析器将返回Message对象结构的根实例。对于简单的非MIME消息，这个根对象的负载可能是一个包含消息文本的字符串。对于MIME消息，根对象True将从其is_multipart()方法返回，并且可以通过get_payload()和walk()方法访问子部分。
实际上有两个解析器接口可供使用，即经典ParserAPI和增量FeedParserAPI。Parser如果将内存中的消息的整个文本作为字符串存在，或者整个消息存在于文件系统中的文件中，那么传统的API是很好的。FeedParser当你从一个可能阻塞等待更多输入的流中读取消息（例如从套接字读取电子邮件消息）时，它更适合。的FeedParser可消耗和递增地解析该消息，并且只有当关闭解析器返回根对象[1]。
请注意，解析器可以以有限的方式进行扩展，当然，您可以从头开始完全实现自己的解析器。email包的捆绑解析器和Message类之间没有魔法连接，所以你的自定义解析器可以以任何需要的方式创建消息对象树。
1. FeedParser API
2.4版本中的新功能。
的FeedParser，从导入的email.feedparser模块，提供了一个API有利于电子邮件消息，如增量分析从可阻断源（例如一插座）阅读电子邮件消息的文本时是必要的。该FeedParser课程可以用来解析完全包含在一个字符串或文件的电子邮件，但经典的ParserAPI可以是用于这种用途的情况下更方便。两个解析器API的语义和结果是相同的。
这个FeedParserAPI很简单，你创建一个实例，为它提供一堆文本，直到没有更多的文本为止，然后关闭解析器以检索根消息对象。这FeedParser在解析符合标准的消息时非常准确，并且在解析不符合规定的消息方面做得非常好，提供了有关消息如何被破坏的信息。它将填充消息对象的缺陷属性以及它在消息中发现的任何问题的列表。查看email.errors模块以获取它可找到的缺陷列表。
以下是以下API的API FeedParser：
class email.parser.FeedParser([_factory])
创建一个FeedParser实例。可选_factory是一个无参数的可调用对象，只要需要一个新的消息对象就会被调用。它默认为email.message.Message该类。
feed(data)
提供FeedParser更多的数据。数据应该是包含一行或多行的字符串。这些线可以是局部的，并且FeedParser会将这些局部线合适地拼接在一起。字符串中的行可以包含任何常见的三行结尾，回车符，换行符，回车符和换行符（它们甚至可以混合使用）。
close()
关闭FeedParser完成所有先前馈送的数据的解析，并返回根消息对象。这是不明确的，如果你提供更多的数据到一个封闭的FeedParser。
2. Parser class API
Parser从email.parser模块导入的类提供了一个API，当信息的完整内容在字符串或文件中可用时，该API可用于解析消息。该email.parser模块还提供了第二个类，HeaderParser如果您只对邮件的标题感兴趣，则可以使用该类。HeaderParser在这些情况下可以更快，因为它不会尝试解析消息体，而是将有效负载设置为原始主体作为字符串。HeaderParser与Parser该类具有相同的API 。
class email.parser.Parser([_class])
Parser该类的构造函数接受一个可选参数_class。这必须是可调用的工厂（例如函数或类），并且每当需要创建子消息对象时都会使用它。它默认为Message（见email.message）。工厂将被调用，而无需争论。
可选的严格标志被忽略。
自2.4版以来不推荐使用：因为Parser该类是Python-in-2.4中向后兼容的API包装FeedParser，因此所有解析都是非严格的。你应该停止传递一个严格的标志给Parser构造函数。
在版本2.2.2中更改：添加了严格标志。
在版本2.4中更改：严格标志已被弃用。
其他公共Parser方法是：
parse(fp[, headersonly])
读取类文件对象fp中的所有数据，解析生成的文本，并返回根消息对象。fp必须同时支持文件类对象readline()和read()方法。
包含在fp中的文本必须格式化为RFC 2822样式标题和标题延续行的一个块，可选地以信封标题开头。标题块由数据结尾或空行结束。标题块之后是消息的正文（可能包含MIME编码的子部分）。
可选的headersonly是一个标志，指定是否在阅读头文件后停止解析。默认值是False，表示它解析文件的全部内容。
在版本2.2.2中更改：添加了headersonly标志。
parsestr(text[, headersonly])
与该parse()方法类似，除了它需要一个字符串对象而不是类似文件的对象。调用一个字符串这种方法是完全等同于环绕文本的StringIO第一个实例，并调用parse()。
可选的headeronly与parse()方法一样。
在版本2.2.2中更改：添加了headersonly标志。
由于从字符串或文件对象创建消息对象结构是一项常见任务，因此提供了两个函数作为方便。它们在顶层email包名称空间中可用。
email.message_from_string(s[, _class[, strict]])
从字符串中返回一个消息对象结构。这完全等同于Parser().parsestr(s)。可选的_class和strict与Parser类构造函数一样被解释。
在版本2.2.2中更改：添加了严格标志。
email.message_from_file(fp[, _class[, strict]])
从打开的文件对象中返回消息对象结构树。这完全等同于Parser().parse(fp)。可选的_class和strict与Parser类构造函数一样被解释。
在版本2.2.2中更改：添加了严格标志。
下面是一个如何在交互式Python提示符下使用它的例子：
>>> import email
>>> msg = email.message_from_string(myString)3.其他说明
以下是关于解析语义的一些注释：
- 大多数非多部分类型的消息被解析为具有字符串有效载荷的单个消息对象。这些对象将返回
False了is_multipart()。他们的get_payload()方法将返回一个字符串对象。
- 所有多部分类型的消息都将被解析为一个容器消息对象，其中包含有关其负载的子消息对象列表。外容器消息将返回
True了is_multipart()和他们的get_payload()方法将返回列表Message子部分。
- 大多数内容类型为message / *的消息（例如message / delivery-status和message / rfc822）也将被解析为包含长度为1的列表载荷的容器对象。他们的
is_multipart()方法将返回True。列表有效载荷中的单个元素将是一个子消息对象。
- 一些非符合标准的消息可能不会对他们的内部一致的多 -edness。这样的消息可能有一个类型为multipart的Content-Type头，但是它们的
is_multipart()方法可能会返回False。如果这些消息被解析FeedParser，他们将MultipartInvariantViolationDefect在其缺陷属性列表中包含该类的一个实例。详情请参阅email.errors。
注
1 | 从Python 2.4中引入的电子邮件包版本3.0开始，经典的解析器根据FeedParser重新实现，因此两个解析器之间的语义和结果是相同的。 |
|---|
本文档系腾讯云开发者社区成员共同维护，如有问题请联系 cloudcommunity@tencent.com
