Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 1 | :mod:`email`: Parsing email messages |
| 2 | ------------------------------------ |
| 3 | |
| 4 | .. module:: email.parser |
| 5 | :synopsis: Parse flat text email messages to produce a message object structure. |
| 6 | |
| 7 | |
| 8 | Message object structures can be created in one of two ways: they can be created |
Georg Brandl | 3638e48 | 2009-04-27 16:46:17 +0000 | [diff] [blame^] | 9 | from whole cloth by instantiating :class:`~email.message.Message` objects and |
| 10 | stringing them together via :meth:`attach` and :meth:`set_payload` calls, or they |
| 11 | can be created by parsing a flat text representation of the email message. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 12 | |
| 13 | The :mod:`email` package provides a standard parser that understands most email |
| 14 | document structures, including MIME documents. You can pass the parser a string |
Georg Brandl | 3638e48 | 2009-04-27 16:46:17 +0000 | [diff] [blame^] | 15 | or a file object, and the parser will return to you the root |
| 16 | :class:`~email.message.Message` instance of the object structure. For simple, |
| 17 | non-MIME messages the payload of this root object will likely be a string |
| 18 | containing the text of the message. For MIME messages, the root object will |
| 19 | return ``True`` from its :meth:`is_multipart` method, and the subparts can be |
| 20 | accessed via the :meth:`get_payload` and :meth:`walk` methods. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 21 | |
| 22 | There are actually two parser interfaces available for use, the classic |
| 23 | :class:`Parser` API and the incremental :class:`FeedParser` API. The classic |
| 24 | :class:`Parser` API is fine if you have the entire text of the message in memory |
| 25 | as a string, or if the entire message lives in a file on the file system. |
| 26 | :class:`FeedParser` is more appropriate for when you're reading the message from |
| 27 | a stream which might block waiting for more input (e.g. reading an email message |
| 28 | from a socket). The :class:`FeedParser` can consume and parse the message |
| 29 | incrementally, and only returns the root object when you close the parser [#]_. |
| 30 | |
| 31 | Note that the parser can be extended in limited ways, and of course you can |
| 32 | implement your own parser completely from scratch. There is no magical |
| 33 | connection between the :mod:`email` package's bundled parser and the |
Georg Brandl | 3638e48 | 2009-04-27 16:46:17 +0000 | [diff] [blame^] | 34 | :class:`~email.message.Message` class, so your custom parser can create message |
| 35 | object trees any way it finds necessary. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 36 | |
| 37 | |
| 38 | FeedParser API |
| 39 | ^^^^^^^^^^^^^^ |
| 40 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 41 | The :class:`FeedParser`, imported from the :mod:`email.feedparser` module, |
| 42 | provides an API that is conducive to incremental parsing of email messages, such |
| 43 | as would be necessary when reading the text of an email message from a source |
| 44 | that can block (e.g. a socket). The :class:`FeedParser` can of course be used |
| 45 | to parse an email message fully contained in a string or a file, but the classic |
| 46 | :class:`Parser` API may be more convenient for such use cases. The semantics |
| 47 | and results of the two parser APIs are identical. |
| 48 | |
| 49 | The :class:`FeedParser`'s API is simple; you create an instance, feed it a bunch |
| 50 | of text until there's no more to feed it, then close the parser to retrieve the |
| 51 | root message object. The :class:`FeedParser` is extremely accurate when parsing |
| 52 | standards-compliant messages, and it does a very good job of parsing |
| 53 | non-compliant messages, providing information about how a message was deemed |
| 54 | broken. It will populate a message object's *defects* attribute with a list of |
| 55 | any problems it found in a message. See the :mod:`email.errors` module for the |
| 56 | list of defects that it can find. |
| 57 | |
| 58 | Here is the API for the :class:`FeedParser`: |
| 59 | |
| 60 | |
| 61 | .. class:: FeedParser([_factory]) |
| 62 | |
| 63 | Create a :class:`FeedParser` instance. Optional *_factory* is a no-argument |
| 64 | callable that will be called whenever a new message object is needed. It |
| 65 | defaults to the :class:`email.message.Message` class. |
| 66 | |
| 67 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 68 | .. method:: feed(data) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 69 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 70 | Feed the :class:`FeedParser` some more data. *data* should be a string |
| 71 | containing one or more lines. The lines can be partial and the |
| 72 | :class:`FeedParser` will stitch such partial lines together properly. The |
| 73 | lines in the string can have any of the common three line endings, |
| 74 | carriage return, newline, or carriage return and newline (they can even be |
| 75 | mixed). |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 76 | |
| 77 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 78 | .. method:: close() |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 79 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 80 | Closing a :class:`FeedParser` completes the parsing of all previously fed |
| 81 | data, and returns the root message object. It is undefined what happens |
| 82 | if you feed more data to a closed :class:`FeedParser`. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 83 | |
| 84 | |
| 85 | Parser class API |
| 86 | ^^^^^^^^^^^^^^^^ |
| 87 | |
| 88 | The :class:`Parser` class, imported from the :mod:`email.parser` module, |
| 89 | provides an API that can be used to parse a message when the complete contents |
| 90 | of the message are available in a string or file. The :mod:`email.parser` |
| 91 | module also provides a second class, called :class:`HeaderParser` which can be |
| 92 | used if you're only interested in the headers of the message. |
| 93 | :class:`HeaderParser` can be much faster in these situations, since it does not |
| 94 | attempt to parse the message body, instead setting the payload to the raw body |
| 95 | as a string. :class:`HeaderParser` has the same API as the :class:`Parser` |
| 96 | class. |
| 97 | |
| 98 | |
| 99 | .. class:: Parser([_class]) |
| 100 | |
| 101 | The constructor for the :class:`Parser` class takes an optional argument |
| 102 | *_class*. This must be a callable factory (such as a function or a class), and |
| 103 | it is used whenever a sub-message object needs to be created. It defaults to |
Georg Brandl | 3638e48 | 2009-04-27 16:46:17 +0000 | [diff] [blame^] | 104 | :class:`~email.message.Message` (see :mod:`email.message`). The factory will |
| 105 | be called without arguments. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 106 | |
| 107 | The optional *strict* flag is ignored. |
| 108 | |
| 109 | .. deprecated:: 2.4 |
| 110 | Because the :class:`Parser` class is a backward compatible API wrapper |
| 111 | around the new-in-Python 2.4 :class:`FeedParser`, *all* parsing is |
| 112 | effectively non-strict. You should simply stop passing a *strict* flag to |
| 113 | the :class:`Parser` constructor. |
| 114 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 115 | The other public :class:`Parser` methods are: |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 116 | |
| 117 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 118 | .. method:: parse(fp[, headersonly]) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 119 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 120 | Read all the data from the file-like object *fp*, parse the resulting |
| 121 | text, and return the root message object. *fp* must support both the |
| 122 | :meth:`readline` and the :meth:`read` methods on file-like objects. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 123 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 124 | The text contained in *fp* must be formatted as a block of :rfc:`2822` |
| 125 | style headers and header continuation lines, optionally preceded by a |
| 126 | envelope header. The header block is terminated either by the end of the |
| 127 | data or by a blank line. Following the header block is the body of the |
| 128 | message (which may contain MIME-encoded subparts). |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 129 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 130 | Optional *headersonly* is as with the :meth:`parse` method. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 131 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 132 | .. method:: parsestr(text[, headersonly]) |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 133 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 134 | Similar to the :meth:`parse` method, except it takes a string object |
| 135 | instead of a file-like object. Calling this method on a string is exactly |
| 136 | equivalent to wrapping *text* in a :class:`StringIO` instance first and |
| 137 | calling :meth:`parse`. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 138 | |
Benjamin Peterson | e41251e | 2008-04-25 01:59:09 +0000 | [diff] [blame] | 139 | Optional *headersonly* is a flag specifying whether to stop parsing after |
| 140 | reading the headers or not. The default is ``False``, meaning it parses |
| 141 | the entire contents of the file. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 142 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 143 | |
| 144 | Since creating a message object structure from a string or a file object is such |
| 145 | a common task, two functions are provided as a convenience. They are available |
| 146 | in the top-level :mod:`email` package namespace. |
| 147 | |
Georg Brandl | a971c65 | 2008-11-07 09:39:56 +0000 | [diff] [blame] | 148 | .. currentmodule:: email |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 149 | |
| 150 | .. function:: message_from_string(s[, _class[, strict]]) |
| 151 | |
| 152 | Return a message object structure from a string. This is exactly equivalent to |
| 153 | ``Parser().parsestr(s)``. Optional *_class* and *strict* are interpreted as |
| 154 | with the :class:`Parser` class constructor. |
| 155 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 156 | |
| 157 | .. function:: message_from_file(fp[, _class[, strict]]) |
| 158 | |
| 159 | Return a message object structure tree from an open file object. This is |
| 160 | exactly equivalent to ``Parser().parse(fp)``. Optional *_class* and *strict* |
| 161 | are interpreted as with the :class:`Parser` class constructor. |
| 162 | |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 163 | Here's an example of how you might use this at an interactive Python prompt:: |
| 164 | |
| 165 | >>> import email |
| 166 | >>> msg = email.message_from_string(myString) |
| 167 | |
| 168 | |
| 169 | Additional notes |
| 170 | ^^^^^^^^^^^^^^^^ |
| 171 | |
| 172 | Here are some notes on the parsing semantics: |
| 173 | |
| 174 | * Most non-\ :mimetype:`multipart` type messages are parsed as a single message |
| 175 | object with a string payload. These objects will return ``False`` for |
| 176 | :meth:`is_multipart`. Their :meth:`get_payload` method will return a string |
| 177 | object. |
| 178 | |
| 179 | * All :mimetype:`multipart` type messages will be parsed as a container message |
| 180 | object with a list of sub-message objects for their payload. The outer |
| 181 | container message will return ``True`` for :meth:`is_multipart` and their |
Georg Brandl | 3638e48 | 2009-04-27 16:46:17 +0000 | [diff] [blame^] | 182 | :meth:`get_payload` method will return the list of :class:`~email.message.Message` |
| 183 | subparts. |
Georg Brandl | 116aa62 | 2007-08-15 14:28:22 +0000 | [diff] [blame] | 184 | |
| 185 | * Most messages with a content type of :mimetype:`message/\*` (e.g. |
| 186 | :mimetype:`message/delivery-status` and :mimetype:`message/rfc822`) will also be |
| 187 | parsed as container object containing a list payload of length 1. Their |
| 188 | :meth:`is_multipart` method will return ``True``. The single element in the |
| 189 | list payload will be a sub-message object. |
| 190 | |
| 191 | * Some non-standards compliant messages may not be internally consistent about |
| 192 | their :mimetype:`multipart`\ -edness. Such messages may have a |
| 193 | :mailheader:`Content-Type` header of type :mimetype:`multipart`, but their |
| 194 | :meth:`is_multipart` method may return ``False``. If such messages were parsed |
| 195 | with the :class:`FeedParser`, they will have an instance of the |
| 196 | :class:`MultipartInvariantViolationDefect` class in their *defects* attribute |
| 197 | list. See :mod:`email.errors` for details. |
| 198 | |
| 199 | .. rubric:: Footnotes |
| 200 | |
| 201 | .. [#] As of email package version 3.0, introduced in Python 2.4, the classic |
| 202 | :class:`Parser` was re-implemented in terms of the :class:`FeedParser`, so the |
| 203 | semantics and results are identical between the two parsers. |
| 204 | |