james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Günther Schmidt <guenther.schm...@kmmd.de>
Subject Re: Automatic Decoding of field contents
Date Wed, 30 May 2012 22:37:12 GMT
Hi Markus,

thank you very much, you seem to have nailed. And it even better, if I 
read this correctly it's "fixed" in 0.8. So I can even give it a spin.

Günther

Am 31.05.12 00:28, schrieb Markus Wiederkehr:
> 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
>>>
>>


-- 
KMMD IT-Consulting UG (haftungsbeschränkt)
Offenburger Str. 45
68239 Mannheim
Tel: +49-621-4393887
HRB 712101 Amtsgericht Mannheim


Mime
View raw message