R: R: R: [phpxmlrpc-devel] proper data encoding in string value

[Gaetano G. <giu...@se...>]

...
>=20
> 	you're probably right. my patch works well for me, but=20
> if someone add
> functionality you mentioned, i'll be glad. :)
> [ciach]
...

Ok, here's some preliminary code.

Rather than fixing xmlrpcs.inc I preferred to extend the server class, =
overriding base functions.

There are a lot more changes in there other than the char encoding =
stuff, feel free to keep them or rip them off (most of these I submitted =
as patches to sourceforge already):
- ability to block xmlrpc-server to respond to non-https request
- ability to disable all system.xxx functions
- some smarter checking for producing valid comments in xml returned to =
client

About encoding: now the server can
- decide which encodings are accepted. Default: iso-8859-1 and utf-8 =
only
- decide the encoding used for the response.
  Specifically it can use:
  + no encoding specification at all
  + always the same fixed encoding
  + the same encoding as used by the current request
  + the same encoding as per the $xmlrpc_defencoding global variable

Note that setting a specified encoding does actually NOT (trans)encode =
the outgoing message. It only adds a charset-encoding declaration in =
http and xml headers.
In other words, if your server functions do return accented chars and =
the server response-encoding is set to utf-8, the client is likely to =
get some garbled data.

To achieve this extra result, i.e. automatic conversion of the server =
output to the desired encoding, the serialize methods in xmlrpc have to =
be fixed (adding maybe a call to mb_convert_encoding after having =
serialized the whole msg ??? assuming that the originating encoding used =
to set xmrpc values is known).

One more thing to do would be to move the guess_charset_encoding() =
function into xmlrpc.inc, so that it can be used by the client too. This =
would allow it to cope with server responses given in different =
encodings than the request was sent out with, much as the server does.

The new xmlrpc error constat should be moved to xmlrpc.inc, too.

Phew, that was a long mail.
If you're still reading past this point, PLEASE give this cod a try, or =
at least tell me if You think I'm heading down a senseless path. I'm not =
too confident in my ereg skills, and trying to understand all the =
implications of intermingled UNICODE, HTTP, XML and RPC specs is =
somewhat daunting.

Bye, gaetano