email.encoders:編碼器

原始碼:Lib/email/encoders.py


此模組是舊版 (Compat32) 電子郵件 API 的一部分。在新 API 中,此功能由 set_content() 方法的 cte 參數提供。

此模組在 Python 3 中已棄用。不應明確呼叫此處提供的函式,因為 MIMEText 類別使用在該類別的實例化過程中傳遞的 _subtype_charset 值來設定內容類型 (content type) 和 CTE 標頭。

本節中的其餘文字是該模組的原始文件。

從零開始建立 Message 物件時,你通常需要對負載 (payload) 進行編碼,以便透過相容的郵件伺服器進行傳輸。對於包含二進位資料的 image/*text/* 類型的訊息尤其如此。

email 套件在其 encoders 模組中提供了一些方便的編碼器。這些編碼器實際上由 MIMEAudioMIMEImage 類別建構函式使用來提供預設編碼。所有編碼器函式都只接受一個引數,也就是要編碼的訊息物件。他們通常會提取負載、對其進行編碼,然後將負載重設為新編碼的值。他們也應適當地設定 Content-Transfer-Encoding 標頭。

請注意,這些函式對於多部分訊息 (multipart message) 沒有意義。它們必須應用於各個子部分,如果傳遞類型為多部分訊息,則會引發 TypeError

以下是提供的編碼函式:

email.encoders.encode_quopri(msg)

將負載編碼為可列印字元 (quoted-printable) 形式,並將 Content-Transfer-Encoding 標頭設定為 quoted-printable [1]。當大部分負載是正常的可列印資料,但包含一些不可列印的字元時,這是一種很好的編碼。

email.encoders.encode_base64(msg)

將負載編碼為 base64 形式,並將 Content-Transfer-Encoding 標頭設定為 base64。當大部分負載是不可列印資料時,這是一種很好的編碼,因為它是比可列印字元更緊湊的形式。Base64 編碼的缺點是它使文字無法讓人類可讀。

email.encoders.encode_7or8bit(msg)

這實際上並沒有修改訊息的負載,但它確實根據負載資料將 Content-Transfer-Encoding 標頭設定為適當的 7bit8bit

email.encoders.encode_noop(msg)

這沒有任何作用;它甚至沒有設定 Content-Transfer-Encoding 標頭。

註腳