Tex Texin wrote:
I wrote a little test php program that has 2 identical forms. You enter text
in either form and it posts and displays the hex codes for the bytes. The
first form does not set accept-charset, so it defaults to utf-8.
The second form overrides the page encoding and sets accept-charset to
windows-1252.
http://www.xencraft.com/php/testforms.php
If you use IE, since it never honors accept-charset, both forms behave the
same and displays utf-8 byte values. On Netscape, the second form converts
the characters to windows-1252, so the characters look munged, and the
codepoints show windows1252 values.
In summary, if the accept-charset is supplied on a request, and it contains
a single encoding, we should use it as the encoding of the form.
On IE you will never see it. But other browsers that are standards compliant
(netscape was very strong in this area) will.
Do you mean, when the form element has accept-charset=xxx attribute,
Netscape does:
(1) put the input characters in the request content using xxx encoding , and
(2) set xxx in the ACCEPT-CHARSET request header?
(1) seems to comply the HTML spec. But the HTML spec doesn't mandate
browsers to do (2).
Would you double check if Netscape really send ACCEPT-CHARSET=xxx on the
request?
(I don't have Netscape on my pc...)
FireFox sends the same ACCEPT-CHARSET header
("windows-1252,utf-8;q=0.7,*;q=0.7")
on the request regardless the existence of the form accept-charset
attribute.
Since browsers behave differently on the form accept-charset attribute,
I would
prefer PHP does nothing and let developers deal with it in their
applications.
Even if PHP could decode the input data correctly for Netscape,
developers have
to write a piece of code to re-decode the raw input to support other
browsers.
Makoto
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
