• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

javax.mail attachment not correctly encoded

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

( i cross posted this question here, which i initially placed in Sockets and Internet Protocols)

I have developed an online auction system which, has a function to generate invoices using the iText libraries.
The invoices are stored as a ByteArray in a database and are mailed to the customer. This works find when running
the application within my IDE (Netbeans) on Mac OS X and Apache Tomcat 6.0.29 and javamail 1.4.3. When running the application on
Windows 2003 Server with same tomcat and javamail version the attachment is not readable on the client.

The attachment is added to the e-mail using the following code;



The raw e-mail of the attachment when it is correctly encoded (running from my IDE)



And again when encoded from the server


Both attachments have the same length, and are similar (but are exactly the same).
In the third line of the correctly encoded attachment the characters are; "gf" which are
encoded in the not correctly encoded attachment to "P/".

Also setting "-Dmail.mime.multipart.bmparse=false" did not make any difference.
Any ideas, suggestions, solutions ?

Cheers

Peter
 
Peter van Nes
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Nobody any suggestions, .... just a small hint... ?

 
Marshal
Posts: 28177
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What difference does it make?

I ask because sometimes e-mail systems will insert or remove line-ending characters for various reasons. Possibly that's what happened in your example, but since you only posted the encoded attachment, we can't tell that.
 
Sheriff
Posts: 22781
131
Eclipse IDE Spring VI Editor Chrome Java Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Are the byte arrays the same?
 
Peter van Nes
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
@Paul Clapham, The difference is that the mime-encoded attachment is not readable (corrupt) when sending it from the Windows server. Difference in line-endings do indeed not matter when the body part is of content type text, but when the content type is application/pdf it does make a difference

@Rob Prime, Yes they are exactly the same. The PDFs in the example do come from the same database. The invoices also can be viewed in a webpage and are therefore also encoded in Base64 and added to a data url. On both systems the pdfs can be viewed in the webpage. So i suspect that the base64 encoding in the javax.mail api is influenced by the line-ending characters on both systems. But when using org.apache.catalina.util.Base64 encoding is done correctly. Is there a way to enforce javax.mail to use this class for base64 encoding ?

Cheers
Peter
 
Ranch Hand
Posts: 781
Netbeans IDE Ubuntu Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Each line is 76 characters which is a multiple of 4 so each line can be decoded without reference to earlier lines. If you base64 decode and then hex encode the first 8 bytes of the third line of each block you get


This indicates that the 0x81 has been converted to 0x3F. Now 0x3F as an ASCII character is the '?' so it looks to me like somewhere in your processing prior to being added as an attachment your binary file has been treated as text. Typically character encoders encode bytes they can't legitimately encode (such as say 0x81) as a '?'. As you are finding out, characters and String are not suitable as containers for binary data so find out where this binary file is treated as text and modify the code so that it doesn't.
 
Peter van Nes
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks James !

You were absolutely correct. Somewhere in a method i did put the byte array in a String, after fixing this it works perfect even on windows ;-)

Cheers Peter
 
reply
    Bookmark Topic Watch Topic
  • New Topic