email.parser ：電子メールメッセージの解析
ソースコード： ：source： `Lib / email / parser.py`
メッセージオブジェクト構造は、 EmailMessage オブジェクトを作成し、辞書インターフェイスを使用してヘッダーを追加し、 set_content（）を使用してペイロードを追加することにより、布全体から作成できます。 ）および関連するメソッド、または電子メールメッセージのシリアル化された表現を解析することによって作成できます。
email パッケージは、MIMEドキュメントを含むほとんどのメールドキュメント構造を理解する標準パーサーを提供します。 パーサーにバイト、文字列、またはファイルオブジェクトを渡すと、パーサーはオブジェクト構造のルート EmailMessage インスタンスを返します。 単純な非MIMEメッセージの場合、このルートオブジェクトのペイロードは、メッセージのテキストを含む文字列になる可能性があります。 MIMEメッセージの場合、ルートオブジェクトは is_multipart（）メソッドからTrueを返し、サブパーツには get_body（）[X191Xなどのペイロード操作メソッドを介してアクセスできます。 ]、 iter_parts（）、および walk（）。
実際には、 Parser APIとインクリメンタル FeedParser APIの2つのパーサーインターフェイスを使用できます。 Parser APIは、メッセージのテキスト全体がメモリにある場合、またはメッセージ全体がファイルシステム上のファイルに存在する場合に最も役立ちます。 FeedParser は、ストリームからメッセージを読み取る場合に適しています。これにより、入力の待機がブロックされる可能性があります（ソケットからの電子メールメッセージの読み取りなど）。 FeedParser は、メッセージを段階的に消費および解析でき、パーサーを閉じたときにのみルートオブジェクトを返します。
パーサーは限られた方法で拡張できることに注意してください。もちろん、独自のパーサーを最初から完全に実装することもできます。 email パッケージのバンドルパーサーと EmailMessage クラスを接続するすべてのロジックは、policyクラスに組み込まれているため、カスタムパーサーは任意の方法でメッセージオブジェクトツリーを作成できます。適切なpolicyメソッドのカスタムバージョンを実装することにより、必要であることがわかります。
FeedParser API
email.feedparserモジュールからインポートされた BytesFeedParser は、ソースから電子メールメッセージのテキストを読み取るときに必要になるなど、電子メールメッセージの増分解析に役立つAPIを提供します。ブロックできます（ソケットなど）。 BytesFeedParser はもちろん、 bytesのようなオブジェクト、文字列、またはファイルに完全に含まれる電子メールメッセージを解析するために使用できますが、 BytesParser APIはこのようなユースケースにはより便利です。 2つのパーサーAPIのセマンティクスと結果は同じです。
BytesFeedParser のAPIはシンプルです。 インスタンスを作成し、それをフィードする必要がなくなるまでバイトの束をフィードしてから、パーサーを閉じてルートメッセージオブジェクトを取得します。 BytesFeedParser は、標準に準拠したメッセージを解析するときに非常に正確であり、非準拠のメッセージを解析するのに非常に優れており、メッセージがどのように壊れていると見なされたかに関する情報を提供します。 メッセージオブジェクトの defects 属性に、メッセージで見つかった問題のリストが入力されます。 検出できる欠陥のリストについては、 email.errors モジュールを参照してください。
BytesFeedParser のAPIは次のとおりです。
- class email.parser.BytesFeedParser(_factory=None, *, policy=policy.compat32)
BytesFeedParser インスタンスを作成します。 オプションの _factory は、引数なしで呼び出すことができます。 指定されていない場合は、ポリシーの message_factory を使用してください。 新しいメッセージオブジェクトが必要なときはいつでも _factory を呼び出します。
policy が指定されている場合は、指定されているルールを使用してメッセージの表現を更新します。 policy が設定されていない場合は、 compat32 ポリシーを使用します。これにより、Python 3.2バージョンの電子メールパッケージとの下位互換性が維持され、メッセージがデフォルトのファクトリとして提供されます。 他のすべてのポリシーは、デフォルトの _factory として EmailMessage を提供します。 policy が制御する他の機能の詳細については、 policy のドキュメントを参照してください。
注： policyキーワードは常に指定する必要があります; Pythonの将来のバージョンでは、デフォルトが email.policy.default に変更されます。
バージョン3.2の新機能。
バージョン3.3で変更： policy キーワードが追加されました。
バージョン3.6で変更： _factory のデフォルトはポリシー
message_factoryです。- feed(data)
パーサーにさらにデータをフィードします。 data は、1つ以上の行を含むバイトのようなオブジェクトである必要があります。 線は部分的である可能性があり、パーサーはそのような部分的な線を適切につなぎ合わせます。 行には、キャリッジリターン、改行、またはキャリッジリターンと改行の3つの一般的な行末のいずれかを含めることができます（混合することもできます）。
- close()
以前にフィードされたすべてのデータの解析を完了し、ルートメッセージオブジェクトを返します。 このメソッドが呼び出された後に feed（）が呼び出された場合、どうなるかは未定義です。
- class email.parser.FeedParser(_factory=None, *, policy=policy.compat32)
BytesFeedParser と同様に機能しますが、 feed（）メソッドへの入力は文字列である必要があります。 このようなメッセージを有効にする唯一の方法は、ASCIIテキストのみを含めるか、
utf8がTrueの場合、バイナリ添付ファイルを含まないことであるため、これは限られた有用性です。バージョン3.3で変更： policy キーワードが追加されました。
パーサーAPI
email.parser モジュールからインポートされた BytesParser クラスは、メッセージの完全な内容がバイトで利用可能な場合にメッセージを解析するために使用できるAPIを提供します-オブジェクトまたはファイルのように。 email.parser モジュールは、文字列を解析するための Parser と、ヘッダーのみのパーサー BytesHeaderParser および HeaderParser も提供します。メッセージのヘッダーのみに関心がある場合。 BytesHeaderParser および HeaderParser は、メッセージ本文の解析を試みず、代わりにペイロードを未加工の本文に設定するため、これらの状況でははるかに高速になります。
- class email.parser.BytesParser(_class=None, *, policy=policy.compat32)
BytesParser インスタンスを作成します。 _class および policy 引数は、 BytesFeedParser の _factory および policy 引数と同じ意味およびセマンティクスを持ちます。
注： policyキーワードは常に指定する必要があります; Pythonの将来のバージョンでは、デフォルトが email.policy.default に変更されます。
バージョン3.3で変更： 2.4で非推奨になった strict 引数を削除しました。 policy キーワードを追加しました。
バージョン3.6で変更： _class のデフォルトはポリシー
message_factoryです。- parse(fp, headersonly=False)
バイナリファイルのようなオブジェクト fp からすべてのデータを読み取り、結果のバイトを解析して、メッセージオブジェクトを返します。 fp は、 readline（）メソッドと
read()メソッドの両方をサポートする必要があります。fp に含まれるバイトは、 RFC 5322 のブロックとしてフォーマットする必要があります（または、
utf8がTrueの場合、 RFC 6532 ）スタイルのヘッダーとヘッダー継続行。オプションでエンベロープヘッダーが前に付きます。 ヘッダーブロックは、データの終わりまたは空白行のいずれかで終了します。 ヘッダーブロックの後には、メッセージの本文が続きます（[X120X] の Content-Transfer-Encoding を持つサブパーツを含むMIMEエンコードされたサブパーツが含まれる場合があります）。オプションの headersonly は、ヘッダーの読み取り後に解析を停止するかどうかを指定するフラグです。 デフォルトは
Falseで、ファイルの内容全体を解析することを意味します。
- parsebytes(bytes, headersonly=False)
parse（）メソッドに似ていますが、ファイルのようなオブジェクトではなく、バイトのようなオブジェクトを使用する点が異なります。 bytes-like object でこのメソッドを呼び出すことは、 bytes を最初に BytesIO インスタンスでラップし、 parse（）を呼び出すことと同じです。
オプションの headersonly は、 parse（）メソッドと同じです。
バージョン3.2の新機能。
- class email.parser.BytesHeaderParser(_class=None, *, policy=policy.compat32)
headersonly のデフォルトが
Trueであることを除いて、 BytesParser とまったく同じです。バージョン3.3の新機能。
- class email.parser.Parser(_class=None, *, policy=policy.compat32)
このクラスは BytesParser と並列ですが、文字列入力を処理します。
バージョン3.3で変更： strict 引数を削除しました。 policy キーワードを追加しました。
バージョン3.6で変更： _class のデフォルトはポリシー
message_factoryです。- parse(fp, headersonly=False)
テキストモードのファイルのようなオブジェクト fp からすべてのデータを読み取り、結果のテキストを解析して、ルートメッセージオブジェクトを返します。 fp は、ファイルのようなオブジェクトで readline（）メソッドと read（）メソッドの両方をサポートする必要があります。
テキストモードの要件を除けば、このメソッドは BytesParser.parse（）のように動作します。
- class email.parser.HeaderParser(_class=None, *, policy=policy.compat32)
- パーサーとまったく同じですが、 headersonly のデフォルトが
Trueである点が異なります。
文字列またはファイルオブジェクトからメッセージオブジェクト構造を作成することは非常に一般的なタスクであるため、便宜上4つの関数が用意されています。 これらは、トップレベルの email パッケージ名前空間で利用できます。
- email.message_from_bytes(s, _class=None, *, policy=policy.compat32)
バイトのようなオブジェクトからメッセージオブジェクト構造を返します。 これは
BytesParser().parsebytes(s)と同等です。 オプションの _class および policy は、 BytesParser クラスコンストラクターと同様に解釈されます。バージョン3.2の新機能。
バージョン3.3で変更： strict 引数を削除しました。 policy キーワードを追加しました。
- email.message_from_binary_file(fp, _class=None, *, policy=policy.compat32)
開いているバイナリファイルオブジェクトからメッセージオブジェクト構造ツリーを返します。 これは
BytesParser().parse(fp)と同等です。 _class および policy は、 BytesParser クラスコンストラクターと同様に解釈されます。バージョン3.2の新機能。
バージョン3.3で変更： strict 引数を削除しました。 policy キーワードを追加しました。
- email.message_from_string(s, _class=None, *, policy=policy.compat32)
文字列からメッセージオブジェクト構造を返します。 これは
Parser().parsestr(s)と同等です。 _class および policy は、 Parser クラスコンストラクターと同様に解釈されます。バージョン3.3で変更： strict 引数を削除しました。 policy キーワードを追加しました。
- email.message_from_file(fp, _class=None, *, policy=policy.compat32)
開いているファイルオブジェクトからメッセージオブジェクト構造ツリーを返します。 これは
Parser().parse(fp)と同等です。 _class および policy は、 Parser クラスコンストラクターと同様に解釈されます。バージョン3.3で変更： strict 引数を削除しました。 policy キーワードを追加しました。
バージョン3.6で変更： _class のデフォルトはポリシー
message_factoryです。
インタラクティブなPythonプロンプトで message_from_bytes（）を使用する方法の例を次に示します。
>>> import email
>>> msg = email.message_from_bytes(myBytes)その他の注意事項
構文解析のセマンティクスに関する注意事項は次のとおりです。
- ほとんどの非 multipart タイプのメッセージは、文字列ペイロードを持つ単一のメッセージオブジェクトとして解析されます。 これらのオブジェクトは、 is_multipart（）に対して
Falseを返し、 iter_parts（）は空のリストを生成します。 - すべての multipart タイプのメッセージは、ペイロードのサブメッセージオブジェクトのリストを含むコンテナメッセージオブジェクトとして解析されます。 外部コンテナメッセージは、 is_multipart（）に対して
Trueを返し、 iter_parts（）はサブパーツのリストを生成します。 - コンテンツタイプが message / * のほとんどのメッセージ（ message / delivery-status や message / rfc822 など）も、長さ1のペイロードをリストします。 それらの is_multipart（）メソッドは
Trueを返します。 iter_parts（）によって生成された単一の要素は、サブメッセージオブジェクトになります。 - 一部の非標準準拠メッセージは、 multipart -ednessに関して内部的に一貫していない場合があります。 このようなメッセージには、タイプ multipart の Content-Type ヘッダーが含まれる場合がありますが、 is_multipart（）メソッドは
Falseを返す場合があります。 このようなメッセージが FeedParser で解析された場合、欠陥属性リストにMultipartInvariantViolationDefectクラスのインスタンスが含まれます。 詳細については、 email.errors を参照してください。
