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
<[email protected]>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
