email -- An email and MIME handling package
::-- zhuyj [2008-07-07 14:32:33]
Contents
New in version 2.2.
- The email package is a library for managing email messages, including MIME and other RFC 2822-based message documents. It subsumes most of the functionality in several older standard modules such as rfc822, mimetools, multifile, and other non-standard packages such as mimecntl. It is specifically not designed to do any sending of email messages to SMTP (RFC 2821), NNTP, or other servers; those are functions of modules such as smtplib and nntplib. The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231.
email包是一个用来管理email消息的库，email消息包含MIME和其他基于RFC 2822的信息文档。它汇集了几个陈旧的标准模块，例如rfc822，mimetools,multifile,和其他非标准的包例如mimecntl的大多数功能。很明显它不是被设计用来做例如向SMTP(RFC 2821), NNTP，或其他服务发送邮件，那是smtplib和nntplib模块的功能。email包试图尽可能的适应RFC，支持除RFC 2822外，与MIME有关联的RFC，比如RFC 2045, RFC 2046, RFC 2047, 和 RFC 2231。
- The primary distinguishing feature of the email package is that it splits the parsing and generating of email messages from the internal object model representation of email. Applications using the email package deal primarily with objects; you can add sub-objects to messages, remove sub-objects from messages, completely re-arrange the contents, etc. There is a separate parser and a separate generator which handles the transformation from flat text to the object model, and then back to flat text again. There are also handy subclasses for some common MIME object types, and a few miscellaneous utilities that help with such common tasks as extracting and parsing message field values, creating RFC-compliant dates, etc.
email包最主要的区别特性是通过email的内部对象模型表示法来拆分分析和生成email消息。应用程序利用email包主要处理对象；你可以给消息增加子对象,从消息中删除子对象，完全的重新整理目录等等。有一个独立的分析器和独立的生器用来完成单调的文本到对象模型,然后再到单调的文本的转换。并且还有便捷的子类针对一些通用的MIME对象类型，和一些多种功能用来进行一些通用任务例如提取和分析消息域的值，创建适用于RFC的日期等等。
- The following sections describe the functionality of the email package. The ordering follows a progression that should be common in applications: an email message is read as flat text from a file or other source, the text is parsed to produce the object structure of the email message, this structure is manipulated, and finally, the object tree is rendered back into flat text. It is perfectly feasible to create the object structure out of whole cloth -- i.e. completely from scratch. From there, a similar progression can be taken as above. Also included are detailed specifications of all the classes and modules that the email package provides, the exception classes you might encounter while using the email package, some auxiliary utilities, and a few examples. For users of the older mimelib package, or previous versions of the email package, a section on differences and porting is provided.
See Also: Module smtplib:
SMTP protocol client.
Module nntplib:
NNTP protocol client.
1. Representing an email message
The central class in the email package is the Message class, imported from the email.message module. It is the base class for the email object model. Message provides the core functionality for setting and querying header fields, and for accessing message bodies.
- Conceptually, a Message object consists of headers and payloads. Headers are RFC 2822 style field names and values where the field name and value are separated by a colon. The colon is not part of either the field name or the field value. Headers are stored and returned in case-preserving form but are matched case-insensitively. There may also be a single envelope header, also known as the Unix-From header or the From_ header. The payload is either a string in the case of simple message objects or a list of Message objects for MIME container documents (e.g. multipart/* and message/rfc822).
Message objects provide a mapping style interface for accessing the message headers, and an explicit interface for accessing both the headers and the payload. It provides convenience methods for generating a flat text representation of the message object tree, for accessing commonly used header parameters, and for recursively walking over the object tree.
- Here are the methods of the Message class:
class Message( )
- The constructor takes no arguments.
as_string( [unixfrom])
- Return the entire message flatten as a string. When optional unixfrom is True, the envelope header is included in the returned string. unixfrom defaults to False. Note that this method is provided as a convenience and may not always format the message the way you want. For example, by default it mangles lines that begin with From . For more flexibility, instantiate a Generator instance and use its flatten() method directly. For example:
str( )
- Equivalent to as_string(unixfrom=True).
is_multipart( )
- Return True if the message's payload is a list of sub-Message objects, otherwise return False. When is_multipart() returns False, the payload should be a string object.
set_unixfrom( unixfrom)
- Set the message's envelope header to unixfrom, which should be a string.
get_unixfrom( )
- Return the message's envelope header. Defaults to None if the envelope header was never set.
attach( payload)
- Add the given payload to the current payload, which must be None or a list of Message objects before the call. After the call, the payload will always be a list of Message objects. If you want to set the payload to a scalar object (e.g. a string), use set_payload() instead.
get_payload( [i[, decode]])
- Return a reference the current payload, which will be a list of Message objects when is_multipart() is True, or a string when is_multipart() is False. If the payload is a list and you mutate the list object, you modify the message's payload in place.
With optional argument i, get_payload() will return the i-th element of the payload, counting from zero, if is_multipart() is True. An IndexError will be raised if i is less than 0 or greater than or equal to the number of items in the payload. If the payload is a string (i.e. is_multipart() is False) and i is given, a TypeError is raised. Optional decode is a flag indicating whether the payload should be decoded or not, according to the Content-Transfer-Encoding: header. When True and the message is not a multipart, the payload will be decoded if this header's value is "quoted-printable" or "base64". If some other encoding is used, or Content-Transfer-Encoding: header is missing, or if the payload has bogus base64 data, the payload is returned as-is (undecoded). If the message is a multipart and the decode flag is True, then None is returned. The default for decode is False.
set_payload( payload[, charset])
- Set the entire message object's payload to payload. It is the client's responsibility to ensure the payload invariants. Optional charset sets the message's default character set; see set_charset() for details.
Changed in version 2.2.2: charset argument added.
set_charset( charset)
Set the character set of the payload to charset, which can either be a Charset instance (see email.charset), a string naming a character set, or None. If it is a string, it will be converted to a Charset instance. If charset is None, the charset parameter will be removed from the Content-Type: header. Anything else will generate a TypeError. The message will be assumed to be of type text/* encoded with charset.input_charset. It will be converted to charset.output_charset and encoded properly, if needed, when generating the plain text representation of the message. MIME headers (MIME-Version:, Content-Type:, Content-Transfer-Encoding:) will be added as needed.
New in version 2.2.2.
get_charset( )
- Return the Charset instance associated with the message's payload. New in version 2.2.2. The following methods implement a mapping-like interface for accessing the message's RFC 2822 headers. Note that there are some semantic differences between these methods and a normal mapping (i.e. dictionary) interface. For example, in a dictionary there are no duplicate keys, but here there may be duplicate message headers. Also, in dictionaries there is no guaranteed order to the keys returned by keys(), but in a Message object, headers are always returned in the order they appeared in the original message, or were added to the message later. Any header deleted and then re-added are always appended to the end of the header list. These semantic differences are intentional and are biased toward maximal convenience. Note that in all cases, any envelope header present in the message is not included in the mapping interface.
len( )
- Return the total number of headers, including duplicates.
contains( name)
- Return true if the message object has a field named name. Matching is done case-insensitively and name should not include the trailing colon. Used for the in operator, e.g.:
getitem( name)
Return the value of the named header field. name should not include the colon field separator. If the header is missing, None is returned; a KeyError is never raised. Note that if the named field appears more than once in the message's headers, exactly which of those field values will be returned is undefined. Use the get_all() method to get the values of all the extant named headers.
setitem( name, val)
- Add a header to the message with field name name and value val. The field is appended to the end of the message's existing fields. Note that this does not overwrite or delete any existing header with the same name. If you want to ensure that the new header is the only one present in the message with field name name, delete the field first, e.g.:
delitem( name)
- Delete all occurrences of the field with name name from the message's headers. No exception is raised if the named field isn't present in the headers.
has_key( name)
- Return true if the message contains a header field named name, otherwise return false.
keys( )
- Return a list of all the message's header field names.
values( )
- Return a list of all the message's field values.
items( )
- Return a list of 2-tuples containing all the message's field headers and values.
get( name[, failobj])
Return the value of the named header field. This is identical to getitem() except that optional failobj is returned if the named header is missing (defaults to None). Here are some additional useful methods:
get_all( name[, failobj])
- Return a list of all the values for the field named name. If there are no such named headers in the message, failobj is returned (defaults to None).
add_header( _name, _value, **_params)
Extended header setting. This method is similar to setitem() except that additional header parameters can be provided as keyword arguments. _name is the header field to add and _value is the primary value for the header. For each item in the keyword argument dictionary _params, the key is taken as the parameter name, with underscores converted to dashes (since dashes are illegal in Python identifiers). Normally, the parameter will be added as key="value" unless the value is None, in which case only the key will be added. Here's an example:
1 msg.add_header('Content-Disposition', 'attachment', filename='bud.gif')
- This will add a header that looks like
Content-Disposition: attachment; filename="bud.gif"
replace_header( _name, _value)
Replace a header. Replace the first header found in the message that matches _name, retaining header order and field name case. If no matching header was found, a KeyError is raised.
New in version 2.2.2.
get_content_type( )
- Return the message's content type. The returned string is coerced to lower case of the form maintype/subtype. If there was no Content-Type: header in the message the default type as given by get_default_type() will be returned. Since according to RFC 2045, messages always have a default type, get_content_type() will always return a value.
RFC 2045 defines a message's default type to be text/plain unless it appears inside a multipart/digest container, in which case it would be message/rfc822. If the Content-Type: header has an invalid type specification, RFC 2045 mandates that the default type be text/plain.
New in version 2.2.2.
get_content_maintype( )
- Return the message's main content type. This is the maintype part of the string returned by get_content_type().
New in version 2.2.2.
get_content_subtype( )
- Return the message's sub-content type. This is the subtype part of the string returned by get_content_type().
New in version 2.2.2.
get_default_type( )
- Return the default content type. Most messages have a default content type of text/plain, except for messages that are subparts of multipart/digest containers. Such subparts have a default content type of message/rfc822.
New in version 2.2.2.
set_default_type( ctype)
- Set the default content type. ctype should either be text/plain or message/rfc822, although this is not enforced. The default content type is not stored in the Content-Type: header.
New in version 2.2.2.
get_params( [failobj[, header[, unquote]]])
- Return the message's Content-Type: parameters, as a list. The elements of the returned list are 2-tuples of key/value pairs, as split on the "=" sign. The left hand side of the "=" is the key, while the right hand side is the value. If there is no "=" sign in the parameter the value is the empty string, otherwise the value is as described in get_param() and is unquoted if optional unquote is True (the default). Optional failobj is the object to return if there is no Content-Type: header. Optional header is the header to search instead of Content-Type:.
Changed in version 2.2.2: unquote argument added.
get_param( param[, failobj[, header[, unquote]]])
- Return the value of the Content-Type: header's parameter param as a string. If the message has no Content-Type: header or if there is no such parameter, then failobj is returned (defaults to None). Optional header if given, specifies the message header to use instead of Content-Type:. Parameter keys are always compared case insensitively. The return value can either be a string, or a 3-tuple if the parameter was RFC 2231 encoded. When it's a 3-tuple, the elements of the value are of the form (CHARSET, LANGUAGE, VALUE). Note that both CHARSET and LANGUAGE can be None, in which case you should consider VALUE to be encoded in the us-ascii charset. You can usually ignore LANGUAGE. If your application doesn't care whether the parameter was encoded as in RFC 2231, you can collapse the parameter value by calling email.Utils.collapse_rfc2231_value(), passing in the return value from get_param(). This will return a suitably decoded Unicode string whn the value is a tuple, or the original string unquoted if it isn't. For example:
- In any case, the parameter value (either the returned string, or the VALUE item in the 3-tuple) is always unquoted, unless unquote is set to False.
Changed in version 2.2.2: unquote argument added, and 3-tuple return value possible. set_param( param, value[, header[, requote[, charset[, language]]]])
- Set a parameter in the Content-Type: header. If the parameter already exists in the header, its value will be replaced with value. If the Content-Type: header as not yet been defined for this message, it will be set to text/plain and the new parameter value will be appended as per RFC 2045. Optional header specifies an alternative header to Content-Type:, and all parameters will be quoted as necessary unless optional requote is False (the default is True). If optional charset is specified, the parameter will be encoded according to RFC 2231. Optional language specifies the RFC 2231 language, defaulting to the empty string. Both charset and language should be strings.
New in version 2.2.2.
del_param( param[, header[, requote]])
- Remove the given parameter completely from the Content-Type: header. The header will be re-written in place without the parameter or its value. All values will be quoted as necessary unless requote is False (the default is True). Optional header specifies an alternative to Content-Type:.
New in version 2.2.2.
set_type( type[, header][, requote])
Set the main type and subtype for the Content-Type: header. type must be a string in the form maintype/subtype, otherwise a ValueError is raised. This method replaces the Content-Type: header, keeping all the parameters in place. If requote is False, this leaves the existing header's quoting as is, otherwise the parameters will be quoted (the default). An alternative header can be specified in the header argument. When the Content-Type: header is set a MIME-Version: header is also added.
New in version 2.2.2.
get_filename( [failobj])
- Return the value of the filename parameter of the Content-Disposition: header of the message. If the header does not have a filename parameter, this method falls back to looking for the name parameter. If neither is found, or the header is missing, then failobj is returned. The returned string will always be unquoted as per Utils.unquote().
get_boundary( [failobj])
- Return the value of the boundary parameter of the Content-Type: header of the message, or failobj if either the header is missing, or has no boundary parameter. The returned string will always be unquoted as per Utils.unquote().
set_boundary( boundary)
Set the boundary parameter of the Content-Type: header to boundary. set_boundary() will always quote boundary if necessary. A HeaderParseError is raised if the message object has no Content-Type: header. Note that using this method is subtly different than deleting the old Content-Type: header and adding a new one with the new boundary via add_header(), because set_boundary() preserves the order of the Content-Type: header in the list of headers. However, it does not preserve any continuation lines which may have been present in the original Content-Type: header.
get_content_charset( [failobj])
- Return the charset parameter of the Content-Type: header, coerced to lower case. If there is no Content-Type: header, or if that header has no charset parameter, failobj is returned. Note that this method differs from get_charset() which returns the Charset instance for the default encoding of the message body.
New in version 2.2.2.
get_charsets( [failobj])
- Return a list containing the character set names in the message. If the message is a multipart, then the list will contain one element for each subpart in the payload, otherwise, it will be a list of length 1. Each item in the list will be a string which is the value of the charset parameter in the Content-Type: header for the represented subpart. However, if the subpart has no Content-Type: header, no charset parameter, or is not of the text main MIME type, then that item in the returned list will be failobj.
walk( )
- The walk() method is an all-purpose generator which can be used to iterate over all the parts and subparts of a message object tree, in depth-first traversal order. You will typically use walk() as the iterator in a for loop; each iteration returns the next subpart. Here's an example that prints the MIME type of every part of a multipart message structure:
>>> for part in msg.walk(): ... print part.get_content_type() multipart/report text/plain message/delivery-status text/plain text/plain message/rfc822
Changed in version 2.5: The previously deprecated methods get_type(), get_main_type(), and get_subtype() were removed.
Message objects can also optionally contain two instance attributes, which can be used when generating the plain text of a MIME message.
preamble
- The format of a MIME document allows for some text between the blank line following the headers, and the first multipart boundary string. Normally, this text is never visible in a MIME-aware mail reader because it falls outside the standard MIME armor. However, when viewing the raw text of the message, or when viewing the message in a non-MIME aware reader, this text can become visible. The preamble attribute contains this leading extra-armor text for MIME documents. When the Parser discovers some text after the headers but before the first boundary string, it assigns this text to the message's preamble attribute. When the Generator is writing out the plain text representation of a MIME message, and it finds the message has a preamble attribute, it will write this text in the area between the headers and the first boundary. See email.parser and email.generator for details. Note that if the message object has no preamble, the preamble attribute will be None.
epilogue
- The epilogue attribute acts the same way as the preamble attribute, except that it contains text that appears between the last boundary and the end of the message.
Changed in version 2.5: You do not need to set the epilogue to the empty string in order for the Generator to print a newline at the end of the file.
defects
- The defects attribute contains a list of all the problems found when parsing this message. See email.errors for a detailed description of the possible parsing defects.
New in version 2.4.