Hello Oleg! I will investigate the solution that you propose.
Thank you for looking into this! Regards, Rickard Ekeroth Albourne Partners (Cyprus) Ltd. If you are not an intended recipient of this e-mail, please notify the sender, delete it and do not read, act upon, print, disclose, copy, retain or redistribute it. Please visit http://www.albourne.com/email.html for important additional terms relating to this e-mail. ----- Original Message ----- From: "Oleg Kalnichevski (JIRA)" <[email protected]> To: [email protected] Sent: Wednesday, January 2, 2013 6:00:12 PM Subject: [jira] [Resolved] (MIME4J-218) Content-Type Fallback Character Set [ https://issues.apache.org/jira/browse/MIME4J-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Kalnichevski resolved MIME4J-218. -------------------------------------- Resolution: Won't Fix Hi Rickard I apologize that it took me so long to look into this issue. I turned out that mime4j already provides APIs flexible enough to give the users enough options to deal with illegal / unsupported charsets without requiring additional configuration options. That is, one can always opt to use a custom BodyFactory implementation that can do the necessary charset translations deemed appropriate for the given application context. To make such customization less painful, though, I did add new method #resolveCharset to the BasicBodyFactory that one can override without having to re-implement other aspects of the factory. Hope this helps Oleg > Content-Type Fallback Character Set > ----------------------------------- > > Key: MIME4J-218 > URL: https://issues.apache.org/jira/browse/MIME4J-218 > Project: James Mime4j > Issue Type: Bug > Affects Versions: 0.7.2 > Reporter: Rickard Ekeroth > > Would it be possible to add a feature that would allow for specifying a > fallback character set to use when the character set in a 'Content-Type' > header is not recognized by Java? In the old 0.6.2 version, that we used > before, the character set 'ISO-8859-1' was used as a fallback but in the > 0.7.2 version an UnsupportedEncodingException is thrown when the parser > encounters an unknown character set in a Content-Type header. > Here is the relevant part of the exception stack trace: > Caused by: java.io.UnsupportedEncodingException: x-user-defined > at sun.nio.cs.StreamDecoder.forInputStreamReader(StreamDecoder.java:52) > at java.io.InputStreamReader.<init>(InputStreamReader.java:83) > at > org.apache.james.mime4j.message.BasicTextBody.getReader(BasicTextBody.java:49) > > We receive, parse and archive a vast number of confidential e-mail messages > (for which we use Mime4J) and every now and then we get an e-mail message > that contains a non-standard character encoding name (in this case > 'x-user-defined'). With the old (0.6) Mime4J version we were still able to > parse and read most of those e-mail messages because of the fallback > character set in the parser. > I can unfortunately not post the entire message here but the content-type > header that caused the above exception looks like this: > Content-Type: text/plain; charset="x-user-defined" -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
