:解析电子邮件 – – 电子邮件和MIME处理包(Python教程)(参考资料)
email.parser
:解析电子邮件
消息对象结构可以通过以下两种方式之一创建:它们可以从整块布料中获取通过创建一个EmailMessage
对象,使用字典界面添加标题,使用set_content()
和相关方法添加有效负载,或者可以通过解析emailmessage的序列化表示来创建它
email
package提供了一个标准的解析器,可以理解大多数emaildocument结构,包括MIME文档。你可以传递解析器abytes,string或file对象,解析器将返回你的根EmailMessage
对象结构的实例。简单的非MIME消息,该根对象的有效负载可能是包含消息文本的astring。对于MIME消息,root对象将返回True
来自它is_multipart()
方法,子部分可以通过有效负载操作方法访问,如get_body()
,iter_parts()
,和walk()
.
实际上有两个可用的解析器接口,Parser
API和增量FeedParser
API。如果您在内存中包含消息的整个文本,或者如果整个消息存在于文件系统上的文件中,则Parser
API非常有用。当您从流中读取消息时,FeedParser
更合适,可能阻止等待更多输入(例如从套接字读取电子邮件消息)。FeedParser
可以递增地使用和解析消息,只有在关闭解析器时才会返回根对象.
注意解析器可以以有限的方式扩展,当然你可以实现自己的解析器完全从头开始。连接email
包的捆绑解析器和EmailMessage
类的所有逻辑都包含在policy
类中,因此自定义解析器可以以任何方式创建消息对象树。实现适当的自定义版本policy
methods.
FeedParser API
BytesFeedParser
,从email.feedparser
模块,提供有助于增量解析电子邮件消息的API,例如在从可以阻止的源(例如套接字)中读取电子邮件消息的文本时。BytesFeedParser
可以用于解析完全包含在字节对象,字符串或文件中的电子邮件消息,但BytesParser
API这种用例可能更方便。两个parserAPI的语义和结果是一样的.
BytesFeedParser
的API很简单;你创建一个实例,直到它不再需要它来提供它,然后关闭解析器来检索根消息对象。在解析符合标准的消息时,BytesFeedParser
非常准确,并且它在解析不符合要求的消息方面做得非常好,提供了有关消息被视为破坏的信息。它将使用消息中找到的任何问题列表填充消息对象的defects
属性。请参阅email.errors
模块以查找可以找到的缺陷列表.
这是BytesFeedParser
:
- class
email.parser.
BytesFeedParser
(_factory=None, *, policy=policy.compat32) -
创建一个
BytesFeedParser
实例。可选_factory是ano-argument可调用的;如果没有指定,请使用message_factory
中的policy。每当需要新的消息对象时调用_factory如果policy指定使用它指定的规则来更新消息的表示。如果没有设置policy,请使用
compat32
策略,它维护与电子邮件包的Python 3.2版本的向后兼容性,并提供Message
作为默认工厂。所有其他政策提供EmailMessage
默认为_factory。有关policy控件的更多信息,请参阅policy
documentation.注意:应始终指定policy关键字;默认将更改为
email.policy.default
在未来版本的Python中新版本3.2.
更改版本3.3:添加了policy keyword.
在版本3.6中更改:_factory默认为策略
message_factory
.feed
(data)-
为解析器提供更多数据。data应该是字节对象包含一行或多行。线可以是部分的,并且分析器将这些部分线正确地缝合在一起。线条可以有三个常见的线条结尾中的任何一个:回车,换行,或者换行和换行(它们甚至可以混合).
close
()-
完成所有先前输入数据的解析并返回rootmessage对象。如果在调用此方法之后调用
feed()
会发生什么事情是不确定的.
Parser API
BytesParser
类,从email.parser
模块,提供一个API,当消息的完整内容在字节对象或文件中可用时,可用于解析消息。email.parser
模块还提供了Parser
用于解析字符串和仅限标题的解析器BytesHeaderParser
和HeaderParser
,如果您只对消息的标题感兴趣,可以使用它。BytesHeaderParser
和HeaderParser
在这些情况下可以快得多,因为它们不会尝试解析主题体,而是将有效负载设置为原始体.
- class
email.parser.
BytesParser
(_class=None, *, policy=policy.compat32) -
创建一个
BytesParser
实例_class和policy参数与_factory的policy和BytesFeedParser
.参数具有相同的含义和语义注意:应始终指定policy关键字;默认将更改为
email.policy.default
在未来的Python版本中改版3.3:删除了strict在2.4中弃用的参数。添加了policy关键词。
版本3.6更改:_class默认为策略
message_factory
.parse
(fp, headersonly=False)-
从二进制文件类对象fp读取所有数据,解析结果字节,并返回消息宾语。fp必须支持
readline()
和read()
methods.fp中包含的字节必须格式化为 RFC 5322 的块(或者,如果
utf8
是True
, RFC 6532 )样式标题和标题延续行,可选地前面是anenvelope标题。标题块由数据末尾或空行终止。标题块之后是themessage的主体(可能包含MIME编码的子部分,包括带有Content-Transfer-Encoding对8bit
).可选的 headersonly是一个标志,指定是否在读取头文件后停止解析。默认是
False
,意思是它解析文件的全部内容.
parsebytes
(bytes, headersonly=False)-
类似于
parse()
方法,除了需要 bytes-likeobject 而不是类似文件的对象。在字节对象上调用此方法相当于在bytes中包装BytesIO
实例首先调用parse()
.可选headersonly和
parse()
方法一样
新版本3.2.
- class
email.parser.
BytesHeaderParser
(_class=None, *, policy=policy.compat32) -
正好
BytesParser
,除了headersonly默认为True
.版本3.3.
- class
email.parser.
Parser
(_class=None, *, policy=policy.compat32) -
这个类与
BytesParser
平行,但处理字符串输入。在版本3.3中更改:删除了strict参数。添加了policy keyword.
更改版本3.6:_class默认为策略
message_factory
.parse
(fp, headersonly=False)-
从文本模式文件对象fp读取所有数据,解析结果文本,并返回根消息对象。fp必须支持
readline()
和read()
文件类文件的方法.除文本模式要求外,此方法的操作类似于
BytesParser.parse()
.
parsestr
(text, headersonly=False)-
类似于
parse()
方法,除了它需要一个字符串对象而不是一个类文件对象。在字符串上调用此方法等同于在text实例中调用StringIO
调用parse()
.可选headersonly与
parse()
方法一样.
- class
email.parser.
HeaderParser
(_class=None, *, policy=policy.compat32) -
恰好
Parser
,除了headersonly默认为True
.
由于从字符串或文件对象创建消息对象结构是常见任务,因此提供了四个功能以方便起见。它们可以在顶层找到email
package namespace.
email.
message_from_bytes
(s, _class=None, *, policy=policy.compat32)-
从字节对象返回一个消息对象结构。这与
BytesParser().parsebytes(s)
等价。可选_class和policy被解释为BytesParser
classconstructor.新版本3.2.
更改版本3.3:删除了strict参数。添加了policy关键字
email.
message_from_binary_file
// (fp, _class=None, *, policy=policy.compat32 )-
从打开的二进制文件文件对象返回消息对象结构树。这相当于
BytesParser().parse(fp)
. _class和policy被解释为BytesParser
classconstructor.新版本3.2.
在版本3.3中更改:删除了strict参数。添加了policy keyword.
email.
message_from_string
(s, _class=None, *, policy=policy.compat32)-
从字符串返回消息对象结构。这相当于
Parser().parsestr(s)
. _class和policy被解释为Parser
类构造函数.更改版本3.3:删除了strict参数。添加了policy关键字
email.
message_from_file
// (fp, _class=None, *, policy=policy.compat32 )-
从打开文件对象这相当于
Parser().parse(fp)
. _class和policy和解释一样Parser
class constructor.改版3.3:删除了strict论点。添加了policy关键词。
版本3.6更改:_class默认为政策
message_factory
.
这是一个如何使用message_from_bytes()
在一个互动的Python提示符:
>>> import email>>> msg = email.message_from_bytes(myBytes)
附加说明
以下是解析语义的一些注释:
- 大多数非multipart类型的消息被解析为带有字符串有效负载的单个消息对象。对于
False
,这些对象将返回is_multipart()
,iter_parts()
会产生一个空列表 - 所有multipart类型消息将被解析为容器消息对象,其中包含有效负载的子消息对象列表。外容器消息将返回
True
is_multipart()
和iter_parts()
将产生一个子部分列表 - 内容类型为message/*的大多数消息(例如message/delivery-status和message/rfc822)也将被解析为容器对象包含列表有效负载长度为1.他们的
is_multipart()
方法将返回True
。iter_parts()
产生的单个元素将是一个子消息对象. - 一些不符合标准的消息可能在内部不一致multipart-edness。这样的消息可能有Content-Type类型的标题multipart,但他们的
is_multipart()
方法可能会返回False
。如果用解析这些消息FeedParser
,他们将有一个MultipartInvariantViolationDefect
在他们的课堂上defects属性列表。见email.errors
详情.