james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rickard Ekeroth <R.Eker...@albourne.com>
Subject Re: [jira] [Resolved] (MIME4J-218) Content-Type Fallback Character Set
Date Wed, 02 Jan 2013 16:06:22 GMT
Hello Oleg! 

I will investigate the solution that you propose. 

Thank you for looking into this! 


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)" <mime4j-dev@james.apache.org> 
To: rekeroth@albourne.com 
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 


> 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 

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message