18.1. email —メールとMIME処理パッケージ—Pythonドキュメント

提供：Dev Guides
< PythonPython/docs/2.7/library/email
移動先:案内、検索

18.1。 Eメール —電子メールおよびMIME処理パッケージ

バージョン2.2の新機能。


email パッケージは、MIMEおよびその他の RFC 2822 ベースのメッセージドキュメントを含む電子メールメッセージを管理するためのライブラリです。 rfc822 、 mimetools 、 multifile などのいくつかの古い標準モジュール、およびmimecntlなどの他の非標準パッケージの機能のほとんどが含まれています。 ]。 具体的には、SMTP（ RFC 2821 ）、NNTP、またはその他のサーバーへの電子メールメッセージの送信を行うように設計されたではありません。 これらは、 smtplib や nntplib などのモジュールの機能です。 email パッケージは、 RFC 2822 に加えて、 などのMIME関連RFCをサポートし、可能な限りRFCに準拠しようとします。 RFC 2045 、 RFC 2046 、 RFC 2047 、および RFC 2231 。

email パッケージの主な特徴は、電子メールの内部オブジェクトモデル表現からの電子メールメッセージの解析と生成を分割することです。 email パッケージを使用するアプリケーションは、主にオブジェクトを処理します。 メッセージにサブオブジェクトを追加したり、メッセージからサブオブジェクトを削除したり、コンテンツを完全に再配置したりすることができます。 フラットテキストからオブジェクトモデルへの変換、そして再びフラットテキストへの変換を処理する別個のパーサーと別個のジェネレーターがあります。 また、いくつかの一般的なMIMEオブジェクトタイプの便利なサブクラスや、メッセージフィールド値の抽出と解析、RFC準拠の日付の作成などの一般的なタスクを支援するその他のユーティリティもいくつかあります。

次のセクションでは、 email パッケージの機能について説明します。 順序は、アプリケーションで一般的であるはずの進行に従います。電子メールメッセージは、ファイルまたは他のソースからフラットテキストとして読み取られ、テキストが解析されて電子メールメッセージのオブジェクト構造が生成され、この構造が操作され、最後に、オブジェクトツリーはフラットテキストにレンダリングされます。

布全体からオブジェクト構造を作成することは完全に実行可能です—つまり 完全にゼロから。 そこから、上記と同様の進行をとることができます。

また、 email パッケージが提供するすべてのクラスとモジュールの詳細な仕様、 email パッケージの使用中に発生する可能性のある例外クラス、いくつかの補助ユーティリティ、およびいくつかの例も含まれています。 古いmimelibパッケージ、または以前のバージョンの email パッケージのユーザー向けに、相違点と移植に関するセクションが用意されています。

email パッケージドキュメントの内容：


も参照してください

モジュール smtplib
SMTPプロトコルクライアント
モジュール nntplib
NNTPプロトコルクライアント


18.1.12。 パッケージ履歴

この表は、パッケージがリリースされたPythonのバージョンに対応する、電子メールパッケージのリリース履歴を示しています。 このドキュメントの目的上、変更または追加されたバージョンに関するメモが表示されている場合、これらは変更が行われたPythonバージョンを指し、電子メールパッケージバージョンはではありません。 この表は、パッケージの各バージョンのPython互換性についても説明しています。

メール版 で配布 と互換性があります
1.x Python2.2.0からPython2.2.1 サポートされなくなりました
2.5 Python2.2.2 +およびPython2.3 Python2.1から2.5
3.0 Python 2.4 Python2.3から2.5
4.0 Python 2.5 Python2.3から2.5

email バージョン4とバージョン3の主な違いは次のとおりです。

  • すべてのモジュールは、 PEP 8 標準に従って名前が変更されました。 たとえば、バージョン3のモジュールemail.Messageは、バージョン4で email.message に名前が変更されました。

  • 新しいサブパッケージ email.mime が追加され、すべてのバージョン3 email.MIME*モジュールの名前が変更され、 email.mime サブパッケージに配置されました。 たとえば、バージョン3モジュールemail.MIMETextはemail.mime.textに名前が変更されました。

    バージョン3の名前はPython2.6 まで引き続き機能することに注意してください。

  • MIMEApplication クラスを含むemail.mime.applicationモジュールが追加されました。

  • バージョン3で非推奨になったメソッドは削除されました。 これらには、Generator.__call__()、Message.get_type()、Message.get_main_type()、Message.get_subtype()が含まれます。

  • RFC 2231 サポートの修正が追加され、 Message.get_param およびその仲間の戻りタイプの一部が変更される可能性があります。 状況によっては、以前は3タプルを返していた値が単純な文字列を返すようになりました（具体的には、すべての拡張パラメーターセグメントがエンコードされていない場合、言語と文字セットの指定が予期されないため、戻り型は単純な文字列になります）。 また、%-d ecodingは、エンコードされたセグメントとエンコードされていないセグメントの両方に対して実行されていました。 このデコードは、エンコードされたセグメントに対してのみ実行されるようになりました。

email バージョン3とバージョン2の主な違いは次のとおりです。

  • FeedParser クラスが導入され、 Parser クラスが FeedParser の観点から実装されました。 したがって、すべての構文解析は厳密ではなく、構文解析は例外を発生させないように最善を尽くします。 メッセージの解析中に見つかった問題は、メッセージの欠陥属性に保存されます。
  • バージョン2でDeprecationWarningを発生させたAPIのすべての側面が削除されました。 これらには、 MIMEText コンストラクターへの _encoder 引数、Message.add_payload()メソッド、Utils.dump_address_pair()関数、および関数Utils.decode()とUtils.encode()。
  • 新しいDeprecationWarningがGenerator.__call__()、Message.get_type()、Message.get_main_type()、Message.get_subtype()、および strict に追加されました。 Parser クラスへの引数。 これらは、将来のバージョンで削除される予定です。
  • 2.3より前のPythonのサポートは削除されました。

email バージョン2とバージョン1の違いは次のとおりです。

  • email.Headerおよびemail.Charsetモジュールが追加されました。

  • メッセージインスタンスのピクルス形式が変更されました。 これは正式に定義されたことがない（そしてまだ定義されていない）ため、これは後方互換性とは見なされません。 ただし、アプリケーションが Message インスタンスをピクルスおよびアンピクルする場合、 email バージョン2では、 Message インスタンスにプライベート変数 _charset および _default_type 。

  • Message クラスのいくつかのメソッドが非推奨になったか、それらのシグネチャが変更されました。 また、多くの新しいメソッドが追加されました。 詳細については、 Message クラスのドキュメントを参照してください。 変更には完全な下位互換性が必要です。

  • message / rfc822 コンテンツタイプに直面して、オブジェクト構造が変更されました。 email バージョン1では、このようなタイプはスカラーペイロードで表されます。 コンテナメッセージの is_multipart（）はfalseを返し、 get_payload（）はリストオブジェクトではなく、単一の Message インスタンスでした。

    この構造はパッケージの他の部分と矛盾していたため、 message / rfc822 コンテンツタイプのオブジェクト表現が変更されました。 email バージョン2では、コンテナは is_multipart（）からTrueを返し、 get_payload（）は単一のメッセージアイテムを含むリスト。

    これは、下位互換性を完全に維持できなかった1つの場所であることに注意してください。 ただし、 get_payload（）の戻りタイプをすでにテストしている場合は、問題ないはずです。 コードが message / rfc822 のコンテンツタイプのコンテナで Message インスタンスを使用して set_payload（）を実行しないことを確認する必要があります。

  • Parser コンストラクターの strict 引数が追加され、その parse（）および parsestr（）メソッドが headersonly に成長しました。 ] 口論。 strict フラグも関数 email.message_from_file（）および email.message_from_string（）に追加されました。

  • Generator.__call__()は非推奨です。 代わりに Generator.flatten を使用してください。 Generator クラスは、 clone（）メソッドも拡張しました。

  • email.generator モジュールの DecodedGenerator クラスが追加されました。

  • 中間基本クラス MIMENonMultipart および MIMEMultipart が追加され、他のほとんどのMIME関連の派生クラスのクラス階層に挿入されました。

  • MIMEText コンストラクターの _encoder 引数は非推奨になりました。 エンコードは、 _charset 引数に基づいて暗黙的に行われるようになりました。

  • email.Utilsモジュールの次の関数は非推奨になりました：dump_address_pairs()、decode()、およびencode()。 モジュールには、make_msgid()、decode_rfc2231()、encode_rfc2231()、decode_params()の機能が追加されています。

  • 非公開機能email.Iterators._structure()を追加しました。


18.1.13。 との違いmimelib

email パッケージは、元々 mimelib と呼ばれる別のライブラリとしてプロトタイプ化されていました。 メソッド名の一貫性を高めるために変更が加えられ、一部のメソッドまたはモジュールが追加または削除されました。 一部のメソッドのセマンティクスも変更されました。 ほとんどの場合、mimelibで利用可能な機能は、多くの場合異なる方法ではありますが、 email パッケージでも引き続き利用できます。 mimelibパッケージと email パッケージ間の下位互換性は優先事項ではありませんでした。

ここでは、mimelibパッケージと email パッケージの違いについて簡単に説明し、アプリケーションを移植する方法のヒントを示します。

もちろん、2つのパッケージの最も明らかな違いは、パッケージ名が email に変更されていることです。 さらに、最上位パッケージには次の違いがあります。

Message クラスには次の違いがあります。

  • メソッドasString()は as_string（）に名前が変更されました。
  • メソッドismultipart()は is_multipart（）に名前が変更されました。
  • get_payload（）メソッドは、 decode オプションの引数を拡張しました。
  • メソッドgetall()は get_all（）に名前が変更されました。
  • メソッドaddheader()は add_header（）に名前が変更されました。
  • メソッドgettype()はget_type()に名前が変更されました。
  • メソッドgetmaintype()はget_main_type()に名前が変更されました。
  • メソッドgetsubtype()はget_subtype()に名前が変更されました。
  • メソッドgetparams()は get_params（）に名前が変更されました。 また、getparams()は文字列のリストを返しましたが、 get_params（）は、'='で分割された2タプルのリスト、事実上パラメーターのキー/値ペアを返します。 ] サイン。
  • メソッドgetparam()は get_param（）に名前が変更されました。
  • メソッドgetcharsets()は get_charsets（）に名前が変更されました。
  • メソッドgetfilename()は get_filename（）に名前が変更されました。
  • メソッドgetboundary()は get_boundary（）に名前が変更されました。
  • メソッドsetboundary()は set_boundary（）に名前が変更されました。
  • メソッドgetdecodedpayload()は削除されました。 同様の機能を取得するには、値1を get_payload（）メソッドの decode フラグに渡します。
  • メソッドgetpayloadastext()は削除されました。 同様の機能は、 email.generator モジュールの DecodedGenerator クラスでサポートされています。
  • メソッドgetbodyastext()は削除されました。 email.iterators モジュールで typed_subpart_iterator（）を使用してイテレーターを作成することにより、同様の機能を取得できます。

Parser クラスは、パブリックインターフェイスに違いはありません。 message / delivery-status タイプのメッセージを認識するための追加のスマート機能がいくつかあります。これは、のヘッダーブロックごとに個別の Message サブパーツを含む Message インスタンスとして表されます。配信ステータス通知 1 。

Generator クラスは、パブリックインターフェイスに違いはありません。 email.generator モジュールには、 DecodedGenerator と呼ばれる新しいクラスがあります。これは、Message.getpayloadastext()メソッドで以前に利用可能だった機能のほとんどを提供します。

次のモジュールとクラスが変更されました。

  • MIMEBase クラスコンストラクター引数 _major および _minor はそれぞれ _maintype および _subtype に変更されました。

  • Imageクラス/モジュールの名前がMIMEImageに変更されました。 _minor 引数の名前が _subtype に変更されました。

  • Textクラス/モジュールの名前がMIMETextに変更されました。 _minor 引数の名前が _subtype に変更されました。

  • MessageRFC822クラス/モジュールの名前がMIMEMessageに変更されました。 以前のバージョンのmimelibはこのクラス/モジュールRFC822を呼び出しましたが、大文字と小文字を区別しない一部のファイルシステムではPython標準ライブラリモジュール rfc822 と衝突しました。

    また、 MIMEMessage クラスは、メインタイプが message のあらゆる種類のMIMEメッセージを表すようになりました。 MIMEサブタイプを設定するために使用されるオプションの引数 _subtype を取ります。 _subtype のデフォルトは rfc822 です。

mimelibは、addressおよびdateモジュールでいくつかのユーティリティ機能を提供しました。 これらの機能はすべて email.utils モジュールに移動されました。

MsgReaderクラス/モジュールは削除されました。 その機能は、 email.iterators モジュールの body_line_iterator（）関数で最も厳密にサポートされています。

脚注

1
配信ステータス通知（DSN）は、 RFC 1894 で定義されています。



「https://www.finddevguides.com/index.php?title=Python/docs/2.7/library/email&oldid=97122」から取得
Powered by MediaWiki