Hey Brad,
Just to be sure I tested it out and manually typed in "&" into the
source for the web service. I didn't expect this to work, because even
manually typing it in still leads to each character being encoded.
In the quote you provided it says "they MUST be escaped using either
numeric character references...". UTF-8 (and all unicode) encoding
does just that :) The '&' is number 38.
On the other hand, I also tested the bracket characters < and >. Both
cause the same issue as the & character. Other brackets such as [ and
{ and ( do not cause issue.
So clearly this does have something to do with the SAXParser in
Android handling the special XML characters. I have never used
SAXParser outside of Android so I cannot say whether or not it is any
different. But I can confirm that this did not happen in 0.9 and I am
99% confident it should not be happening at all.
Thanks,
Chris
On Sep 29, 9:10 pm, "Brad Gies" <[EMAIL PROTECTED]> wrote:
> Chris,
>
> Well.... sure... UTF-8 can represent the ampersand character, but the
> ampersand is a Reserved character in XML.
>
> Below is a paragraph from the XML spec :
>
> http://www.w3.org/TR/REC-xml/
>
> "The ampersand character (&) and the left angle bracket (<) MUST NOT appear
> in their literal form, except when used as markup delimiters, or within a
> comment, a processing instruction, or a CDATA section. If they are needed
> elsewhere, they MUST be escaped using either numeric character references or
> the strings "&" and "<" respectively. The right angle bracket (>) may
> be represented using the string ">", and MUST, for compatibility, be
> escaped using either ">" or a character reference when it appears in the
> string "]]>" in content, when that string is not marking the end of a CDATA
> section."
>
> Sincerely,
>
> Brad Gies
>
> -----------------------------------------------------------------
> Brad Gies
> 27415 Greenfield Rd, # 2,
> Southfield, MI, USA
> 48076www.bgies.com www.truckerphone.comwww.EDI-Easy.com www.EDI-Simple.com
> -----------------------------------------------------------------
>
> Moderation in everything, including abstinence
>
> -----Original Message-----
> From: android-developers@googlegroups.com
>
> [mailto:[EMAIL PROTECTED] On Behalf Of Chris Cicc
> Sent: Monday, September 29, 2008 8:47 PM
> To: Android Developers
> Subject: [android-developers] Re: SAXParser reports diffeernt qName on SDK
> 0.9 from SDK 1.0
>
> Hey Brad,
> As far as I know it doesn't have to be escaped if it's unicode
> encoded. In this case, the XML is coming from a .Net Web Service,
> which is encoded in UTF-8.
>
> Also, we aren't comparing two different parsers, but rather the old
> and new version of the SAXParser with unmodified code.
>
> -chris
>
> On Sep 29, 5:30 pm, "Brad Gies" <[EMAIL PROTECTED]> wrote:
> > Shouldn't the '&' character be escaped if you are going to use it in XML?
>
> > The SAX parser if probably just following the XML spec and the other
> parser
> > wasn't :)
>
> > Sincerely,
>
> > Brad Gies
>
> > -----------------------------------------------------------------
> > Brad Gies
> > 27415 Greenfield Rd, # 2,
> > Southfield, MI, USA
> > 48076www.bgies.com www.truckerphone.comwww.EDI-Easy.com www.EDI-Simple.com
> > -----------------------------------------------------------------
>
> > Moderation in everything, including abstinence
>
> > -----Original Message-----
> > From: android-developers@googlegroups.com
>
> > [mailto:[EMAIL PROTECTED] On Behalf Of Chris Cicc
> > Sent: Monday, September 29, 2008 4:47 PM
> > To: Android Developers
> > Subject: [android-developers] Re:SAXParserreports diffeernt qName on SDK
> > 0.9 from SDK 1.0
>
> > Hey Charlie,
> > I think this should be added to the bug list. I'll do it tonight when
> > I get home if you haven't already by then...
>
> > What I don't understand is this doesn't seem to be an encoding or
> > namespace issue, since all unicode characters except '&' work fine
> > (that I've tried). As far as I know, there are no encoding schemes or
> > namespaces that single out the '&' character, though I admit my
> > experience with this is too limited to say for sure.
>
> > I'm guessing this isn't a planned change, since there should be
> > *something* written in the change log/migration guide and there is
> > nothing. So I'm all but certain it's an unintended bug...
>
> > -chris
>
> > On Sep 29, 2:51 pm, Charlie Collins <[EMAIL PROTECTED]> wrote:
> > > I have this same issue. I switched to localname as well, but it seems
> > > like as soccercheng notes, you should be able to dictate namespace and
> > > namespace-prefix features. This blows up though, anyone on the team
> > > care to elaborate - should this work with Android, and should a bug be
> > > filed, or what? (I didn't see any current bugs related to in my
> > > cursory search.)
>
> > > Also, this seems like a pretty big change from 0.9 to 1.0, maybe it
> > > should go in the migrating guide?
>
> > > On Sep 29, 10:09 am, Chris Cicc <[EMAIL PROTECTED]> wrote:
>
> > > > Hello,
> > > > I am also having a problem with theSAXParserthat I believe is
> > > > similar to your problem. I had a parser for a basic XML document that
> > > > contained only nodes and text. This was working find for weeks with
> > > > 0.9. But after the change to 1.0 RC1 it no longer works properly.
>
> > > > Now, when it hits a node that contains the text, for instance "test &
> > > > text", it will separate it into three records, "test", "&", "text".
> > > > With 0.9 this would return "test & text" as you would assume. Using
> > > > other special characters, such as % and *, work as expected. Anyone
> > > > else see behavior like this?
>
> > > > Any suggestions?
>
> > > > Thanks,
> > > > Chris
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to android-developers@googlegroups.com
To unsubscribe from this group, send email to
[EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
