Hello Patrick, On Jan 28, 2011, at 9:48 , Patrick Ohly wrote:
> The difference is that the older lib decoded base64 encoding and stored > the decoded data in the field. The new lib doesn't, and then the encoder > applies base64 encoding again to the already encoded data. > > This changed in the very latest commit: > > TMimeDirProfileHandler::parseProperty(): > > 3529d3cb (Lukas Zeller 2011-01-25 14:45:16 +0100 3906) if > (encoding==enc_quoted_printable) > 3529d3cb (Lukas Zeller 2011-01-25 14:45:16 +0100 3907) > storeUnprocessed = false; // QP will be decoded, so param must not be stored > 3529d3cb (Lukas Zeller 2011-01-25 14:45:16 +0100 3908) else > 3529d3cb (Lukas Zeller 2011-01-25 14:45:16 +0100 3909) encoding = > enc_none; // other encodings will not be processed > > commit 3529d3cb0929aed94b2568c0e74f3ec746b7be7a > Author: Lukas Zeller <l...@plan44.ch> > Date: Tue Jan 25 14:45:16 2011 +0100 > > engine: implemented "unprocessed" wildcard properties to allow handling > unknown extensions (like X-xxxx properies > > Lukas, should that code above perhaps be conditional on "current > property is 'unprocessed' wildcard"? Right now it applies to all > properties, including PHOTO, and thus skips the decoding in > decodeValue(). Oh, that was a bad one :-( Thanks for analyzing. Of course you are right. This totally ruined parsing of B64 encoded properties. I'll post a patch ASAP! Best Regards, Lukas Lukas Zeller, plan44.ch l...@plan44.ch - www.plan44.ch _______________________________________________ os-libsynthesis mailing list os-libsynthesis@synthesis.ch http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
