Can somebody tell me why Carriage return and line feed are inserted into an attachment (text/plain)? Is there anyway to bypass that? If not, can we tell them to insert according to the encoding of the attachment?
The problem I am encountering is that I have a text file that is encoded in 'Unicode-16BE'. After sending it through as an attachment, I see that there are extra sets of CR/LF attached to each line, and the problem appears to be that the newly added CR/LF are not in Big Endian format.
The original CR/LF for the file appears to be '00 0D 00 0A', but after sending through, and its new version becomes '00 0D 0A 00 0D 0A'. I am not exactly sure why the order of '00 0A' at the end got swapped, and then '0D 0A' is appended.
I'm just wondering if such an encoding is supported. Here are the code snippet I used
Multipart mixedPart = new MimeMultipart( "mixed" );
.... //mixedPart.addBodyPart( alternativePart) etc...
// attach the file to its own mime body part
MimeBodyPart att = new MimeBodyPart();
FileDataSource fds = new FileDataSource( file ) {
@Override
public String getContentType() {
return "text/plain; charset="UTF-16BE";
}
};
DataHandler dataHandler = new DataHandler( fds );
att.setDataHandler( dataHandler );
att.setFileName( fileName );
// Add the attachment to the Multipart message
mixedPart.addBodyPart( att );
{code}
Any help is appreciated.
Thanks
Ray