Comments (11)
It is most likely because you are not telling correctly to the xmlrpc library what character encoding your text is using.
I assume that you are in charge of the server, and that the string comes from a database or some other internal processing.
If the string is encoded as UTF-8, then you need to set
$xmlrpc_internalencoding='UTF8';
as documented here: http://gggeek.github.io/phpxmlrpc/doc-2/ch08s02.html#id937475
from phpxmlrpc.
ps: the online debugger has the 'Show debug info' option which can be used to see all details of the request and response received. This is useful when troubleshooting character encoding problems
from phpxmlrpc.
pps: if the error you mention is different from what I assume, e.g. the data wit wrong encoding comes from the client, or you are in charge of the client and not the server, do not hesitate to come back with more info
from phpxmlrpc.
Thanks for the reply. We had actually set this value as a troubleshooting attempt but it did not affect the output.
$xmlrpc_internalencoding='UTF8';
Execution of method examples.echo on server http://phpxmlrpc.sourceforge.net/server.php ...
Debug info:
---SENDING---
POST /server.php HTTP/1.0
User-Agent: XML-RPC for PHP 3.0.0
Host: phpxmlrpc.sourceforge.net
Accept-Charset: UTF-8,ISO-8859-1,US-ASCII
Content-Type: text/xml
Content-Length: 163
HEADER: Via: gggeek.altervista.org (PHP)
HEADER: Accept-Charset: UTF-8,ISO-8859-1,US-ASCII
HEADER: Host: phpxmlrpc.sourceforge.net
HEADER: User-Agent: gggeek.altervista.org/199.27.128.200 (compatible; MSIE 7.0;)
HEADER: Content-Length: 163
HEADER: Content-Type: text/xml
HEADER: X-Forwarded-For: 199.27.128.200, 176.9.36.157
HEADER: X-Remote-Addr: 176.9.36.157
HEADER: X-Varnish: 1385841160
---END---
---PARSED---
xmlrpcval::__set_state(array(
'me' =>
array (
'struct' =>
array (
'faultCode' =>
xmlrpcval::__set_state(array(
'me' =>
array (
'int' => 109,
),
'mytype' => 1,
'_php_class' => NULL,
)),
'faultString' =>
xmlrpcval::__set_state(array(
'me' =>
array (
'string' => 'XML error: Invalid character at line 4, column 40',
),
'mytype' => 1,
'_php_class' => NULL,
)),
),
),
'mytype' => 3,
'_php_class' => NULL,
))
---END---
XMLRPC call FAILED!
Fault code: [109] Reason: 'XML error: Invalid character at line 4, column 40'
09/Apr/2015:19:34:12
from phpxmlrpc.
mmm, it seems like the debugger still has some problems properly coping with character sets (in this case: latin-1 characters, not utf-8 ones).
I just pushed a fix for this to the php53 branch (current master).
I can backport it to the 3.0 branch, but there are a couple of things I want to get fixed properly, so it will take a little time. If you want, in the meantime I can update the public debugger for you to test.
About your specific use case: apart from the debugger not working, what exact setup and symptoms do you have?
- are you in control of both server side and client side?
- what character sets are used at all steps of the chain?
A known limitation of the library is that, server-side, if latin-1 characters are received, and the charset declaration is in the http header bot not the xml prologue, parsing will fail.
This could be either better documented, or properly fixed, but I fear that it might slow down the code a bit...
from phpxmlrpc.
Hi,
I'm pretty sure we fixed the problem on our end by adding a layer just
before the request is posted to the library as follows:
$data = $this->file_get_contents_utf8('php://input');
...
$xmlrpc->service($data);
...
//Added to prevent incorrect encoding
function file_get_contents_utf8($fn) {
$content = file_get_contents($fn);
return mb_convert_encoding($content, 'UTF-8',
mb_detect_encoding($content, 'UTF-8, ISO-8859-1', true));
}
The original issue arose from our client, and they only provided to us the
XML request body, which starts like this:
NCC Guttermann GmbH",1,"B2B PC","Wolbecker Windmühle
55","","Münster","48167","02506/9320-0","02506/9320-20","
https://www.nccms.de","","DE","de
They were likely not setting the Content-type header correctly and/or the
XML prologue when posting to the service as you point out, so the service
had to detect the encoding, which it did as ISO-8859-1. However, having
only the body of the request (without headers) makes it difficult to
reproduce what the client was actually doing.
It appears that both our customer and the debugger have the same issue: not
setting the XML prologue and the Content-type header to include the
charset as in Content-Type: text/xml; charset=utf-8 when posting to the
XMLRPC back end.
By the way, thank you so much for the prompt attention. We were very
surprised to hear back so quickly and succinctly.
Michael Fatica
Principal
Fatica Consulting L.L.C.
303-325-5912
www.fatica.net
On Fri, Apr 10, 2015 at 5:11 AM, Gaetano Giunta [email protected]
wrote:
mmm, it seems like the debugger still has some problems properly coping
with character sets (in this case: latin-1 characters).I just pushed a fix for this to the php53 branch (current master).
I can backport it to the the 3.0 branch, but there are a couple of things
I want to get fixed properly, so it will take a little time. If you want,
in the meantime I can update the public debugger for you to test.About your specific use case: apart from the debugger not working, what
exact setup and symptoms do you have?
- are you in control of both server side and client side?
- what character sets are used at all steps of the chain?
A known limitation of the library is that, server-side, if latin-1
characters are received, and the charset declaration is in the http header
bot not the xml prologue, parsing will fail.
This could be either better documented, or properly fixed, but I fear that
it might slow down the code a bit...Reply to this email directly or view it on GitHub
#24 (comment).
from phpxmlrpc.
You are welcome.
Indeed, it seems that the debugger was doing exactly the same as your client. Not sure if we can call it good luck or bad luck :-)
It definitely is a weak spot in the library, even though in today's utf8-oriented world it is probably a rare occurrence.
For the nitty gritty details: since version 5, the php library used for xml parsing is stupid enough to
- choke on latin-1 characters unless there is a charset declaration in the xml prologue
- disallow the coder to tell it that the xml is actually latin-1 instead of utf8
(it was actually better in the dark ages of php4, go figure...) That's why the lib can not cope with latin-1 characters when the charset is properly declared in the http headers
I will work on a "proper" fix for the long term, doing either something similar to what you have done, or injecting the charset declaration in the xml prologue if it is only found in the http headers.
from phpxmlrpc.
ps: i renamed the issue with a title which better fits results of the investigation
from phpxmlrpc.
Update: a fix has been developed and applied so far only to the php53 branch, with tests.
Unfortunately it seems that the new code fails on HHVM because it hits an incompatibility in HHVM itself: facebook/hhvm#4837
I will backport the fix to 3.0 branch and document this as known bug
from phpxmlrpc.
Fixed in release 3.0.1
from phpxmlrpc.
Note: you will most likely have to remove your added workaround if upgrading to 3.0.1 and later
from phpxmlrpc.
Related Issues (20)
- deprecated on PHP 8.1.7: Headers::offsetExists($offset) should either be compatible with ArrayAccess::offsetExists HOT 2
- Separate error codes for "invalid_return" HOT 12
- Support <NIL/> extension - or at least don't crash HOT 4
- PHP 8.1 deprecated strftime and gmstrftime HOT 1
- Remove warnings in PHP 8.1 HOT 8
- xmlrpc_encode_request HOT 3
- 1 HOT 1
- demo install HOT 11
- Legacy layer load order incorrect HOT 2
- Is it possible to disable autpomatic base64 decoding? HOT 6
- Struct does not work HOT 3
- Uncaught Error: Call to a member function serialize() on string in /vendor/phpxmlrpc/phpxmlrpc/src/Value.php:373 HOT 1
- Cannot access protected property Server::accepted_charset_encodings in Server.php (1533) HOT 4
- Suppress xml_parse warnings in XmlParser HOT 7
- How to specify a method signature for a function that returns void? HOT 4
- Add support for php 7+ type hinting in the Wrapper class
- Response sent on Request if HttpException, status_code is false configured. HOT 1
- Nested parameters fail with [Call to a member function serialize() on string] in phpxmlrpc/src/value.php HOT 1
- PHP 8 undefined array key. HOT 2
- Class "PhpXmlRpc\Exception\PhpXmlrpcException" not found HOT 5
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from phpxmlrpc.