Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Re: font/char set question
- Date: Tue, 31 Jul 2007 04:10:30 +0900 (JST)
- From: Curt Sampson <cjs@example.com>
- Subject: Re: [tlug] Re: font/char set question
- References: <5634e9210707282051g6d4ac8b9l1ba725231bdff464@mail.gmail.com> <d8fcc0800707290802x2c9798dj411fc5400e8b8d6f@mail.gmail.com> <46AD1954.1080209@dcook.org> <d8fcc0800707291946s531f3353y8e0124d8e12cb071@mail.gmail.com> <Pine.NEB.4.64.0707301307430.28098@homeric.cynic.net> <20070730095007.c7a28cce.gstewart@bonivet.net>
On Mon, 30 Jul 2007, Godwin Stewart wrote:
On Mon, 30 Jul 2007 13:43:45 +0900 (JST), Curt Sampson <cjs@example.com> wrote:
> Every browser I've seen a) does not tell you in what encoding it's > submitting a form, and b) submits forms in the encoding of the web > page from which the form was taken.
Unless the opening <form> tag includes an accept-charset specification:
<form action=3D"whatever.php" method=3D"post" accept-charset=3D"ISO-8859-15= ">
In this case, any data submitted via this form will be in ISO-8859-15 regardless of the charset of the page it's to be found on.
I think this misses the point.
This appears to me to be no different from including the encoding as a hidden parameter, except for the following additional complexity:
1. If the browser doesn't support this, you'll probably see data posted in the (browser's opinion of) the charset of the page in which the form resides.
2. If the browser does support it, but doesn't support the encoding you specify, who knows what happens?
3. According to http://www.w3.org/TR/html4/interact/forms.html :
User agents may interpret this value as the character encoding that was used to transmit the document containing this FORM element.
Is it just me, or does this introduce a whole pile of ambiguity? What if the Content-type header says something different. What if there are multiple encodings (comma-separated) in the value?
As it happens, I discovered some "official" support for my idea from MS.From http://msdn2.microsoft.com/en-us/library/ms533061.aspx :
If ACCEPT-CHARSET is not specified, the form will be submitted in the character encoding specified for the document. If the form includes characters that fall outside the character set specified for the document, Microsoft Internet Explorer will attempt to determine an appropriate character set.
The first sentence is quite clear; the latter I interpret as, "don't generate documents with invalid character sequences."
cjs -- Curt Sampson <cjs@example.com> +81 90 7737 2974 Mobile sites and software consulting: http://www.starling-software.com
- References:
- [tlug] Re: font/char set question
- From: Jim Breen
- Re: [tlug] Re: font/char set question
- From: Josh Glover
- Re: [tlug] Re: font/char set question
- From: Darren Cook
- Re: [tlug] Re: font/char set question
- From: Josh Glover
- Re: [tlug] Re: font/char set question
- From: Curt Sampson
- Re: [tlug] Re: font/char set question
- From: Godwin Stewart
Home | Main Index | Thread Index
- Prev by Date: Re: font/char set question: keitai: non-support of stuff is a feature . . . . . . . . [tlug]
- Next by Date: Re: [tlug] Re: font/char set question
- Previous by thread: Re: [tlug] Re: font/char set question
- Next by thread: Re: [tlug] Re: font/char set question
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links