W3C home > Mailing lists > Public > www-international@w3.org > January to March 1997

Re: charset issues

From: <Ed_Batutis/CAM/Lotus@crd.lotus.com>
Date: Fri, 3 Jan 1997 11:33:32 -0400
To: www-international@www10.w3.org
Message-Id: <85256414.00587538.00@mta2.lotus.com>



To:       www-international@www10.w3.org
cc:
From:     Ed Batutis/CAM/Lotus @ LOTUS@MTA
Date:     01/03/97 11:33:32 AM


mduerst wrote:
>> 5) Send an Accept-Charset on the POST

>Either you mean send Accept-Charset in the FORM, or you have forgotten
something.
>
>The I18N HTML spec proposes that an attribute Accept-Charset be used
>on textual input fields of forms.
>
>The main case where this could be used is where the server sends
>out the document in a well-known encoding (for efficiency reasons),
>but expects the FORM answer to come back as UTF-8 (because a single
encoding is easier to deal with).
>
>In the long run, UTF-8 is the encoding of choice for (short) form
submissions.
>
>Regards, Martin.

Maybe I misunderstood what someone from a major vendor suggested to me
offline. I understood them to say that they were considering sending an
Accept-charset from the client to the server at POST time in the HTTP
header, essentially saying "please accept the data in this character
encoding".

Maybe I'm misunderstanding it however. It seems workable in theory, but not
compatible with any other ideas that have been discussed.

In any case, I think the best idea is to move away from
x-www-form-urlencoded as quickly as possible, patching it up with a "hidden
charset field" in the near term.

Using application/form-data seems like the best way.

What implementations support form-data?  Who has plans to do so?

=Ed Batutis
ebatutis@lotus.com
Received on Friday, 3 January 1997 11:33:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 19:16:46 GMT