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

[K Suominen]

On Fri, 25 Feb 2005 15:42:32 +0100, Albert Holm <albert at cdr.se> wrote:
> On Thu, 24 Feb 2005 17:29:10 -0800, Matthew Mullenweg <m at mullenweg.com>
> wrote:
> 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.

I will definitely test with this tonight, thanks!

> 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.

It is not at all given that there is just one right thing here.

I have existing content in ISO 8859-1 mixed in with content from the
blog.  It is not possible (or desirable) to convert all that content
to UTF-8, as it is used in other places than the blog as well.

As long as WordPress supports user-selectable charset (and I really
hope it always will) we should fix things in ways that work with that
support.

Since we already produce .htaccess, we could simply output the
appropriate AddDefaultCharset statement there.  We could also call
ini_set() to make sure PHP has the right idea.  I can look into the
code this weekend and produce a patch.

The charset selection feature is really dear to me and I'm not afraid
to volunteer my time in order to have it fully supported in WordPress.

Regards,
+ Kim