W3C home > Mailing lists > Public > www-international@w3.org > April to June 1996

Re: Using unicode or MBCS characters in forms

From: Erik van der Poel <erik@netscape.com>
Date: Thu, 20 Jun 1996 20:55:50 -0700
Message-Id: <31CA1D46.63DE@netscape.com>
To: Gavin Nicol <gtn@ebt.com>
Cc: JMHX.DSKPO33C@dskbgw1.itg.ti.com, www-international@w3.org
Gavin Nicol wrote:
> I use 2.01 under Unix. How do I set it?

You need 2.02 or higher. Look for "httpAcceptLanguage" in the *.ad file.
That is the X resource that you need to set. We haven't created a GUI
for this yet.

> >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.
> This "bugward combatibility" is one of the primary reasons things
> haven't changed. This and the "well it seems to work now" attitude.
> You could at least make it an option.

We want to avoid cluttering the UI with options that the average user
doesn't understand. I suppose we could put it in a config file.

> What happens if you have, on a single site, many different forms in
> many different encodings? What happens if the forms are dynamically
> generated, where you do not know a priori what the encoding of the
> form is/was?

I guess we haven't come across many cases like this.

> Then you have to rely on data sniffing, in which case it
> is not easy to distinguish EUC-KR and EUC-JP. Data sniffing would also
> be simplified if a single encoding was choosen for each language.

The fact is that more than one encoding is used for some languages. It
would be nice if we could get the servers to use fewer encodings without
affecting the client users (customers).

> I don't think so. The I18N discussions are quite old now, and are
> probably the one area where software vendors are almost uniformly
> poor.

Vendors don't necessarily respond to discussions in working groups. They
must, however, respond to customers. What I'm saying is that it seems
like we haven't had many customers request this.

> So do you recognise EUC-JP (which I believe is not in the IANA list,
> except as Extended_UNIX_Code_Fixed_Width_for_Japanese).

No, we don't recognize EUC-JP yet, but we do recognize X-EUC-JP. Also,
Extended_UNIX_Code_Fixed_Width_for_Japanese is not the same as EUC-JP.
That is the wchar_t form. What you're thinking of is

> Also, even when I send the parameter, why does the document info forms
> tell me the encoding is iso-20220-jp?

Yes, I think we have a bug in that area.

Received on Thursday, 20 June 1996 23:57:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 21 September 2016 22:37:15 UTC