Hi, I don't know how to set up a combination of the latest AOLserver, using the nsd8x Interpreter, and a Postgres 7.2 database, that allows me to safely work with a charset of iso8859-1. Please don't throw stones, I know this has been discussed very often ;-)
How to do it? The problems I run into during my own tests and the problems that other people have (I read through some threads on various boards) are: A. Using the latest server "out of the box", working with most European characters will almost always fail using the typical string and regexp functions that internally use utf-8 ... _IF_ you are returning (in http- header or meta-tags) a charset of e.g. iso8859-1 (you have to know what comes from forms/submits; you try to return "umlauts" or any language depending chars and tell the browser of it). B. I got the tip of using an undocumented parameter in the config file, that maps the iso8859-1 charset to ".adp" files (last year on this list). But this does not guarantee that all characters that _leave_ an adp will be in iso8859-1 encoding (e.g. if I use combinations of "ns_adp_parse -file" (where strings from the DB are regexped and stringed and whatever) and return the string with "ns_return"). At least if all what comes in goes iso-ed to the DB, you could do a workaround and translate all outgoing chars to "{" html code. (There was an example of a ns_adp_puts function that does this given by Harray Moreau on the list)... If you "escape" all the characters that way, I assume, you would not no longer have to return a charset header or charset-meta-tag. C. The uncool way: Using "charset=utf-8" outgoing, then also expecting it incoming. A special character should come in as unicode and tcl should treat it this way. The database must be installed with unicode-encoding. You will run into performace problems and/or, maybe, some unresolved topics of Postgres unicode-implementation as well. I have not tried this yet, I merely assume this would work. What's your opinion on that? D. Using an AD-patched version of AOLserver. The Problem: It's an older version of the server, will it be kept up to date in the future? (Of course, there's a large user base running it) E. I did not try --enable-recode and setting up a charset table for utf8 -> latin1 and latin1 -> utf8 for Postgres. Maybe this would work if you can guarantee all charsets coming from AOLserver are coming as utf8 or iso8859x. Maybe, don't know. I tried putting "SET ENCODING TO 'UNICODE'" resp. "LATIN1" in front of every SQL statement in my test api (and took into account that it may make a difference if you are SELECTing or INSERTing) for telling the Postgres server that the client uses unicode or latin with and without the undocumented feature of (B). This only lead to error messages noticing me of failed encoding translations. Every insert _always_ was logged with german special characters (umlauts) and never as unicode characters (don't know if this is correct). Will AOLserver 4 come with I18N support that solves all the problems and what to do if you need a solution here and now? Solution B? C? Thanks for reading through this one... Bernd.
