RE: [INTERNALS-WIN] Question about using UTF-8 encoding for server variables used by PHP

The actualy problem is this:

If url contains non-ascii characters, e.g. http://mysite.com/2009/10/русские-символ, then this URL results in 404 in WordPress. WordPress uses REQUEST_URI server variable to get the originally requested URL. Over HTTP the non-english characters come as URL encoded, but IIS internally converts them to unicode. Then FastCGI module converts it back to ANSI before passing them to PHP.

It looks like the change with converting the server variable to UTF-8 is very risky. Other alternative we are considering is to set the REQUEST_URI to contain the URL string as originally requested by the client (preserving the original encoding). Apparently this is what Apache does.

> -----Original Message-----
> From: Pierre Joye [mailto:[email protected]]
> Sent: Friday, January 08, 2010 3:20 PM
> To: Ruslan Yakushev
> Cc: [email protected]
> Subject: Re: [INTERNALS-WIN] Question about using UTF-8 encoding for
> server variables used by PHP
> 
> hi,
> 
> On Fri, Jan 8, 2010 at 11:27 PM, Ruslan Yakushev
> <[email protected]> wrote:
> 
> > Because we changed PATH_TRANSLATED which is used as filename in PHP
> and is passed to windows file system APIs which don't handle UTF-8, we
> started getting 404 for Russian filenames on systems with Russian
> codepage which is a regression. Can you please advise us as to which
> server variables are safe to change to UTF8?
> 
> None of the PATH, as it will have the same issue that the one you
> describe here.
> 
> As we have discussed in the past, UTF-8 will be possible once PHP does
> support widechar API internally (not before php next major version, be
> 5.4 or 6).
> 
> However I'm not sure to understand what is the problem exactly. What
> is the "title"? A filename? Which encoding is used in the 1st place?
> 
> Cheers,
> --
> Pierre
> 
> http://blog.thepimp.net | http://www.libgd.org