email.encoders: 編碼器?
此模塊是舊版 (Compat32) email API 的組成部分。 在新版 API 中將由 set_content() 方法的 cte 形參提供該功能。
此模塊在 Python 3 中已棄用。 這里提供的函數不應被顯式地調用，因為 MIMEText 類會在類實例化期間使用 _subtype 和 _charset 值來設置內容類型和 CTE 頭。
本段落中的剩余文本是該模塊的原始文檔。
當創建全新的 Message 對象時，你經常需要對載荷編碼以便通過兼容的郵件服務器進行傳輸。 對于包含二進制數據的 image/* 和 text/* 類型的消息來說尤其如此。
email 包在其 encoders 模塊中提供了一些方便的編碼。 這些編碼器實際上由 MIMEAudio 和 MIMEImage 類構造函數使用，以提供默認編碼。 所有編碼器函數只接受一個參數，即要編碼的消息對象。 它們通常提取有效數據，對其進行編碼，并將有效數據重置為此新編碼的值。 他們還應該根據需要設置 Content-Transfer-Encoding 標頭。
請注意，這些函數對于多段消息沒有意義。 它們必須應用到各個單獨的段上面，而不是整體。如果直接傳遞一個多段類型的消息，會產生一個 TypeError 錯誤。
下面是提供的編碼函數：
-
email.encoders.encode_quopri(msg)? 將有效數據編碼為quoted-printable形式，并將:mailheader:Content-Transfer-Encoding`標頭設置為``quoted-printable` 1. 。當大多數實際的數據是普通的可打印數據但包含少量不可打印的字符時，這是一個很好的編碼。
-
email.encoders.encode_base64(msg)? 將有效載荷編碼為 base64 形式，并將 Content-Transfer-Encoding 標頭設為
base64。 當你的載荷主要包含不可打印數據時這是一種很好用的編碼格式，因為它比 quoted-printable 更緊湊。 base64 編碼格式的缺點是它會使文本變成人類不可讀的形式。
-
email.encoders.encode_7or8bit(msg)? 這并不實際改變消息的有效載荷，但它會基于載荷數據將 Content-Transfer-Encoding 標頭相應地設為
7bit或8bit。
-
email.encoders.encode_noop(msg)? 這樣什么都不會做；它甚至不會設置 Content-Transfer-Encoding 標頭。
備注
- 1
請注意使用
encode_quopri()編碼格式還會對數據中的所有制表符和空格符進行編碼。