+---------- 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.
