james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Wiederkehr <markus.wiederk...@gmail.com>
Subject Re: Automatic Decoding of field contents
Date Wed, 30 May 2012 22:28:31 GMT
This is a MIME extension that is not implemented in Mime4J, see
https://issues.apache.org/jira/browse/MIME4J-109

Markus

On Wed, May 30, 2012 at 11:07 PM, Günther Schmidt
<guenther.schmidt@kmmd.de>wrote:

> Hi everyone,
>
> sorry for the confusion, the mimeparser set to do decoding *does* also
> decode content fields. It just has trouble recognizing some more exotic
> ones correctly, like this one:
>
> Content-Type: application/zip; name*0*=iso-8859-15''Redcom%**
> 20Erl%F6santeilsplit;
>  name*1*=ter.zip
>
> Anybody here know a neat trick to get around this hick up?
>
> Günther
>
> Am 30.05.12 00:37, schrieb Günther Schmidt:
>
>> Hi everyone,
>>
>> I've figured out how to get the parser to automatically decode input
>> streams, ie make mime4j return Base64InputStream or
>> QuotedPrintableInputStream, by setting MimeStreamParser.**
>> setContentDecoding(true).
>>
>> However this does not seem to affect the contents of any of the headers
>> fields. Their bodies are still quotedprintable encoded, even when parsed,
>> ie turned into a ParsedField, which causes some errors in my code.
>>
>> I haven't found the switch for automatically decoding the field contents
>> as well. What do I have to do?
>>
>> Günther
>>
>
>

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