Joe Steele 1d1db50a9f Don't always base64 encode in BinaryTempFileBody.writeTo ... Issue 5734 exemplifies the problem: receive a message with an attachment of type message/rfc822 that doesn't use base64 encoding for the body of the attached message. K-9 Mail incorrectly stores the attached message locally with its original headers but using base64 encoding for the body. A discrepancy thus exists between what the headers say about the encoding of the body versus the actual encoding used. This is obvious when attempting to view the attachment (either by using a compatible message viewer available on the device or by saving the attachment to a file and viewing the file contents). The process: When a message with an attached sub-message is received, Message.parse puts the attachment in a new MimeMessage with the attachment's body in a BinaryTempFileBody. LocalFolder.saveAttachment then calls Message.writeTo (which later calls BinaryTempFileBody.writeTo) to place the entire attachment (headers and body) in a new file that will become a LocalAttachmentBody. Until now, BinaryTempFileBody.writeTo could only save the message body using base64 encoding. This commit implements BinaryTempFileBody.setEncoding and assures that the body is written out with the same encoding that was found in its headers.		2013-09-03 19:51:26 -04:00
..
k9	Don't always base64 encode in BinaryTempFileBody.writeTo	2013-09-03 19:51:26 -04:00