Hi, > tells UTF-8 to use two bytes, which means you lose!). So for AOLserver 3.x > the only real way to handle this kind of thing is to use nsd76. There is > something in 3.4.2 called "encodings" in the configuration to force the > nsd8x (Tcl 8.x) UTF-8 encoder to Do The Right Thing with the aforementioned > eighth-bit-set bytes but you'd have to ask someone else precisely how that > fixes this thing.
what is TCL 7.6? :-) Hm, as far as I can tell, using the "encoding" parameter does the job, so I think it's better to use nsd8x and switch to the 4.x server later. You mentioned the EURO character: > I should also mention on a related topic that the EUR character is almost > certainly not going to work unless you choose and stick to the proper > character set... Windows has its own codepage and ISO has these fake > ISO-8859-15 and ISO-8859-0 character sets to try to handle EUR. People > editting content in MS Windows are not going to use the same EUR code as > people writing a Tcl script on Unix. Watch for that. There's a good page explaining alle the "EUR" char problems here: http://www.cs.tut.fi/~jkorpela/html/euro.html Using some kind of "ISO-to-Unicode-"#"-regsub-numeric-char-representations-ns_adp_puts"- approach ... I can submit a ALT-0128 (EUR) char typed in a Windows environment (using "accept-charset='ISO-8859-1'" within the FORM tag and HTTP-Header and META-Header (...)) to a Linux AOLserver installation, store it in Postgres (funny enough, created with standard "SQL ASCII" - encoding, psql shows me a "200" (?) value for each stored EUR character) and adp_putsing it back as "#128" char, able to view it as EUR character (VERDANA font on Windows). The "#128" character is mentioned in the document above as "undefined; if it works, consider it as an illusion" ;-) so maybe only I can see it ... The other representations are € and € (besides € or € ). Thanks, Bernd.
