The version of ns_write/ns_return that I wrote as a TclObj command returns binary data without altering it. I don't know if or how this relates as I haven't had any cause to work with any non-US/English stuff.
The module is at http://www.vorteon.com/download/ and the patch against aolserver 4 is at http://sourceforge.net/tracker/?atid=303152&group_id=3152&func=browse in case you are interested in looking at it. On Thursday 09 May 2002 05:23 pm, Rob Mayoff wrote: > +---------- On May 9, atfrost said: > > Tedious stuff, eh? But I'm not convinced that this isn't a bug. > > Oh, I'm sure it's a bug. I'm just saying that it's probably not > something easily solved, or something that can be solved simply by > implementing published standards. > > > As far as I can tell, the current (5.0+) versions of IE and Netscape > > submit form data using whatever encoding is being used to view the form > > submit page. At least, this has been my emperical experience - I'm not > > too sure what happens when you do something like submit Japanese > > characters from an iso-8859-1 encoded page... > > But then you have to ask whether you can rely on users having those > versions of the browsers. When I worked on this stuff some two years > ago, I suggested just doing everything in UTF-8. But Henry Minsky (in > the ArsDigita Japan office) said browsers that support UTF-8 had only > 50% penetration in Japan at the time, so we couldn't just do that. > Maybe by now the fraction is close enough to one that transmitting and > receiving only in UTF-8 is feasible. > > > Does AOLServer perform any implicit silent conversion on received form > > data? > > Through version 3.3, standard AOLserver doesn't do any "silent > conversion". However, Tcl does, in some circumstances. It depends on > what you do with the data. > > I never looked much at AOLserver 3.4, but I think they might have added > a little bit of I18N support in that version. I'm pretty sure it wasn't > as complete as what I did for ArsDigita, though. You might want to try > switching to that version. > > > It seems that there must be a way to correct the modification > > that's happening to the data, since AOLServer undoes whatever it's > > doing when it ships the data back out to the client. > > The problem is that Tcl may perform uninvertable transformations on > strings that are not in normalized UTF-8 format.