ChaosKCW wrote: > > > > There's an Oracle environment variable that appears to make a > > difference: NLS_CHARSET, perhaps - it's been a while since I've had to > > deal with Oracle, and I'm not looking for another adventure into > > Oracle's hideous documentation to find out. > > That is an EVIL setting which should not be used. The NLS_CHARSET > environment variable causes so many headaches its not worth playing > with it at all.
Well, at this very point in time I don't remember the preferred way of getting Oracle, the client libraries and the database adapter to agree on the character encoding used for communicating data between applications and the database system. Nevertheless, what you need to do is to make sure that you know which encoding is used so that if you either get plain strings (ie. not Unicode objects) out of the database, or if you need to write plain strings to the database, you can provide the encoding to the unicode built-in function or to the decode/encode methods; this is much better than just stripping out characters that can't be represented by ASCII. Anyway, despite my objections to digging through Oracle documentation, I found the following useful documents: the "Globalization Support" index [1], an FAQ about NLS_LANG [2], and a white paper about Unicode support in Oracle [3]. It may well be the case that NLS_LANG might help you do what you want, but since the database systems I have installed (PostgreSQL, sqlite3) seem to "do Unicode" without such horsing around, I'm not really able to offer much more advice on this subject. Paul [1] http://www.oracle.com/technology/tech/globalization/index.html [2] http://www.oracle.com/technology/tech/globalization/htdocs/nls_lang faq.htm [3] http://www.oracle.com/technology/tech/globalization/pdf/TWP_AppDev_Unicode_10gR2.pdf -- http://mail.python.org/mailman/listinfo/python-list
