Tex-Twil wrote:
"US-ASCI" is not ISO-8859-1 so why does this method returns it ?

Since ASCII is a subset of ISO-8859-1, all bytes in the range 0x00 to 0x7f will convert correctly and there should be none outside of this range to convert wrongly. I'm not saying I like this flaw but it does not hurt and I could live with it. If you feel strongly about it then raise a bug report.

Tex-Twil wrote:
"US-ASCI" is not ISO-8859-1 so why does this method returns it ?

Since ASCII is a subset of ISO-8859-1, all bytes in the range 0x00 to 0x7f will convert correctly and there should be none outside of this range to convert wrongly. I'm not saying I like this flaw but it does not hurt and I could live with it. If you feel strongly about it then raise a bug report.

It works this way but not the other way round. A text with a "US-ASCII" charset cannot encode all of the "ISO-8859-1" characters.

so:

"US-ASCII" contains "ISO-8859-1" is FALSE.

but

MimeUtility.javaCharset("US-ASCII") contains "ISO-8859-1" will be TRUE

Tex-Twil wrote:
"US-ASCI" is not ISO-8859-1 so why does this method returns it ?

Since ASCII is a subset of ISO-8859-1, all bytes in the range 0x00 to 0x7f will convert correctly and there should be none outside of this range to convert wrongly. I'm not saying I like this flaw but it does not hurt and I could live with it. If you feel strongly about it then raise a bug report.

It works this way but not the other way round. A text with a "US-ASCII" charset cannot encode all of the "ISO-8859-1" characters.

so:

"US-ASCII" contains "ISO-8859-1" is FALSE.

but

MimeUtility.javaCharset("US-ASCII") contains "ISO-8859-1" will be TRUE

The second statement does not make sense for me.

I'm not sure what exactly you are asking? sabre150's basic point was that if you get a mime part encoded using the "US-ASCII" charset, then you can successfully decode it using the "ISO-8859-1" charset. so, everything should "work" just fine.

I'm not sure what exactly you are asking? sabre150's basic point was that if you get a mime part encoded using the "US-ASCII" charset, then you can successfully decode it using the "ISO-8859-1" charset. so, everything should "work" just fine.

The bottom line is the following. I have an e-mail body part and I need to determine dynamically if I can insert the text "inline" to the e-mail body part. For this, I check if the charset of the body part "contains" the charset of the text. If yes, I just add the text to the e-mail body part. If no, I add the text as another e-mail body part to the e-mail.

In this situation, the IF condition is true, indicating that I can append a "ISO-8859-1" text to a "US-ASCII" mail body part ... . ISO-8859-1 characters, such as ü cannot be encoded using US-ASCII, right ?

Where is my mistake? Shall I skip the MimeUtility.javaCharset call and use the charset name directly from the mime body part ?

jtahlborn wrote:
ah, now i understand your problem. in this situation, it is definitely a problem. maybe you should start by trying to load the Charset directly first, and then fallback to MimeUtility.

ok, that would be a workaround.

I just suppose that MimeUtility.javaCharset falls back to a default JVM character encoding when it cannot find the java equivalent.

btw, what is exactly the difference between a mime charset and a java charset?