email — 電子郵件和 MIME 處理包

原始碼: Lib/email/__init__.py

email 包是一個用於管理電子郵件訊息的庫。它專門不設計用於向 SMTP (RFC 2821)，NNTP 或其他伺服器傳送電子郵件訊息；這些是諸如 smtplib 等模組的功能。email 包嘗試儘可能符合 RFC 標準，支援 RFC 5322 和 RFC 6532，以及諸如 RFC 2045，RFC 2046，RFC 2047，RFC 2183 和 RFC 2231 等 MIME 相關 RFC。

電子郵件包的總體結構可以分為三個主要元件，加上一個控制其他元件行為的第四個元件。

該軟體包的核心元件是表示電子郵件訊息的“物件模型”。應用程式主要透過 message 子模組中定義的物件模型介面與該軟體包進行互動。應用程式可以使用此 API 來詢問有關現有電子郵件的問題，構造新的電子郵件，或者新增或刪除本身使用相同物件模型介面的電子郵件子元件。也就是說，遵循電子郵件訊息及其 MIME 子元件的性質，電子郵件物件模型是一個物件樹結構，它們都提供 EmailMessage API。

該軟體包的另外兩個主要元件是 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 可能檢測到的缺陷（不符合 RFC）。然後，我們介紹了 headerregistry 和 contentmanager 子元件，它們提供了用於更詳細地操作標題和有效負載的工具。這兩個元件都包含與使用和生成非平凡訊息相關的功能，但也記錄了它們的可擴充套件性 API，這將是高階應用程式感興趣的。

接下來是一系列使用前面部分中介紹的 API 基本部分的示例。

以上代表了電子郵件包的現代（unicode 友好）API。其餘部分，從 Message 類開始，介紹了與電子郵件訊息的表示方式的細節直接相關的舊式 compat32 API。 compat32 API 不嚮應用程式隱藏 RFC 的詳細資訊，但是對於需要在該級別上執行的應用程式，它們可能是有用的工具。對於出於向後相容性原因仍在使用 compat32 API 的應用程式，本文件也適用。

在 3.6 版本中更改：文件進行了重組和重寫，以推廣新的 EmailMessage/EmailPolicy API。

email 包文件的內容

傳統 API

另請參閱

模組 smtplib

SMTP（簡單郵件傳輸協議）客戶端

模組 poplib

POP（郵局協議）客戶端

模組 imaplib

IMAP（Internet 訊息訪問協議）客戶端

模組 mailbox

用於使用各種標準格式在磁碟上建立、讀取和管理訊息集合的工具。