Re: [cx-oracle-users] Antw: Bad conversion of a unicode value?
Brought to you by:
atuining
From: Michael S. <ms...@co...> - 2007-12-05 17:34:24
|
Anthony Tuininga schrieb: > Not everyone is going to want to switch wholesale to unicode > immediately -- the amount of pain that would cause is considerable. I > would agree that long term, that is the way to go, but some > intermediate steps should probably be taken. I am thinking that it > might work to do the following: > > Add a connection constructor parameter that specified that __all__ > strings should be returned as unicode objects, not string objects. > This parameter would default to False to get the current behavior -- > string objects returned (fixing whatever is causing the problem right > now). It would likely be reasonable to return unicode for nvarchar2 > data regardless of this setting but I'd appreciate some feedback on > that. That would be a fine thing. Always returning unicode for nvarchar2 columns is just fine for oracle >= 9i, but not always for older ones, where nvarchar could be some other encoding than one of the unicode encodings. > I've also considered some setting that would allow you to specify > unicode for certain columns but perhaps it would be better to go all > unicode or the hybrid I suggested above, and not confuse matters by > adding that capability. Thoughts? If you return unicode for all nvarchar2 columns by default the user can always force it by using, or using nvarchar2 as column type. SELECT TO_NCHAR(...) FROM ... > >> There are some pitfalls for literal SQL in the path, but i think you can write >> the interface in a way that you don't have to worry about all this stupid encoding >> conversion stuff forced upon us by Oracle, Python and other forces... > > What are you referring to about literal SQL in the path? Oracle has the nasty habit to trash literal unicode values in SQL when the database encoding is non-unicode, bind variables are fine, but literal unicode values in SQL statements is not safe in general, because they get converted to the database encoding while passing through the server side of OCI. See http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/ch7progrunicode.htm#i1006315 So maybe the autoquoting mentioned there is a good idea. Michael |