I have a similar problem with german umlauts, here is a summary of
some tests (with umlauts instead of Chinese characters).
Aolserver version is always AOLserver/3.2+ad10.
> 1. Test PG directly. Create a table with a
> "text" field, then insert and retrieve Chinese
> characters. Make sure that works.
That works. Postgres has Multibyte enabled and the database is in
UNICODE encoding (according to encoding).
> 2. Write a simple Tcl script that retrieves rows
> ALREADY IN THE TABLE, ns_write them,
> and see if you get Chinese characters out.
Works both with nsd76 and nsd8x for me.
Writing posted values into a file: works with both.
Sending mail with ns_sendmail always works (posted values, read from
db, read from file) with both.
Reading a file from the file system with umlauts in it and storing
its text in the db: works with nsd76, fails with nsd8x.
So they only place where characters get translated wrong seems to be
on the aolserver->postgres path when using nsd8x.
> (try with nsd76 and nsd8x - 76 is much better
> for OpenACS in general because Tcl 8x has
> memory leaks associated with regexps).
Somewhere at arsdigita I read that those issues are now resolved and
everybody should use nsd8x. They will eventually stop support for
nsd76 - e.g. ns_cache only works with nsd8x.
Unfortunately there seems to be no other alternative than to use nsd76
right now if you need a non US encoding.
Is it safe to say that according to the tests above it is an issue
with the nspostgres driver?
> I know that one set of bug fixes for PG 7.0.3
> involved internationalization. I suggest
> downloading and installing that with the right
> switches, for starters.
Tried it, same troubles. (PostgreSQL 7.0.3 on i686-pc-linux-gnu,
compiled by gcc 2.95.2)
