0

I'm really not understanding where these characters are coming from. I am populating a custom class object and then serializing it to disk and getting strange characters in the result like this:

<Address1>_x0031_0028_x0020_N_x0020_30th_x0020_PL</Address1>

Where the correct answer is this:

<Address1>10028 N 30th PL</Address1>

When I step through the code, each of these object properties look good, it is only after they serialize that strange characters are injected. What I am not certain of, is if the characters originate from its source (a Nexus DB table which) and I just can't see the strange characters when stepping through the code in VS, or if indeed the characters are a result of serializing from the object itself. FYI, The object class source is actually a schema object that I've converted to a class.

Another note: this problem isn't occurring on every element, just a handful of them.

Thanks for any help on this.

Karl..

kstubs
  • 808
  • 4
  • 18
  • You may need to specify the encoding to use writing the file. – David Thielen Dec 13 '13 at 23:47
  • 1
    A character is getting replaced by its hex representation. A "1" is indeed 0x0031, a space is 0x0020. The leading underscore before the x is particularly strange. The .NET framework doesn't do this, this is almost surely damage that was done before it got to your program. – Hans Passant Dec 13 '13 at 23:54
  • Yes, that is what I was suspecting. Any tips for examining the characters in VS? I'm trying to decide if this happens when I read from the Nexus DB, or after I've populated my object. – kstubs Dec 14 '13 at 00:59
  • Hi David, I have tried to specify UTF-8 encoding when readng and writing but may not have exhausted the effort. I thought I would a few questions first, and in fact I'm not certain wgich encoding to use. – kstubs Dec 14 '13 at 01:04

1 Answers1

0

Solving my own problem. The problem was that I had defined a field in my schema as xs:ncname type, and then when serializing the values in the data source did not conform to this type so spaces and leading numbers were translated accordingly on serialization.

The solution was to correctly define the field as xs:string.

kstubs
  • 808
  • 4
  • 18