Re: Using unicode or MBCS characters in forms

Gavin Nicol wrote:
> Netscape Navigator could be a lot better Erik. For example, it would be
> very useful if it sent Accept-Language and Accept-Charset fields, and
> indicated the encoding of POSTed data.

We do send Accept-Language, if the user sets it.

Accept-Charset is on the list of things to consider doing. It seems a
bit wasteful. The more charsets you support, the more bandwidth you have
to use. Maybe it would be nice if the Accept-Charset header could be
sent in a compact way.

Assuming "POSTed data" refers to forms, I haven't seen very many forms
asking for an ENCTYPE of "multipart/form-data". The most common enctype
appears to be "application/x-www-form-urlencoded", the default. I
suppose we could add "; charset=xxx" to the content-type header, though
things appear to work as they are (i.e. the client sends the results
back in the same encoding as the original form). Can all servers deal
with an appended charset parameter? We would need to investigate this
before adding charset. Discussing these things on this mailing list is
all very well, but actually making changes to our software requires a
lot of care.

> As it is now, any data recieved must be sniffed to figure out what it
> is. Not very useful on a site that could get queries in both EUC-KR
> and EUC-JP... even shift-jis and EUC can be mistaken.

I suppose it would be nice if people could submit EUC-KR data even if
the original form is in EUC-JP or ISO-8859-1. Currently, people seem to
get by with results sent back in the same encoding as the form itself.
Haven't heard too many complaints about this.

> It is more than a year and a half since I pointed this out.

Right, so I guess this is not really a much demanded feature.

> BTW. Is there a list of charset values that Navigator recognises
> online anywhere.

Under Options -> Document Encoding, you will find a list of charsets.
The actual spelling of the various charset names can be found in



Follow-Ups: References: