Description: ------------ I'm encountering the problem that the received result at the XML_RPC2 client is not properly decoded according to the encoding option value. It seems that the result which includes mufti-byte strings is still formatted with ISO-8859-1 format, not UTF-8 format. Here is the snips of the code. Server Side: <?php require_once 'XML/RPC2/Server.php'; require_once 'XML/RPC2/Server/Input/PhpInput.php'; class XMLRPC2Server { /** * remotefunction() returns the server info. * * @return array of strings. */ public static function remotefunction() { $result = array('mutibyte_str'=>'???', 'ascii_str'=>'englishtext'); return $result; } } $options = array( 'prefix' => 'test.', 'sslverify' => false, 'encoding' => 'utf-8', 'escaping' => 'markup', 'input' => new XML_RPC2_Server_Input_PhpInput(), ); $server = XML_RPC2_Server::create('XMLRPC2Server', $options); $server->handleCall(); ?> Client Side: <?php require_once 'XML/RPC2/Client.php'; $options = array( 'prefix' => 'test.', 'sslverify' => false, 'backend' => 'php', 'encoding' => 'utf-8', 'escaping' => 'markup', ); $client = XML_RPC2_Client::create('http://127.0.0.1/test/soap/xml_rpc2/pearrequest/Server.php', $options); $result = $client->remotefunction(); print_r($result) ?> Test script: --------------- <?php require_once 'XML/RPC2/Client.php'; $options = array( 'prefix' => 'test.', 'sslverify' => false, 'backend' => 'php', 'encoding' => 'utf-8', 'escaping' => 'markup', ); $client = XML_RPC2_Client::create('http://127.0.0.1/test/soap/xml_rpc2/pearrequest/Server.php', $options); $result = $client->remotefunction(); print_r($result) ?> Expected result: ---------------- Array ( [mutibyte_str] =>??? [ascii_str] => englishtext ) Actual result: -------------- Array ( [mutibyte_str] => ?ú?{?ê [ascii_str] => englishtext )

So,here's the changes since 1.1.0b2 and yesterday's release: http://tinyurl.com/8q7khlm There's nothing in there that should cause a regression like you describe - the strtolower() behaviour should affect your configuration as you've stated it, and the test case that swapped to UTF-8 was failing (and ... should never have worked as far as I can tell). So... I'm kind of stumped.

Hi Daniel, thanks for your information. The test Cade should specify muti byte characters in the reply. Because of the site's restriction?, I could not paste multi byte characters in this test case. ( actually, I put them inside, but it was swapped with character ?. Thanks for the patch.

I have checked the patch but I think this is not relevant for this issue. I think this issue is more related to Bug #18378. #12249 is similar but I assume this issue has been already fixed. Bug #18378 XMLRPC2 can't decode results when querying Trac server Bug #12249 Php Server backend does not pass encoding to response object PATCH