summaryrefslogtreecommitdiff
path: root/Doc/library/email.message.rst
diff options
context:
space:
mode:
authorR. David Murray <rdmurray@bitdance.com>2010-10-08 15:55:28 +0000
committerR. David Murray <rdmurray@bitdance.com>2010-10-08 15:55:28 +0000
commit96fd54eaec700cc50e5960f45ee79bc25c2c48c5 (patch)
tree4e4fc3f48d8957b6b0fccc372410e8374ce4fb70 /Doc/library/email.message.rst
parent59fdd6736bbf1ba14083a4bb777abaefc364f876 (diff)
downloadcpython-git-96fd54eaec700cc50e5960f45ee79bc25c2c48c5.tar.gz
#4661: add bytes parsing and generation to email (email version bump to 5.1.0)
The work on this is not 100% complete, but everything is present to allow real-world testing of the code. The only remaining major todo item is to (hopefully!) enhance the handling of non-ASCII bytes in headers converted to unicode by RFC2047 encoding them rather than replacing them with '?'s.
Diffstat (limited to 'Doc/library/email.message.rst')
-rw-r--r--Doc/library/email.message.rst18
1 files changed, 15 insertions, 3 deletions
diff --git a/Doc/library/email.message.rst b/Doc/library/email.message.rst
index 9dcb2b427d..dc305a7fd8 100644
--- a/Doc/library/email.message.rst
+++ b/Doc/library/email.message.rst
@@ -111,9 +111,17 @@ Here are the methods of the :class:`Message` class:
be decoded if this header's value is ``quoted-printable`` or ``base64``.
If some other encoding is used, or :mailheader:`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``.
+ returned as-is (undecoded). In all cases the returned value is binary
+ data. If the message is a multipart and the *decode* flag is ``True``,
+ then ``None`` is returned.
+
+ When *decode* is ``False`` (the default) the body is returned as a string
+ without decoding the :mailheader:`Content-Transfer-Encoding`. However,
+ for a :mailheader:`Content-Transfer-Encoding` of 8bit, an attempt is made
+ to decode the original bytes using the `charset` specified by the
+ :mailheader:`Content-Type` header, using the `replace` error handler. If
+ no `charset` is specified, or if the `charset` given is not recognized by
+ the email package, the body is decoded using the default ASCII charset.
.. method:: set_payload(payload, charset=None)
@@ -160,6 +168,10 @@ Here are the methods of the :class:`Message` class:
Note that in all cases, any envelope header present in the message is not
included in the mapping interface.
+ In a model generated from bytes, any header values that (in contravention
+ of the RFCs) contain non-ASCII bytes will have those bytes transformed
+ into '?' characters when the values are retrieved through this interface.
+
.. method:: __len__()