18.1.2. email.parser：電子メールメッセージの解析—Pythonドキュメント
18.1.2。 email.parser ：電子メールメッセージの解析
メッセージオブジェクト構造は、2つの方法のいずれかで作成できます。メッセージオブジェクトをインスタンス化し、 attach（）および set_payload（）を介してそれらをストリング化することにより、クロス全体から作成できます。 呼び出し、または電子メールメッセージのフラットテキスト表現を解析して作成できます。
email パッケージは、MIMEドキュメントを含むほとんどのメールドキュメント構造を理解する標準パーサーを提供します。 パーサーに文字列またはファイルオブジェクトを渡すことができ、パーサーはオブジェクト構造のルートメッセージインスタンスを返します。 単純な非MIMEメッセージの場合、このルートオブジェクトのペイロードは、メッセージのテキストを含む文字列になる可能性があります。 MIMEメッセージの場合、ルートオブジェクトは is_multipart（）メソッドからTrueを返し、サブパーツには get_payload（）および walkを介してアクセスできます。 （）メソッド。
実際には、従来の Parser APIとインクリメンタル FeedParser APIの2つのパーサーインターフェイスを使用できます。 従来の Parser APIは、メッセージのテキスト全体が文字列としてメモリにある場合、またはメッセージ全体がファイルシステム上のファイルに存在する場合に適しています。 FeedParser は、より多くの入力の待機をブロックする可能性のあるストリームからメッセージを読み取る場合に適しています（例： ソケットからの電子メールメッセージの読み取り）。 FeedParser はメッセージを段階的に消費および解析でき、パーサー 1 を閉じたときにのみルートオブジェクトを返します。
パーサーは限られた方法で拡張できることに注意してください。もちろん、独自のパーサーを最初から完全に実装することもできます。 email パッケージのバンドルパーサーと Message クラスの間には魔法のようなつながりがないため、カスタムパーサーは必要に応じてメッセージオブジェクトツリーを作成できます。
18.1.2.1。 FeedParser API
バージョン2.4の新機能。
email.feedparserモジュールからインポートされた FeedParser は、ソースからの電子メールメッセージのテキストを読み取るときに必要になるなど、電子メールメッセージの増分解析に役立つAPIを提供します。ブロックできます（例： ソケット）。 もちろん、 FeedParser を使用して、文字列またはファイルに完全に含まれる電子メールメッセージを解析できますが、このようなユースケースでは、従来の Parser APIの方が便利な場合があります。 2つのパーサーAPIのセマンティクスと結果は同じです。
FeedParser のAPIはシンプルです。 インスタンスを作成し、フィードするテキストがなくなるまで大量のテキストをフィードしてから、パーサーを閉じてルートメッセージオブジェクトを取得します。 FeedParser は、標準に準拠したメッセージを解析するときに非常に正確であり、非準拠のメッセージを解析するのに非常に優れており、メッセージがどのように壊れていると見なされたかに関する情報を提供します。 メッセージオブジェクトの defects 属性に、メッセージで見つかった問題のリストが入力されます。 検出できる欠陥のリストについては、 email.errors モジュールを参照してください。
FeedParser のAPIは次のとおりです。
- class email.parser.FeedParser([_factory])
FeedParser インスタンスを作成します。 オプションの _factory は引数なしの呼び出し可能であり、新しいメッセージオブジェクトが必要になるたびに呼び出されます。 デフォルトは email.message.Message クラスです。
- feed(data)
FeedParser にさらにデータをフィードします。 data は、1行以上を含む文字列である必要があります。 線は部分的である可能性があり、 FeedParser はそのような部分的な線を適切につなぎ合わせます。 文字列内の行には、一般的な3つの行末、キャリッジリターン、改行、またはキャリッジリターンと改行のいずれかを含めることができます（混合することもできます）。
- close()
FeedParser を閉じると、以前にフィードされたすべてのデータの解析が完了し、ルートメッセージオブジェクトが返されます。 閉じた FeedParser にさらにデータをフィードするとどうなるかは未定義です。
18.1.2.2。 パーサークラスAPI
email.parser モジュールからインポートされた Parser クラスは、メッセージの完全な内容が文字列またはファイルで利用可能な場合にメッセージを解析するために使用できるAPIを提供します。 email.parser モジュールは、HeaderParserと呼ばれる2番目のクラスも提供します。これは、メッセージのヘッダーのみに関心がある場合に使用できます。 HeaderParserは、メッセージ本文の解析を試みず、代わりにペイロードを文字列としてraw本文に設定するため、これらの状況でははるかに高速になる可能性があります。 HeaderParserには、 Parser クラスと同じAPIがあります。
- class email.parser.Parser([_class])
Parser クラスのコンストラクターは、オプションの引数 _class を取ります。 これは呼び出し可能なファクトリ（関数やクラスなど）である必要があり、サブメッセージオブジェクトを作成する必要がある場合は常に使用されます。 デフォルトは Message です（ email.message を参照）。 ファクトリは引数なしで呼び出されます。
オプションの strict フラグは無視されます。
バージョン2.4以降非推奨： Parser クラスは、Python2.4の新機能 FeedParser 、 all の下位互換性のあるAPIラッパーであるため構文解析は事実上非厳密です。 strict フラグを Parser コンストラクターに渡すのをやめるだけです。
バージョン2.2.2で変更： strict フラグが追加されました。
バージョン2.4で変更： strict フラグは非推奨になりました。
その他のパブリック Parser メソッドは次のとおりです。
- parse(fp[, headersonly])
ファイルのようなオブジェクト fp からすべてのデータを読み取り、結果のテキストを解析して、ルートメッセージオブジェクトを返します。 fp は、ファイルのようなオブジェクトで readline（）メソッドと read（）メソッドの両方をサポートする必要があります。
fp に含まれるテキストは、 RFC 2822 スタイルのヘッダーとヘッダー継続行のブロックとしてフォーマットする必要があり、オプションでエンベロープヘッダーを前に付ける必要があります。 ヘッダーブロックは、データの終わりまたは空白行のいずれかで終了します。 ヘッダーブロックの後には、メッセージの本文があります（MIMEでエンコードされたサブパーツが含まれている場合があります）。
オプションの headersonly は、ヘッダーの読み取り後に解析を停止するかどうかを指定するフラグです。 デフォルトは
Falseで、ファイルの内容全体を解析することを意味します。バージョン2.2.2で変更： headersonly フラグが追加されました。
文字列またはファイルオブジェクトからメッセージオブジェクト構造を作成することは非常に一般的なタスクであるため、便宜上2つの関数が提供されています。 これらは、トップレベルの email パッケージ名前空間で利用できます。
- email.message_from_string(s[, _class[, strict]])
文字列からメッセージオブジェクト構造を返します。 これは
Parser().parsestr(s)とまったく同じです。 オプションの _class および strict は、 Parser クラスコンストラクターと同様に解釈されます。バージョン2.2.2で変更： strict フラグが追加されました。
- email.message_from_file(fp[, _class[, strict]])
開いているファイルオブジェクトからメッセージオブジェクト構造ツリーを返します。 これは
Parser().parse(fp)とまったく同じです。 オプションの _class および strict は、 Parser クラスコンストラクターと同様に解釈されます。バージョン2.2.2で変更： strict フラグが追加されました。
インタラクティブなPythonプロンプトでこれを使用する方法の例を次に示します。
>>> import email
>>> msg = email.message_from_string(myString)18.1.2.3。 その他の注意事項
構文解析のセマンティクスに関する注意事項は次のとおりです。
- ほとんどの非 multipart タイプのメッセージは、文字列ペイロードを持つ単一のメッセージオブジェクトとして解析されます。 これらのオブジェクトは、 is_multipart（）に対して
Falseを返します。 彼らの get_payload（）メソッドは文字列オブジェクトを返します。 - すべての multipart タイプのメッセージは、ペイロードのサブメッセージオブジェクトのリストを含むコンテナメッセージオブジェクトとして解析されます。 外部コンテナメッセージは is_multipart（）に対して
Trueを返し、それらの get_payload（）メソッドは Message サブパーツのリストを返します。 - コンテンツタイプが message / * のほとんどのメッセージ（例： message / delivery-status および message / rfc822 ）も、長さ1のリストペイロードを含むコンテナーオブジェクトとして解析されます。 それらの is_multipart（）メソッドは
Trueを返します。 リストペイロードの単一の要素は、サブメッセージオブジェクトになります。 - 一部の非標準準拠メッセージは、 multipart -ednessに関して内部的に一貫していない場合があります。 このようなメッセージには、タイプ multipart の Content-Type ヘッダーが含まれる場合がありますが、 is_multipart（）メソッドは
Falseを返す場合があります。 このようなメッセージが FeedParser で解析された場合、欠陥属性リストにMultipartInvariantViolationDefectクラスのインスタンスが含まれます。 詳細については、 email.errors を参照してください。
脚注
- 1
- Python 2.4で導入された電子メールパッケージバージョン3.0の時点で、従来の Parser が FeedParser に関して再実装されたため、セマンティクスと結果は2つのパーサー間で同じです。
