You are viewing a plain text version of this content. The canonical link for it is here.
Posted to mime4j-dev@james.apache.org by Rickard Ekeroth <R....@albourne.com> on 2012/10/26 16:44:28 UTC
Content-Type Fallback Character Set
Hello!
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.
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.
Re: Content-Type Fallback Character Set
Posted by Rickard Ekeroth <R....@albourne.com>.
Hello Oleg!
I have posted an issue in JIRA (MIME4J-218) now.
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" <ol...@apache.org>
To: mime4j-dev@james.apache.org
Sent: Wednesday, October 31, 2012 12:23:28 PM
Subject: Re: Content-Type Fallback Character Set
On Mon, Oct 29, 2012 at 03:47:30PM -0000, Rickard Ekeroth wrote:
> Hello Oleg!
>
> 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"
>
>
> Regards,
>
> Rickard Ekeroth
> Albourne Partners (Cyprus) Ltd.
>
Hi Rickard
The exception stack trace and the Content-Type header alone should be sufficient. Please raiase a change request in JIRA nonetheless. I'll try to get around to implementing it. JIRA will help keep track of the progress or lack thereof.
Oleg
Re: Content-Type Fallback Character Set
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Mon, Oct 29, 2012 at 03:47:30PM -0000, Rickard Ekeroth wrote:
> Hello Oleg!
>
> 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"
>
>
> Regards,
>
> Rickard Ekeroth
> Albourne Partners (Cyprus) Ltd.
>
Hi Rickard
The exception stack trace and the Content-Type header alone should be sufficient. Please raiase a change request in JIRA nonetheless. I'll try to get around to implementing it. JIRA will help keep track of the progress or lack thereof.
Oleg
Re: Content-Type Fallback Character Set
Posted by Rickard Ekeroth <R....@albourne.com>.
Hello Oleg!
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"
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" <ol...@apache.org>
To: mime4j-dev@james.apache.org
Sent: Saturday, October 27, 2012 1:41:27 PM
Subject: Re: Content-Type Fallback Character Set
On Fri, 2012-10-26 at 14:44 +0000, Rickard Ekeroth wrote:
> Hello!
>
> 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.
>
Rickard
could you please post a complete stack trace of the exception and, if
possible, the message content that caused it? Probably the best way to
go about it would be to raise a change request in JIRA and attach both
artifacts to it.
Oleg
>
> 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.
>
>
Re: Content-Type Fallback Character Set
Posted by Oleg Kalnichevski <ol...@apache.org>.
On Fri, 2012-10-26 at 14:44 +0000, Rickard Ekeroth wrote:
> Hello!
>
> 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.
>
Rickard
could you please post a complete stack trace of the exception and, if
possible, the message content that caused it? Probably the best way to
go about it would be to raise a change request in JIRA and attach both
artifacts to it.
Oleg
>
> 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.
>
>