(bringing this back on the list...) Hi Shan, It appears that the steps you outlined have solved my issue(s) too. Thanks, Andy On Tue, 2004-02-03 at 16:19, Shan Duncan wrote:
Hi,
I just went through the exact same issue except it was from ZPT.
First check the version of python you are runniing zope.
Second check to see what the default encoding that version of python is using:
python>import sys python>sys.getdefaultencoding() python> 'ascii'
The version of python I was using to run zope returned ascii as the default.
Doing a quick check via google I found this link:
http://diveintopython.org/xml_processing/unicode.html
and added a file called sitecustomize.py to lib/site-packages:
-----------------------------------------------------------
# sitecustomize.py # this file can be anywhere in your Python path, # but it usually goes in ${pythondir}/lib/site-packages/
import sys sys.setdefaultencoding('iso-8859-1') -----------------------------------------------------------
(I used iso-8859-1 because I am mainly supporting western european languages. There is no reason why you could not use another encoding).
and restart zope so python uses your new default encoding and you should be ok. This at least is my understanding of the quick and easy fix. You can go with other methods such as localizer but that might be more work for now. The plone site at plone.org has a discussion of unicode too.
I have had folks from Mexico save and upload information via a forulator form to and from a mysql database today without any problems so far.
Good luck!
Cheers,
-Shan
On Wednesday 04 February 2004 15:18, Andrew Altepeter wrote:
(bringing this back on the list...)
Hi Shan,
It appears that the steps you outlined have solved my issue(s) too.
Youve probably swapped your original problems for a set of different ones. This does make some things easier so I understand the temptation to use it, but it is not a supported configuration for Zope or python :-(
When the form is submitted with these unicode characters in it, my script raises a UnicodeError when ZMySQLDA apparrently attempts to change the encoding to ascii.
add a :utf8:ustring marshalling tag on the end of your field, and your variable will hold a unicode object. unicode objects have a .encode() method, which will be useful if your database adapter needs an 8-bit string. -- Toby Dickenson
Hi Toby,
On Wednesday 04 February 2004 15:18, Andrew Altepeter wrote:
(bringing this back on the list...)
Hi Shan,
It appears that the steps you outlined have solved my issue(s) too.
You've probably swapped your original problems for a set of different ones.
I had a feeling that this wasn't an 'approved' way to go... What kinds of problems?
This does make some things easier so I understand the temptation to use it, but it is not a supported configuration for Zope or python :-(
Thanks for the warning.
When the form is submitted with these unicode characters in it, my script raises a UnicodeError when ZMySQLDA apparrently attempts to change the encoding to ascii.
add a :utf8:ustring marshalling tag on the end of your field, and your variable will hold a unicode object.
unicode objects have a .encode() method, which will be useful if your database adapter needs an 8-bit string.
I think zmysqlda needs an 8-bit string? It seems to, because zmysqlda.db.db (which is a mysql-python db object) raises the unicode error. The biggest problem with unicode I'm having are microsoft's m-dashes and curly-quotes. So what you're saying is that if the input fields are :utf8:ustring, then prior to saving them to database, if I did: field.encode('latin-1') Everything will work well? Or, will these unicode characters just have 8 bits removed? Thanks so much for the advice; I'll look into changing how my input fields are rendered. Andy
On Wednesday 04 February 2004 16:16, Andrew Altepeter wrote:
field.encode('latin-1')
Everything will work well?
You will get an exception at that point if someone has typed a non-latin1 string into your form. maybe thats what you want; handle the exception and report an error.
Or, will these unicode characters just have 8 bits removed?
field.encode('latin-1','replace') will change characters that dont fit in latin-1 into the ? character. -- Toby Dickenson
Thanks for the tip. In my case I had a problem with ZPT returning the error. I used iso-8859-1 as the default as that is the character set for the version of MySQL server I am running. As I understand it mysql 4.1 will have unicode support. Cheers, -Shan On Wed, 4 Feb 2004, Toby Dickenson wrote:
On Wednesday 04 February 2004 15:18, Andrew Altepeter wrote:
(bringing this back on the list...)
Hi Shan,
It appears that the steps you outlined have solved my issue(s) too.
Youve probably swapped your original problems for a set of different ones. This does make some things easier so I understand the temptation to use it, but it is not a supported configuration for Zope or python :-(
When the form is submitted with these unicode characters in it, my script raises a UnicodeError when ZMySQLDA apparrently attempts to change the encoding to ascii.
add a :utf8:ustring marshalling tag on the end of your field, and your variable will hold a unicode object.
unicode objects have a .encode() method, which will be useful if your database adapter needs an 8-bit string.
participants (3)
-
Andrew Altepeter -
Shan Duncan -
Toby Dickenson