Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (athena.apache.org: domain of markus.wiederkehr@gmail.com
 designates 209.85.160.173 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FC6A118.2060705@kmmd.de>
References: <4FC54FA1.609@kmmd.de>
	<4FC68C1D.3000901@kmmd.de>
	<CA+h-BnsTQE1Rvj5=3vT9SzGqrJi377kyY1y776BcDxevPhs8ew@mail.gmail.com>
	<4FC6A118.2060705@kmmd.de>
Date: Thu, 31 May 2012 13:41:10 +0200
Message-ID: 
 <CA+h-Bnt+Wxw9-_Ntji9Agq4r3JNO097HHzuTZMz1Jdkby0Essw@mail.gmail.com>
Subject: Re: Automatic Decoding of field contents
From: Markus Wiederkehr <markus.wiederkehr@gmail.com>
To: mime4j-dev@james.apache.org
Content-Type: multipart/alternative; boundary=20cf303ddc4a50390704c1538b48

--20cf303ddc4a50390704c1538b48
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Sorry to disappoint you but "Fix Version" means it is scheduled to be fixed
in 0.8, it is not fixed yet. If nobody contributes a patch it will simply
be postponed to 0.9 once 0.8 is ready.

A patch would be welcome but we cannot accept a derivative work from
JavaMail or other sources if the license is not compatible.

Markus

On Thu, May 31, 2012 at 12:37 AM, G=C3=BCnther Schmidt
<guenther.schmidt@kmmd.de>wrote:

> 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=C3=BCnther
>
> 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<https://issues.apache=
.org/jira/browse/MIME4J-109>
>>
>> Markus
>>
>> On Wed, May 30, 2012 at 11:07 PM, G=C3=BCnther 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*=3Diso-8859-15''Redcom%**
>>>
>>> 20Erl%F6santeilsplit;
>>>  name*1*=3Dter.zip
>>>
>>> Anybody here know a neat trick to get around this hick up?
>>>
>>> G=C3=BCnther
>>>
>>> Am 30.05.12 00:37, schrieb G=C3=BCnther 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 header=
s
>>>> 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 conten=
ts
>>>> as well. What do I have to do?
>>>>
>>>> G=C3=BCnther
>>>>
>>>>
>>>
>
> --
> KMMD IT-Consulting UG (haftungsbeschr=C3=A4nkt)
> Offenburger Str. 45
> 68239 Mannheim
> Tel: +49-621-4393887
> HRB 712101 Amtsgericht Mannheim
>
>

--20cf303ddc4a50390704c1538b48--