18.1. 电子邮件-电子邮件和 MIME 处理包

2.2 版中的新Function。

email软件包是用于 Management 电子邮件的库,包括 MIME 和其他基于 RFC 2822的邮件文档。它将大多数Function包含在几个较旧的标准模块(例如rfc822mimetoolsmultifile)和其他非标准软件包(例如mimecntl)中。它不是专门设计用于将电子邮件发送到 SMTP( RFC 2821),NNTP 或其他服务器的;这些是smtplibnntplib等模块的Function。 email包try尽可能地符合 RFC,除了 RFC 2822以外,还支持诸如 RFC 2045 RFC 2046 RFC 2047 RFC 2231之类的与 MIME 相关的 RFC。

email程序包的主要区别在于,它从电子邮件的内部“对象模型”表示形式中分离了电子邮件的解析和生成。使用email软件包的应用程序主要处理对象。您可以向消息中添加子对象,从消息中删除子对象,完全重新排列内容,等等。这里有一个单独的解析器和一个单独的生成器,用于处理从纯文本到对象模型的转换,然后返回到再次显示纯 Literals。还有一些常见的 MIME 对象类型的便捷子类,以及一些杂项 Util,可帮助完成诸如提取和解析消息字段值,创建符合 RFC 的日期等常见任务。

以下各节介绍了email软件包的Function。排序遵循在应用程序中应该常见的进度:从文件或其他来源将电子邮件作为纯文本读取,将文本解析为电子邮件的对象结构,对该结构进行操作,最后,对象树被渲染回平面文本。

用整块布料(即完全从头开始)创建对象结构是完全可行的。从那里,可以采取与上述类似的进展。

还包括email软件包提供的所有类和模块的详细规范,使用email软件包时可能遇到的异常类,一些辅助 Util 以及一些示例。对于较旧的mimelib软件包或较早版本的email软件包的用户,提供了有关差异和移植的部分。

email软件包文档的内容:

See also

  • Module smtplib

  • SMTP 协议 Client 端

  • Module nntplib

  • NNTP 协议 Client 端

18.1.12. 包装历史

下表描述了电子邮件软件包的发行历史记录,与该软件包所发行的 Python 版本相对应。就本文档而言,当您看到有关更改或添加的版本的 Comments 时,它们指的是进行更改的 Python 版本,不是电子邮件软件包的版本。该表还描述了该软件包每个版本的 Python 兼容性。

email versiondistributed withcompatible with
1.xPython 2.2.0 至 Python 2.2.1不再受支持
2.5Python 2.2.2 和 Python 2.3Python 2.1 至 2.5
3.0Python 2.4Python 2.3 至 2.5
4.0Python 2.5Python 2.3 至 2.5

以下是email版本 4 和版本 3 之间的主要区别:

  • 所有模块均已根据 PEP 8标准重命名。例如,版本 3 模块email.Message在版本 4 中重命名为email.message

  • 添加了一个新的子程序包email.mime,所有版本 3 email.MIME*模块都被重命名并位于email.mime子程序包中。例如,版本 3 模块email.MIMEText重命名为email.mime.text

*请注意,版本 3 名称将 continue 使用,直到 Python 2.6 *为止。

  • 添加了email.mime.application模块,其中包含MIMEApplication类。

  • 版本 3 中不推荐使用的方法已被删除。这些包括Generator.__call__()Message.get_type()Message.get_main_type()Message.get_subtype()

  • 已为 RFC 2231支持添加了修复程序,这些修复程序可以更改Message.get_param和朋友的某些返回类型。在某些情况下,用于返回三 Tuples 的值现在将返回简单字符串(特别是,如果所有扩展参数段都未编码,则不需要指定语言和字符集,因此返回类型现在为简单字符串)。而且,过去曾经对编码段和未编码段都执行%-decoding。现在仅对编码的段执行此解码。

以下是email版本 3 和版本 2 之间的主要区别:

  • 引入了FeedParser类,并根据FeedParser实现了Parser类。因此,所有解析都是非严格的,并且解析将尽最大努力永远不会引发异常。解析消息时发现的问题存储在消息的* defect *属性中。

  • 已删除版本 2 中引发DeprecationWarning的 API 的所有方面。这些包括MIMEText构造函数的* _encoder *参数,Message.add_payload()方法,Utils.dump_address_pair()函数以及函数Utils.decode()Utils.encode()

  • 新的DeprecationWarning已添加到:Generator.__call__()Message.get_type()Message.get_main_type()Message.get_subtype()Parser类的* strict *参数。这些有望在将来的版本中删除。

  • 删除了对 2.3 之前的 Python 的支持。

以下是email版本 2 和版本 1 之间的区别:

  • email.Headeremail.Charset模块已添加。

  • Message个实例的 pickle 格式已更改。由于从来没有(现在仍然没有)对此进行正式定义,因此这不被视为向后不兼容。但是,如果您的应用程序腌制并释放了Message个实例,请注意,在email版本 2 中,Message实例现在具有私有变量* _charset _default_type *。

  • Message类中的几种方法已被弃用,或它们的签名已更改。此外,还添加了许多新方法。有关详细信息,请参见Message类的文档。所做的更改应完全向后兼容。

  • 面对* message/rfc822 *Content Type,对象结构已更改。在email版本 1 中,此类类型将由标量有效负载表示,即容器消息的is_multipart()返回 false,get_payload()不是列表对象,而是单个Message实例。

此结构与包的其余部分不一致,因此* message/rfc822 Content Type 的对象表示已更改。在email版本 2 中,容器确实*从is_multipart()返回True,而get_payload()返回包含单个Message项的列表。

请注意,这是无法完全保持向后兼容性的地方。但是,如果您已经在测试get_payload()的返回类型,就可以了。您只需要确保您的代码不会在 Content Type 为* message/rfc822 *的容器上对Message实例执行set_payload()

  • 添加了Parser构造函数的* strict 参数,并且其parse()parsestr()方法增加了 headersonly *参数。 * strict *标志也已添加到函数email.message_from_file()email.message_from_string()

  • Generator.__call__()已弃用;请改用Generator.flattenGenerator类还增加了clone()方法。

  • email.generator模块中添加了DecodedGenerator类。

  • 中间 Base ClassMIMENonMultipartMIMEMultipart已添加,并插入到大多数其他与 MIME 相关的其他派生类的类层次结构中。

  • MIMEText构造函数的* _encoder 参数已被弃用。现在,基于 _charset *参数隐式地进行编码。

  • email.Utils模块中的以下Function已被弃用:dump_address_pairs()decode()encode()。以下Function已添加到模块中:make_msgid()decode_rfc2231()encode_rfc2231()decode_params()

  • 加入了非公开Functionemail.Iterators._structure()

18.1.13. 与 mimelib 的差异

email软件包最初是作为单独的库mimelib原型化的。进行了更改,以使方法名称更加一致,并且已添加或删除了某些方法或模块。一些方法的语义也已更改。在大多数情况下,mimelib中可用的任何Function在email包中仍然可用,尽管通常以不同的方式。 mimelib软件包和email软件包之间的向后兼容性不是优先事项。

这是mimelibemail软件包之间差异的简要说明,以及有关如何移植应用程序的提示。

当然,两个软件包之间最明显的区别是软件包名称已更改为email。此外,顶级软件包还具有以下差异:

Message类具有以下区别:

  • 方法asString()重命名为as_string()

  • 方法ismultipart()重命名为is_multipart()

  • get_payload()方法增加了* decode *可选参数。

  • 方法getall()重命名为get_all()

  • 方法addheader()重命名为add_header()

  • 方法gettype()重命名为get_type()

  • 方法getmaintype()重命名为get_main_type()

  • 方法getsubtype()重命名为get_subtype()

  • 方法getparams()重命名为get_params()。同样,尽管getparams()返回一个字符串列表,而get_params()返回一个 2Tuples 列表,有效地是参数的键/值对,在'='符号上分割。

  • 方法getparam()重命名为get_param()

  • 方法getcharsets()重命名为get_charsets()

  • 方法getfilename()重命名为get_filename()

  • 方法getboundary()重命名为get_boundary()

  • 方法setboundary()重命名为set_boundary()

  • 方法getdecodedpayload()已删除。要获得类似的Function,请将值 1 传递给get_payload()方法的* decode *标志。

  • 方法getpayloadastext()已删除。 email.generator模块中的DecodedGenerator类支持类似的Function。

  • 方法getbodyastext()已删除。您可以pass在email.iterators模块中使用typed_subpart_iterator()创建一个迭代器来获得类似的Function。

Parser类的公共界面没有区别。它确实具有一些其他智能,可以识别* message/delivery-status *类型的消息,它表示为Message实例,其中包含交货状态通知[1]中每个 Headers 块的单独的Message子部分。

Generator类的公共界面没有区别。不过,email.generator模块中有一个名为DecodedGenerator的新类,它提供了Message.getpayloadastext()方法中以前可用的大多数Function。

以下模块和类已更改:

  • MIMEBase类的构造函数参数* _major _minor 分别更改为 _maintype _subtype *。

  • Image类/模块已重命名为MIMEImage。 * _minor 参数已重命名为 _subtype *。

  • Text类/模块已重命名为MIMEText。 * _minor 参数已重命名为 _subtype *。

  • MessageRFC822类/模块已重命名为MIMEMessage。请注意,mimelib的早期版本称为此类/模块RFC822,但在某些不区分大小写的文件系统上,它与 Python 标准库模块rfc822发生冲突。

另外,MIMEMessage类现在表示任何类型的 MIME 邮件,其主类型为* message 。它带有一个可选参数 _subtype *,用于设置 MIME 子类型。 * _subtype 默认为 rfc822 *。

mimelib在其addressdate模块中提供了一些 Util Function。所有这些Function已移至email.utils模块。

MsgReader类/模块已被删除。 email.iterators模块中的body_line_iterator()Function最紧密地支持其Function。

Footnotes