How to stop .NET from encoding an XML string with XML.Serialization

Question

I am working with some Xml Serialization in ASP.NET 2.0 in a web service. The issue is that I have an element which is defined such as this:

<System.Xml.Serialization.XmlElementAttribute(Form:=System.Xml.Schema.XmlSchemaForm.Unqualified, IsNullable:=True)> _
Public Property COMMENTFIELD() As String
    Get
        Return CommentField ' This is a string
    End Get
    Set(ByVal value as String)
        CommentField = value
    End Set
End Property

Elsewhere in code I am constructing a comment and appending as a line-break (according to the rules of the web service we are submitting to) between each 'comment', like this: (Please keep in mind that is a valid XML entity representing character 10 (Line Feed I believe).

XmlObject.COMMENTFIELD = sComment1 & "&#xA;" & sComment2

The issue is that .NET tries to do us a favor and encode the & in the comment string which ends up sending the destination web service this: &#xA;, which obviously isn't what we want.

Here is what currently happens:

XmlObject.COMMENTFIELD = sComment1 & "&#xA;" & sComment2

Output:

<COMMENTFIELD>comment1 &amp;#xA comment2</COMMENTFIELD>

Output I NEED:

<COMMENTFIELD>comment1 &#xA; comment2</COMMENTFIELD>

The Question Is: How do I force the .NET runtime to not try and do me any favors in regards to encoding data that I already know is XML compliant and escaped already (btw sComment1 and sComment2 would already be escaped). I'm used to taking care of my XML, not depending on something magical that happens to escape all my data behind my back!

I need to be able to pass valid XML into the COMMENTFIELD property without .NET encoding the data I give it (as it is already XML). I need to know how to tell .NET that the data it is receiving is an XML String, not a normal string that needs escaped.

Are you saying that the remote web service is differentiating between
and an embedded line feed character? If so, I don't think it's processing the XML correctly. — David Norman
– David Norman, Commented Jan 6, 2009 at 22:22

David Norman · Accepted Answer · 2009-01-06 02:13:25Z

2

If you look at the XML spec section 2.4, you see that the & character in an element's text always used to indicate something escaped, so if you want to send an & character, it needs to be escaped, e.g., as & So .Net is converting the literal string you gave it into valid XML.

If you really want the web service to receive the literal text &, then .NET is doing the correct thing. When the web service processes the XML it will convert it back to the same literal string you supplied on your end.

On the other hand, if you want to send the remote web service a string with a newline, you should just construct the string with the newline:

XmlObject.COMMENTFIELD = sComment1 & "\n" & sComment2

.Net will do the correct thing to make sure this is passed correctly on the wire.

answered Jan 6, 2009 at 2:13

David Norman

20k12 gold badges68 silver badges54 bronze badges

Sign up to request clarification or add additional context in comments.

1 Comment

Astra Over a year ago

I had already tried adding Environment.NewLine between the comments and also a Chr(10) between the comments. All that comes out the other side is a normal line break (where I need the XML entity), this is because \n, Chr(10) are both valid XML values that do not need escaped.

Tom A · Accepted Answer · 2009-01-06 00:23:39Z

0

It is probably dangerous to mix two different encoding conventions within the same string. Since you have your own convention I recommend explicitly encoding the whole string when it is ready to send and explicitly decoding it on the receiving end.

Try the HttpServerUtility.HtmlEncode Method (System.Web) .

+tom

answered Jan 6, 2009 at 0:23

Tom A

6159 silver badges17 bronze badges

Collectives™ on Stack Overflow

How to stop .NET from encoding an XML string with XML.Serialization

2 Answers 2

1 Comment

Comments

Your Answer

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

1 Comment

Comments

Your Answer

Sign up or log in

Post as a guest

Related