Andreas Jung wrote at 2006-1-5 13:39 +0100:
>I forgot to mention a major point: compatibility.
>When a ZPT is internally stored a unicode string then content returned by
>methods called through the ZPT will be implicitly converted to unicode.
>This will definitely raise UnicodeDecodeErrors. So how to deal with this
> - allowing only unicode textual content when calling macros, PyScript etc.
> - converting non-unicode to unicode inside the TAL code using some
> encoding. The encoding could be specified as property of the called
> method (function properties) or object.
Using a site encoding would probably be the best way (as done by e.g.
Plone and Archetypes).
Most sites use in fact a fixed encoding most of the time.
At the places where a different encoding is used, it can be
employed explicitely to convert to unicode.
As pointed out in private email ("charset negociation will not work"),
the response charset has a significant impact on the charset
used in form data sent back to the server.
This may pose severe problems when the response charset is
not the same as the site encoding (for textual form data).
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -