email.headerregistry : 自定义头对象

源代码: Lib/email/headerregistry.py


Added in version 3.6: [ 1 ]

头表示是通过定制子类化 str 。用于表示给定 Header 头的特定类的确定是通过 header_factory policy 有效当创建头时。此节文档化特定 header_factory 实现通过 email 包为处理 RFC 5322 兼容 Email 消息,它不仅为各种头类型提供定制头对象,还为应用程序提供扩展机制以添加自己的自定义头类型。

当使用的任何策略对象派生自 EmailPolicy ,所有头的产生通过 HeaderRegistry 和拥有 BaseHeader 作为它们的最后基类。每个头类都拥有通过头类型确定的额外基类。例如,许多头拥有类 UnstructuredHeader 作为它们的其它基类。头的第 2 专用类由头名称确定,使用的查找表存储在 HeaderRegistry 。对于典型应用程序,所有这些是透明管理的,但提供用于修改默认行为的接口以供更复杂应用程序使用。

以下章节首先文档化头基类及其属性,紧接着是用于修改行为的 API 在 HeaderRegistry ,最后是支持类 (用于表示从结构化头剖析获得而来的数据)。

class email.headerregistry. BaseHeader ( 名称 , )

name and value 被传递给 BaseHeader header_factory 调用。任何头对象的字符串值都是 value 被完全解码成 Unicode。

此基类定义了下列只读特性:

名称

头的名称 (在 : 之前的字段部分)。此值被准确传入 header_factory 调用对于 name ;也就是说,保留大小写。

defects

元组 HeaderDefect 实例报告在剖析期间找到的任何 RFC 合规性问题。email 包试着完整检测合规性问题。见 errors 模块了解可能报告的缺陷类型的论述。

max_count

此类型的头的最大数量,可以拥有相同 name 。值为 None 意味着不受限制。 BaseHeader 值对于此属性为 None ;期望专用头类根据需要覆盖此值。

BaseHeader 还提供通过 email 库代码调用的如下方法,且一般不应被应用程序所调用:

fold ( * , policy )

返回字符串包含 linesep 字符按要求正确折叠头根据 policy cte_type of 8bit 将被视为 7bit ,由于头可能不包含任意二进制数据。若 utf8 is False ,非 ASCII 数据将是 RFC 2047 编码。

BaseHeader by itself cannot be used to create a header object. It defines a protocol that each specialized header cooperates with in order to produce the header object. Specifically, BaseHeader requires that the specialized class provide a classmethod() 命名 parse 。此方法的调用如下:

parse(string, kwds)