Some character coding error occur if 'default_charset' is set in php.ini

[nyuwec]

Installing WP to some web hosts, there is a problem if in the php.ini the 'default_charset' directive is set to anything that is different than the 'blog_charset' WP option, garbled text can will be received.

Here is a short description how to reproduce this bug:

• Set 'default_charset' directive in php.ini to 'iso-8859-2'
• Set blog charset to UTF-8 on the WP admin page/Settings
• Open a post editor and add the folowing category: "Árvíztűrő tükörfúrógép". You will receive the following text when the ajax response arrives: "Ă�rvĂ­ztĹąrĹ� tĂźkĂśrfĂşrĂłgĂŠp"

Fix:

I have put the following line to the wp-settings.php (line 570):

ini_set('default_charset',get_option('blog_charset'));

[hakre]

Thanks for reporting. Can you provide a binary dump (in hex please) of the two values you provided in the summary? Can you provide the PHP version and the OS version PHP is running on? Can you say what data your browser expects (which charset is selected in your browser to display for the two examples). That will help to find out more. I will take a look on the PHP settings description.

[hakre]

According to the ​PHP Documentation that setting changes the Content-type:-header. Set it to an empty string to prevent that. Interestingly that header is set by wordpress as well based on the blog_charset option. Maybe the header can not be overwritten? This needs further testing.

[nyuwec]

Sorry for the late response:

• This bug affects only the ajax responses.
• Server: Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2 PHP/5.2.8 (default_charset: iso-8859-1)

Here is the request header when an ajax-save (admin-ajax.php) occurs in the post editor:

Host	localhost
User-Agent	Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Accept	*/*
Accept-Language	hu,en-us;q=0.7,en;q=0.3
Accept-Encoding	gzip,deflate
Accept-Charset	ISO-8859-2,utf-8;q=0.7,*;q=0.7
Keep-Alive	300
Connection	keep-alive
Content-Type	application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With	XMLHttpRequest
Referer	http://localhost/~kolesmihaly/test/wordpress/wp-admin/post.php?action=edit&post=1
Content-Length	284
Cookie	wordpress_139eba7c194a58b05d3c48dc95f1b0eb=admin%7C1255449171%7C5866f7a18ab45eeb179a57e6b10b75bd; wordpress_test_cookie=WP+Cookie+check; wp-settings-time-1=1255276395; wordpress_logged_in_139eba7c194a58b05d3c48dc95f1b0eb=admin%7C1255449171%7Cb7ce9df71ad39a1526060cd7f7b0dae4; ja_tube_tpl=ja_tube

And here is the response header:

Date	Sun, 11 Oct 2009 15:54:18 GMT
Server	Apache/2.2.11 (Unix) mod_ssl/2.2.11 OpenSSL/0.9.8k DAV/2 PHP/5.2.8
X-Powered-By	PHP/5.2.8
Content-Length	237
Keep-Alive	timeout=5, max=100
Connection	Keep-Alive
Content-Type	text/xml;charset=iso-8859-1

As you can see the response header content-type is set to iso-8859-1 instead of utf-8, which is the default charset of this wordpress install.

[ryan]

No matter what I set default_charset to, the Content-Type header sent by admin-ajax.php is the one I see.

[hakre]

[10375]
azaozz 2009-01-18 06:40:40
Add Content-Type header to admin-ajax and press this, props UnderWordPressure, fixes #8795

[hakre]

I think that this ticket is infact a duplicate of #8795.

In case the reporter's feedback is technically correct then the patched in header line of [10375] would not be able to overwrite the default_charset directive for the header into UTF-8. That would mean that headers have already been sended (most probably).

Please activate

define ('WP_DEBUG', true);
define ('WP_DEBUG_DISPLAY', true);

to get information about warnings and get them logged. That will help you to find the problem on these certains blogs.

Since the referenced changeset was prior to the version of wordpress it was reported to have the error with, it looks like a configuration issue on certain installs. Please verify on theses installs wether or not that line of code can be properly executed.

[sergey.s.betke@…]

related - #19448. And patch - at the #19448 ticket. This trouble is still exist for 3.3rc1 WordPress version.
Changeset [10375] isn't enough, function send() changed Content-Type http header, without encoding keyword.

[SergeyBiryukov]

Closing as a duplicate of #19448.