Re: entity changes

Andres Salomon <[email protected]>
Newsgroups gmane.comp.php.xml-rpc
Message-ID <1054306854.665.2.camel@nrop>
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 (&Eacute;) to numerical entities
(&#201;).


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" <[email protected]>
> To: "Jeff Barr" <[email protected]>
> Cc: <[email protected]>
> 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" <[email protected]>
> > > To: <[email protected]>
> > > 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
> > > > [email protected]
> > > > http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
> > > >
> > >
> > >
> > > _______________________________________________
> > > phpxmlrpc mailing list
> > > [email protected]
> > > http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
> >
> >
> > _______________________________________________
> > phpxmlrpc mailing list
> > [email protected]
> > http://lists.usefulinc.com/cgi-bin/mailman/listinfo/phpxmlrpc
> >
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.