> [2] This line change from 'iso-8859-1' to 'utf-8'
> lib/python/App/dtml/manage_page_header.dtml
> <dtml-call "REQUEST.set('management_page_charset','iso-8859-1')">

Bad news. That will cause all management form submissions to encode strings in 
utf8. 99% of the methods to which the strings are being submitted will not be 
expecting this, and will corrupt characters whose unicode code point is >127.

If you have a ZMI form that *is* expecting this then you need to make some 
other changes to avoid breakage. Essentially just adding :utf8: marshalling 
tags, possibly some :strings: and :ustring: too. 

(yes, this sucks. The problem is that browsers dont specify the character 
encoding used in form submissions. At some point we need to discuss the way 
forward on this issue....)

> [1] These 3 filses (total 3 line) change
>    from "encode('latin1')" to "encode('utf-8')"
> $find . -name '*.py' -exec grep -l 'encode.*latin1' {} \;
> ./lib/python/ZPublisher/Converters.py
> ./lib/python/ZPublisher/HTTPRequest.py
> ./lib/python/ZPublisher/HTTPResponse.py

Even more bad news. Suppose a dtml page it not yet prepared to handle unicode 
(because it hasnt had the changes described above) but it 'accidentally' 
encounters a unicode attribute. This happens often in the ZMI when objects 
have a unicode 'title', because many products render the title attribute of 
*other* objects. We cant force the response to utf8 because this will cause 
the same breakage described above.

For more details see:


> But I have not enough test.

obviously. ;-)

> I want mechanism to change encoding dinamically.

the manage_properties page that Arnar Lundesgaard has been working with is a 
good example. It switches between latin-1 and utf-8 automatically depending 
on whether any unicode properties have been defined. (to support *really* old 
browsers that dont understand utf8)

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope )

Reply via email to