java.io.UnsupportedEncodingException: latin-iso8859-1
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Groundhog Usenet Reader |
In Progress
|
Undecided
|
Unassigned |
Bug Description
The problem is (probably) due to non-standard (malformed?) charset string.
Here's the backtrace:
W/MimeEntity( 2154): Unexpected end of headers detected. Higher level boundary detected or EOF reached.
W/BodyFactory( 2154): MIME charset 'latin-iso8859-1' has no corresponding Java charset. Using Charset[US-ASCII] instead.
W/System.err( 2154): java.io.
W/System.err( 2154): at java.lang.
W/System.err( 2154): at java.lang.
W/System.err( 2154): at java.lang.
W/System.err( 2154): at com.almarsoft.
W/System.err( 2154): at com.almarsoft.
W/System.err( 2154): at com.almarsoft.
W/System.err( 2154): at android.
W/System.err( 2154): at java.util.
W/System.err( 2154): at java.util.
W/System.err( 2154): at java.util.
W/System.err( 2154): at java.util.
W/System.err( 2154): at java.lang.
W/System.err( 2154): Caused by: java.nio.
W/System.err( 2154): at java.nio.
W/System.err( 2154): at java.lang.
W/System.err( 2154): ... 11 more
The cause of the problem is here:
com.almarsoft.
All cases where String is constructed with supplied charset string, there should be additional sanity check if given charset string is known at all. If not, there could be some fallback to some sane default.
There's a method in mime4j's BodyFactory called toJavaCharset. It looks like a good start for similar solution on Groundhog's side.
Once again, I can't test it, because I don't have SDK installed. Maybe it's time to start playing with it ;)
I'll test toJavaCharset and if that also fails default to iso-8859-1. Thanks for the tip and the backtrace.