[wp-hackers] Content-Type conflict (Mosquito #857)

[Albert Holm]

On Thu, 24 Feb 2005 17:29:10 -0800, Matthew Mullenweg <m at mullenweg.com>  
wrote:

> K Suominen wrote:
>> - readme.html (yuck, impossible to fix, please make it readme.php  
>> instead)
>
> This will always be a straight HTML file, sorry.

XHTML I hope, as it already is. With XHTML, the XML prolog is used to  
determine the charset used. W3 writes:

> In order to portably present documents with specific character
> encodings, the best approach is to ensure that the web server provides
> the correct headers. If this is not possible, a document that wants to
> set its character encoding explicitly must include both the XML
> declaration an encoding declaration and a meta http-equiv statement
> (e.g., <meta http-equiv="Content-type" content="text/html;
> charset=EUC-JP" />). In XHTML-conforming user agents, the value of the
> encoding declaration of the XML declaration takes precedence.

>> For the files in wp-admin, I guess an acceptable solution would be to
>> hard-code utf-8 as the charset (as is already done with the
>> (ignored-by-browser) <meta> tag), although it means the user could
>> input a blog title that becomes incorrect when the character set is
>> changed.
>
> What browsers are this?
>

I know Opera uses the value in HTTP first and then http-equiv if the first  
is missing. In the case of the readme that Kim links to in his next  
message, server says iso-8859-1, document http-equiv says utf-8 and Opera  
uses the one defined in the browser which default is windows-1252. Though,  
I have no document with XML prolog to play with but I guess that for XHTML  
Opera will use that.

The right thing to do ofcourse, is to make servers send out utf-8 for both  
wordpress and normal xhtml files with html file suffix, make sure the blog  
including archives is converted to utf-8 and get rid of the unneccessary  
entities.

/Albert
-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/