Bart sez: > >>>> > Approach 1: > Let the CGI script check the kind of browser the user is using. Sounds ok. > >>>> > Approach 2: > Hide the characters with code 128 to 255 in your form in a hidden field. Let > the browser include this string together with the request, split the result > up, and use this as a translation table, to get your standard encoding. > > I have absolutely no idea whether this can be done. It sounds nice though, > because it would be totally independent of the kind of browser the user is > using. Ah, wishful thinking... Do you mean including them in "logical" form (i.e. é stuff) or "hardcoded" form (i.e. ‡ stuff)? I'm not sure that either would work... would the browser encode anything that wasn't typed into it directly? > >>>> > Approach 3: A pragmatic approach. I've noticed that Mac and Ansi encoding > hardly overlap: Ansi uses mainly codes from 192 and up, while the Mac sticks > mainly to codes beneath 160. In fact, codes above 218 are meaningless on the > Mac, and codes beneath 160 mean nothing in Ansi (well, they might be > considered as duplicates of the controls codes 0-31 actually). Um... what kind of Mac are you using? Mine uses all 128 8th-bit-high characters.... As for the ANSI code (I'm assuming that's just ISO-Latin-1), aren't they defined as really strange control code stuff ("reverse linefeed" and the like)? Not that that matters in this application, but I thought that something was defined for it. > Bart Lateur Don -=-=-=-Don Blaheta-=-=-=-blahedo@quincy.edu-=-=-=-dblaheta@aol.com-=-=-=- Every four seconds a woman has a baby. Our problem is to find this woman and stop her.