I'm using the XML-RPC library to retrieve calendar listing records from a calendar website. Both the client and the server are using the latest XML-RPC library.

Both client and server are using UTF-8 encoding all around, and I've adjusted $xmlrpc_internalencoding.

Some of the calendar entries are in Japanese, input with UTF-8 encoding, and displayed on the site with UTF-8 encoding. (See http:// www.radicalendar.org/calendar/index.php?view=month&group=imcjapan).

If I make an XMLRPC request to retrieve some Japanese entries, the library chokes and returns an "Invalid token" error. After what seems like 90 hours of debugging (checking the strings and arrays at various stages of encoding and parsing), I tracked the problem down to the default case of xmlrpc_encode_entitites()

   if ($code < 32 || $code > 159)
      $character = ("&#".strval($code).";");

If I simply comment out that code, leaving a blank default case, the XML is now valid and parses (and displays) exactly as expected. I have NOT debugged the code to the extent where I can tell exactly what character's entity reference might be the exact cause of the problem...it's all complicated by the fact that I don't read Japanese, so debugging is that much harder.

Any idea why the entity conversion is causing the XML to become invalid? Is it feasible to leave off the

There's an example page at http://dev.dadaimc.org/mod/calendar/ index.php with debugging turned on, but it'll only be valid for today (11/14/05 -0500), after which time the Japanese entry will no longer be part of the results. But I'd be happy to reproduce the problem upon request.


a.h.s. boy
spud(at)nothingness.org            "as yes is to if,love is to yes"

phpxmlrpc mailing list

Reply via email to