2006/8/31, Andreas Jung <[EMAIL PROTECTED]>:

--On 31. August 2006 19:28:54 +0200 Dieter Maurer <[EMAIL PROTECTED]>

> Luiz Fernando Bernardes Ribeiro wrote at 2006-8-30 14:08 -0300:
>> 2006/8/29, Andreas Jung < [EMAIL PROTECTED]>:
>> ...
>> After trying a lot of things, I found the problem is really in the
>> zpublisher realm, no matter what kind of encoding trick I use, even with
>> a python script, the output is converted to the default encoding if I
>> use any variable or dynamic value from the database.
> If you were right (which I still hope you won't) than someone
> severely misunderstood the meaning of "default".

I think he is not right.


Zope did respect the default setting when I changed the charset header in the file.

The lesson learned is: Working with two encoding charsets is very trick, and even trickier if you use the ZMI to edit files.

I had to create a simple ZPT file with the initial XML block and "inject" the rest of the xml data, including variables and database, using a tal:content pointing to a python script encoding everything to utf-8. The ZPT file was needed as simple way to change the charset header trough the ZMI.

When you change the charset trough the ZMI Zope trows an exception if it find any non-conforming character, the problem is that since the default charset is set to iso Zope reencodes my file to iso when it generates the editing form field so when I submit it back Zope raises an exception.

Considering I can't change everything to utf-8 I will have to live with it and maybe find a simpler pattern to change the charset without raising an exception (maybe the dummy tal:define?).

I hope it help others.

Thanks for your help and time,

Luiz Fernando B. Ribeiro
Zope maillist  -  Zope@zope.org
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-dev )

Reply via email to