-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 First, cool down for a moment. Second, I discussed all those issues with my special friend in some Launchpad ticket years ago (+ a huge amount of private discussions). I can not recall all details but at the time of the integration of the Zope 3 ZPT engine the unicode resolver approach was the best thinkable solution for dealing all possible edgecase where encoding issues may pop *for the sake of backwards compatibility* and with all possible combinations where encodings have to be considered (including stuff like the management_page_charset property). The implementation is now working for years - so it can't be that bad. If you have a better implementation you should be able to override the utility or to fix the code directly. I won't comment after years on the details below (check Launchpad for the related ticket). Andreas Chris Withers wrote:
Hi All,
It's been a a while since I had a good rant on a Zope list, but this really takes the biscuit.
Andreas, what on *earth* were you thinking with PreferredCharsetResolver?!
I like the idea of IUnicodeEncodingConflictResolver, but PreferredCharsetResolver is in the realms of totally batshit crazy.
Why? well, because what *on earth* have the character sets accepted by the user agent got to do with how strings are encoded in *my database*?!
Nevermind the logic holes of the following:
- reverting to management_page_charset *only* if there's no REQUEST (there's always a REQUEST, this is Zope 2, the world collapses if there isn't!)
- returning the original text if the bizarre dance fails, violating the contract of IUnicodeEncodingConflictResolver to *return unicode*
How about the *insane performance overhead* of doing two utility lookups *and* iterating over a load of encodings trying to find one that works for *every single string substituition* done by a ZPT?!
Why has no-one noticed this? Well, my guess is because when browsers are explicitly supplying headers, as quite a few do (IE and Safari excepted, who are legitimately going "we can handle anything you can throw at us"), this moronic piece of code happily loops through them all, and no doubt gets a hit on either utf-8 or latin-1, or, if you're really lucky, ascii.
To boot, when things go wrong, nobody suspects this miserable little turd because it's hides itself nicely by just returning the original text, leaving the bemused reader to wonder why some UA's fail and some succeed, pointing the finger in totally the wrong direction (hence Charlie's hacked up getPreferredCharsets and poor Vlad's desperate attempts).
Thankfully, I guess I can register an override that doesn't bark at the moon and froth at the mouth... Here, have an invoice for the hours of my life you've needlessly wasted...
Faaaaaaaaaaaaarq,
Chris ;-)
- -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope & Plone D-72070 Tübingen | Produce & Publish www.zopyx.com | www.produce-and-publish.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJMmRMqAAoJEADcfz7u4AZjThgLvjIWRhiVWoV/0IG7qadEliG0 Dk1+v+hu3ocu0DURn9XK5nGrHkkR+cFIjYdyjArDfXTqoNXWPii90QbtypK7Lce8 PD2rPp+fnwyMSne9iz9s/LtYYrDO/gbxWx9robjyjGmvICthKZD/qZk3cM47SSzq rhZLRV+r6GwVemn8sQEQ/y3gXKMgP7txz/Co1reWdWgrRH2HX4qpzvKHVLykXIrT lx4D9X0UfxGO+64p7MCEOgg41W3EzNM3qIEGp4PUTTwjcp/Use+AP5kS+Q6vQEWV n4c3RdaIX35EMNjVaunh0SMj+75rizMTarkGJ9e5lxekQLxqrveTiKqgGWtManD4 fjCSXpaobvy1Ym02CSLSLmSA4Y8ETTvdM87covKBvXHfaDyn5zxZaCmJ66L7Y+1i OwnbtFIke4tLFGhsEQDcbSBQDMD6TNuA1h/SQJ5AXAT3kSBPPvhWS/C8tWvoEdft dhzLEvXmpqMyA/4EgrMh6zP5fuGGkuM= =WUsF -----END PGP SIGNATURE-----