[pmwiki-users] Headers are not sending charset !

Patrick R. Michaud pmichaud at pobox.com
Mon Mar 12 09:11:28 CDT 2007

On Mon, Mar 12, 2007 at 03:59:57PM +0200, Athan wrote:
> "Patrick R. Michaud" <pmichaud at pobox.com> wrote in message 
> news:20070312132715.GC29823 at host.pmichaud.com...
> > A second approach might be for PmWiki to treat xlpage-i18n as though
> > it is a simple charset declration whenever an associated xlpage-*
> > script doesn't exist.  Thus, if someone sets 'xlpage-i18n' to
> > 'euc-jp', and there's no 'xlpage-euc-jp.php' file in the scripts/
> > directory, then PmWiki defaults to setting the charset
> > declarations in $HTTPHeaders and $HTMLHeaders.  But I'm not
> > sure I like this solution...
> With all respect to your opinion, what's the problem with such a solution?
> If I understood, a min requirement for each xlpage-xxxx.php is to declare 
> http and html headers. Then why don't do that in the core before including 
> xlpage-xxxx.php, if one exists?

I answered that in my previous message, where I wrote:

    ...because in general simply setting the charset= parameter of the
    html/http headers isn't sufficient to get things to work properly.
    In addition to setting the headers, PmWiki often needs to re-evaluate
    the value of $pagename in the context of the new character set, as well
    as potentially change the settings for a few other variables
    (e.g., $KeepToken) to avoid collisions between pagenames and PmWiki's
    internal string markers.

If simply setting http and html headers was generally reliable enough
to make things work, then I'd probably do this.  But since any change
to the character set almost always requires looking at these other
issues, I think it's best to say that we always build a specific
xlpage-* script for each individual character set.

> PS: Still hope you consider a utf8-only core...

See the message I just posted about utf8 support.  :-)


More information about the pmwiki-users mailing list