email --- 電子郵件與 MIME 處理包?

源代碼: Lib/email/__init__.py

email 包是一個(gè)用于管理電子郵件消息的庫。 它 并非 被設計為執行向 SMTP (RFC 2821), NNTP 或其他服務(wù)器發(fā)送電子郵件消息的操作；這些是 smtplib 和 nntplib 等模塊的功能。 email 包試圖盡可能地遵循 RFC，支持 RFC 5322 和 RFC 6532，以及與 MIME 相關(guān)的各個(gè) RFC 例如 RFC 2045, RFC 2046, RFC 2047, RFC 2183 和 RFC 2231。

email 包的總體結構可以分為三個(gè)主要組件，另外還有第四個(gè)組件用于控制其他組件的行為。

這個(gè)包的中心組件是代表電子郵件消息的“對象模型”。 應用程序主要通過(guò)在 message 子模塊中定義的對象模型接口與這個(gè)包進(jìn)行交互。 應用程序可以使用此 API 來(lái)詢(xún)問(wèn)有關(guān)現有電子郵件的問(wèn)題、構造新的電子郵件，或者添加或移除自身也使用相同對象模型接口的電子郵件子組件。 也就是說(shuō)，遵循電子郵件消息及其 MIME 子組件的性質(zhì)，電子郵件對象模型是所有提供 EmailMessage API 的對象所構成的樹(shù)狀結構。

這個(gè)包的另外兩個(gè)主要組件是 parser 和 generator。 parser 接受電子郵件消息的序列化版本（字節流）并將其轉換為 EmailMessage 對象樹(shù)。 generator 接受 EmailMessage 并將其轉回序列化的字節流。 (parser 和 generator 還能處理文本字符流，但不建議這種用法，因為這很容易導致某種形式的無(wú)效消息。

控制組件是 policy 模塊。 每一個(gè) EmailMessage、每一個(gè) generator 和每一個(gè) parser 都有一個(gè)相關(guān)聯(lián)的 policy 對象來(lái)控制其行為。 通常應用程序只有在 EmailMessage 被創(chuàng )建時(shí)才需要指明控制策略，或者通過(guò)直接實(shí)例代 EmailMessage 來(lái)新建電子郵件，或者通過(guò)使用 parser 來(lái)解析輸入流。 但是策略也可以在使用 generator 序列化消息時(shí)被更改。 例如，這允許從磁盤(pán)解析通用電子郵件消息，而在將消息發(fā)送到電子郵件服務(wù)器時(shí)使用標準 SMTP 設置對其進(jìn)行序列化。

email 包會(huì )盡量地對應用程序隱藏各種控制類(lèi) RFC 的細節。 從概念上講應用程序應當能夠將電子郵件消息視為 Unicode 文本和二進(jìn)制附件的結構化樹(shù)，而不必擔心在序列化時(shí)要如何表示它們。 但在實(shí)際中，經(jīng)常有必要至少了解一部分控制類(lèi) MIME 消息及其結構的規劃，特別是 MIME "內容類(lèi)型" 的名稱(chēng)和性質(zhì)以及它們是如何標識多部分文檔的。 在大多數情況下這些知識應當僅對于更復雜的應用程序來(lái)說(shuō)才是必需的，并且即便在那時(shí)它也應當僅是特定的高層級結構，而不是如何表示這些結構的細節信息。 由于 MIME 內容類(lèi)型被廣泛應用于現代因特網(wǎng)軟件（而非只是電子郵件），因此這對許多程序員來(lái)說(shuō)將是很熟悉的概念。

以下小節描述了 email 包的具體功能。 我們會(huì )從 message 對象模型開(kāi)始，它是應用程序將要使用的主要接口，之后是 parser 和 generator 組件。 然后我們會(huì )介紹 policy 控制組件，它將完成對這個(gè)庫的主要組件的處理。

接下來(lái)的三個(gè)小節會(huì )介紹這個(gè)包可能引發(fā)的異常以及 parser 可能檢測到的缺陷（即與 RFC 不相符）。 然后我們會(huì )介紹 headerregistry 和 contentmanager 子組件，它們分別提供了用于更精細地操縱標題和載荷的工具。 這兩個(gè)組件除了包含使用與生成非簡(jiǎn)單消息的相關(guān)特性，還記錄了它們的可擴展性 API，這將是高級應用程序所感興趣的內容。

在此之后是一組使用之前小節所介紹的 API 的基本部分的示例。

前面的內容是 email 包的現代（對 Unicode 支持良好）API。 從 Message 類(lèi)開(kāi)始的其余小節則介紹了舊式 compat32 API，它會(huì )更直接地處理如何表示電子郵件消息的細節。 compat32 API 不會(huì ) 向應用程序隱藏 RFC 的相關(guān)細節，但對于需要進(jìn)行此種層級操作的應用程序來(lái)說(shuō)將是很有用的工具。 此文檔對于因向下兼容理由而仍然使用 compat32 API 的應用程序也是很適合的。

email 包文檔的內容:

舊式 API: