You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@ws.apache.org by Dylan McNamee <dy...@exanetworks.com> on 2003/12/11 20:12:04 UTC
setEncoding broken? (Was re: accented characters in XMLRPC arguments)
At the risk of chatting with myself on a public mailing list, I hereby
revise my last email to say "it would seem that
XmlRpc.setEncoding("UTF-8") is broken in 1.2-b1".
I've tried calling this, as well as "UTF8" (since that's what Java
seems to like to call it), and regardless, it doesn't seem to affect
how the parser is configured, nor does whether I call setEncoding
before or after creating my xmlrpcClient. Regardless of any of these
permutations, I always get this exception:
java.io.IOException: Invalid character data corresponding to XML entity
√
at org.apache.xmlrpc.XmlRpcClient$Worker.execute(XmlRpcClient.java:444)
at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:163)
...
In this discussion:
http://www.mail-archive.com/rpc-dev@xml.apache.org/msg00967.htmlhttp://
www.mail-archive.com/rpc-dev@xml.apache.org/msg00967.html
The author of MinML says he's working on encoding-related stuff, but
that was in March, and nothing seems to have moved.
Does anyone else see this?
Thanks!
dylan mcnamee
Re: setEncoding broken? (Was re: accented characters in XMLRPC arguments)
Posted by Gus Mueller <gu...@mu.org>.
Dylan McNamee (dylan@exanetworks.com) wrote:
> At the risk of chatting with myself on a public mailing list, I hereby
> revise my last email to say "it would seem that
> XmlRpc.setEncoding("UTF-8") is broken in 1.2-b1".
Calling setEncoding() doesn't change the behaviour of how the data is
written out, it just changes to the "prolog" so it looks like this:
<?xml version="1.0" encoding="UTF-8" ?>
It doesn't actually let you write utf-8 data over 0xff. If you want
that you have to change the source and do a recompile.
I would love to mistaken about this however...
-gus
--
August Mueller
http://flyingmeat.com/
VoodooPad - 1st Place U.S., O'Reilly Mac OS X Innovators Contest round 2
"Christmas means carnage!" -- Ferdinand, the duck
Re: setEncoding broken? (Was re: accented characters in XMLRPC arguments)
Posted by John Wilson <tu...@wilson.co.uk>.
On 11 Dec 2003, at 19:51, Gus Mueller wrote:
> John Wilson (tug@wilson.co.uk) wrote:
>
> <snip>
>
>> At one point in time the XML-RPC spec limited the Unicode characters
>> in
>> strings to be ASCII. The Apache XML-RPC actually limited them to be
>> ISO
>> 8859/1. Some time ago that restriction was lifted but the XML-RPC code
>> has not been updated to reflect this.
>
> Would it be out of the question to create a method like
> setUseAllUnicode(boolean) or something similar, that would flag
> XMLWriter not to throw an exception on chars above 0xff? Or maybe if
> it
> saw that the encoding was set to utf-8, it wouldn't throw an exception?
>
I think that the best solution is to completely remove the restriction
that XMLWriter will not write characters with values > 0XFF. If we
support ISO 8859/1, UTF-8 and UTF-18 them we only have to use the
numeric character encodings when we are using ISO 8859/1.
It's a common misapprehension with XML that the encoding restricts the
characters that can be used. XML documents in *any* encoding can
contain *all* of the Unicode characters allowed by the XML spec.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: setEncoding broken? (Was re: accented characters in XMLRPC arguments)
Posted by Gus Mueller <gu...@mu.org>.
John Wilson (tug@wilson.co.uk) wrote:
<snip>
> At one point in time the XML-RPC spec limited the Unicode characters in
> strings to be ASCII. The Apache XML-RPC actually limited them to be ISO
> 8859/1. Some time ago that restriction was lifted but the XML-RPC code
> has not been updated to reflect this.
Would it be out of the question to create a method like
setUseAllUnicode(boolean) or something similar, that would flag
XMLWriter not to throw an exception on chars above 0xff? Or maybe if it
saw that the encoding was set to utf-8, it wouldn't throw an exception?
thanks,
-gus
>
> You are trying to send a character with a value of 8730 (the
> mathematical operator square root). Currently Apache XML-RPC won't
> support that.
>
> The encoding is irrelevant. Any encoding is capable of expressing all
> the Unicode characters.
>
> If you want to patch your code to fix this look in XMLWriter.java and
> find where it throws the exception.
>
> Change
>
> if (c < 0x20 || c > 0xff)
>
> to
>
> if (c < 0x20)
>
> This should fix your problem no matter what encoding is used.
>
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
-gus
--
August Mueller
http://flyingmeat.com/
VoodooPad - 1st Place U.S., O'Reilly Mac OS X Innovators Contest round 2
"Christmas means carnage!" -- Ferdinand, the duck
Re: setEncoding broken? (Was re: accented characters in XMLRPC arguments)
Posted by John Wilson <tu...@wilson.co.uk>.
On 11 Dec 2003, at 19:12, Dylan McNamee wrote:
> At the risk of chatting with myself on a public mailing list, I hereby
> revise my last email to say "it would seem that
> XmlRpc.setEncoding("UTF-8") is broken in 1.2-b1".
>
> I've tried calling this, as well as "UTF8" (since that's what Java
> seems to like to call it), and regardless, it doesn't seem to affect
> how the parser is configured, nor does whether I call setEncoding
> before or after creating my xmlrpcClient. Regardless of any of these
> permutations, I always get this exception:
>
> java.io.IOException: Invalid character data corresponding to XML
> entity √
> at
> org.apache.xmlrpc.XmlRpcClient$Worker.execute(XmlRpcClient.java:444)
> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:163)
>
The problem is not caused by the encoding. It's a restriction imposed
by the XML-RPC implementation which stops Unicode characters with
values . 0XFF being written.
At one point in time the XML-RPC spec limited the Unicode characters in
strings to be ASCII. The Apache XML-RPC actually limited them to be ISO
8859/1. Some time ago that restriction was lifted but the XML-RPC code
has not been updated to reflect this.
You are trying to send a character with a value of 8730 (the
mathematical operator square root). Currently Apache XML-RPC won't
support that.
The encoding is irrelevant. Any encoding is capable of expressing all
the Unicode characters.
If you want to patch your code to fix this look in XMLWriter.java and
find where it throws the exception.
Change
if (c < 0x20 || c > 0xff)
to
if (c < 0x20)
This should fix your problem no matter what encoding is used.
John Wilson
The Wilson Partnership
http://www.wilson.co.uk
Re: setEncoding broken? (Was re: accented characters in XMLRPC arguments)
Posted by remigijus <ba...@takas.lt>.
For same problem related with encoding I did some changes in the source.
But I still had no sucess for the client part whitch was used from the
applet.
I wish you sucess and will be watching what you will come with.
----- Original Message -----
From: "Dylan McNamee" <dy...@exanetworks.com>
To: <xm...@ws.apache.org>
Sent: Thursday, December 11, 2003 9:12 PM
Subject: setEncoding broken? (Was re: accented characters in XMLRPC
arguments)
> At the risk of chatting with myself on a public mailing list, I hereby
> revise my last email to say "it would seem that
> XmlRpc.setEncoding("UTF-8") is broken in 1.2-b1".
>
> I've tried calling this, as well as "UTF8" (since that's what Java
> seems to like to call it), and regardless, it doesn't seem to affect
> how the parser is configured, nor does whether I call setEncoding
> before or after creating my xmlrpcClient. Regardless of any of these
> permutations, I always get this exception:
>
> java.io.IOException: Invalid character data corresponding to XML entity
> √
> at org.apache.xmlrpc.XmlRpcClient$Worker.execute(XmlRpcClient.java:444)
> at org.apache.xmlrpc.XmlRpcClient.execute(XmlRpcClient.java:163)
> ...
>
> In this discussion:
>
> http://www.mail-archive.com/rpc-dev@xml.apache.org/msg00967.htmlhttp://
> www.mail-archive.com/rpc-dev@xml.apache.org/msg00967.html
>
> The author of MinML says he's working on encoding-related stuff, but
> that was in March, and nothing seems to have moved.
>
> Does anyone else see this?
>
> Thanks!
> dylan mcnamee
>