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.

Reply via email to