[phpxmlrpc] entity changes

Andres Salomon dilinger at voxel.net
Fri May 30 12:00:55 BST 2003


There's a function in xmlrpc.inc called xmlrpc_html_entity_xlate(). 
htmlentities should still be called, and the data returned from that
should be run through xmlrpc_html_entity_xlate().  This will convert
from your standard xhtml entites (É) to numerical entities
(É).


On Fri, 2003-05-30 at 09:18, Jeff Barr wrote:
> Ok, that makes sense. I did some digging and it looks like the offending
> code is:
> 
>                         case $xmlrpcString:
>                                  $rs.="<${typ}>" . htmlentities($val).
> "</${typ}>";
>                                  break;
> 
> In xmlrpcval::serializeData. Do I simply need to write a function to replace
> htmlentities? It would basically do what htmlspecialchars does,
> and then translate everything that's non-ASCII into numeric entities. This
> should not be too hard to do with strtr.
> 
> Is this correct?
> 
> Jeff;
> 
> ----- Original Message ----- 
> From: "Andres Salomon" <dilinger at voxel.net>
> To: "Jeff Barr" <jeff at vertexdev.com>
> Cc: <phpxmlrpc at usefulinc.com>
> Sent: Thursday, May 29, 2003 9:01 AM
> Subject: Re: [phpxmlrpc] entity changes
> 
> 
> > Sorry, the stuff in CVS needs more work wrt entities; I just haven't had
> > time lately.  The server should be returning numerical entities instead
> > of XHTML entities, which is on my TODO list.
> >
> >
> >
> > On Thu, 2003-05-29 at 02:23, Jeff Barr wrote:
> > > I am testing out this code and there are still some issues. My server
> > > is trying to return a string containing the folllowing encoded
> characters:
> > >
> > >     &Atilde;
> > >     &cedil;
> > >     &oslash;
> > >
> > > If any of these characters are present in the returned string then
> > > the client (also using PHP XML-RPC) dies like this:
> > >
> > >     XML error: undefined entity at line 10
> > >
> > > The characters appear to be properly encoded in the XML. Here's
> > > some debug output from the client:
> > >
> > >     &lt;value&gt;&lt;string&gt;B&amp;Atilde;&amp;cedil;rsen
> > > Online&lt;/string&gt;&lt;/value&gt;
> > >
> > > As an experiment, I stripped these characters out on the client
> > > side in xmlrpcmsg::parseResponse and I didn't get the undefined
> > > entity error.
> > >
> > > I believe that the server should insert entity declarations for
> > > these characters. Is this correct?
> > >
> > > Jeff;
> > >
> > > ----- Original Message ----- 
> > > From: "Andres Salomon" <dilinger at voxel.net>
> > > To: <phpxmlrpc at usefulinc.com>
> > > Sent: Thursday, April 17, 2003 2:11 AM
> > > Subject: [phpxmlrpc] entity changes
> > >
> > >
> > > > Folks, I just committed some changes that address some longstanding
> issues
> > > > w/ this xmlrpc implementation, and multibyte characters from various
> > > > charsets.  I'll be testing these changes some more this week, but if
> > > > anyone has dealt w/ entity issues in xml or xmlrpc, or has experience
> w/
> > > > another xmlrpc library, please look over the changes (see the
> ChangeLog
> > > > for additional details).  The things that need addressing are:
> > > > a) does xmlrpcresp need to be fixed in a similar way?
> > > > b) should entity translation be done on the server or client?  Are
> xmlrpc
> > > > servers expected to know how to handle things like &eacute; (or even
> > > > &#233;)?
> > > > c) are there any entities that might be missing?
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > phpxmlrpc mailing list
> > > > phpxmlrpc at usefulinc.com
> > > > http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
> > > >
> > >
> > >
> > > _______________________________________________
> > > phpxmlrpc mailing list
> > > phpxmlrpc at usefulinc.com
> > > http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
> >
> >
> > _______________________________________________
> > phpxmlrpc mailing list
> > phpxmlrpc at usefulinc.com
> > http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
> >
> 




More information about the phpxmlrpc mailing list