comments at the end of this mail tex
> -----Original Message----- > From: Makoto Tozawa [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 25, 2005 4:47 PM > To: Tex Texin > Cc: 'Andrei Zmievski'; [EMAIL PROTECTED]; 'PHP > Developers Mailing List' > Subject: Re: [PHP-DEV] Re: PHP Unicode support design document > > > 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 OK, I added to the bottom of http://www.xencraft.com/php/testforms.php, a display of the header info. You are quite right. Although NS changes the form content to match the encoding of the FORM's accept-charset attribute, it doesn't change the value of accept-charset that it returns to the server. I guess the way to think about it, is the FORM's accept-charset tells the user agent the encodings the server accepts. In the POST to the server, the user agent is telling the server the encodings it accepts, and it is not resending the forms' accept-charset attribute. That makes some sense, especially since the other attributes of the form are not sent to the server, only the variables. People are welcome to try other browsers and report back the accept-charset value. But I agree now, that we can't use the accept-charset value to trigger the encoding, since it doesn't necessarily represent the encoding of the data. tex -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
