New submission from Andreas Thomas <raed...@gmail.com>: The attachment of my sample email contains '123\n', but get_payload (decode=True) returns '123'. The source of this error is the function _bdecode from the email.utils module, which gets called for decoding base64 encoded payloads. Here the last \n gets stripped away, because (comment in the function):
# We can't quite use base64.encodestring() since it tacks on a "courtesy # newline". Blech! I don't think that's true. At least not for Python 2.5.4 and upwards. Also note the "encodestring" instead of "decodestring". In fact calling base64.decodestring(part.get_payload()) returns the correct value, so I propose to remove this function completely and just use the standard decoding method. Please note that base64.encodestring really tacks on a \n. ---------- components: Library (Lib) files: test.eml messages: 94100 nosy: athomas severity: normal status: open title: get_payload(decode=True) eats last newline type: behavior versions: Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file15139/test.eml _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue7143> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
