1

The comment field of an XML database I'm reading and writing is stored as the attribute of an NSXMLElement. One entry contains a line feed (0x0a) character. These are encoded by a non NSXML encoder in the document I'm parsing as 
 and get parsed correctly by NSXML. They result in the NSString containing the unicode value 0x0a 0x00 in memory (intel byte ordering).

For example:

<INFO BITRATE="192000" GENRE="Podcast" COMMENT="Test &amp; More Test &#xA;&#xA;After the Line Feeds"</INFO>

When writing this NSString back out as the value of an NSXMLElement's attribute, it does not get encoded back and results in the following being output to the xml file: 

 <INFO BITRATE="192000" GENRE="Podcast" COMMENT="Test &amp; More Test 

After the Line Feeds"</INFO>

which of course does not get parsed properly upon re-reading the file again.

It seems like node options like NSXMLNodePreserveCharacterReferences or NSXMLNodePreserveEntities should be the way to go but it doesn't seem to help in any way.

I must be missing the obvious but I've been stuck on this all day.

Didier Malenfant
  • 729
  • 1
  • 10
  • 25
  • Did you use those options when reading or when writing? – Ken Thomases Apr 13 '12 at 03:31
  • I first had no options (apart from NSXMLNodePrettyPrint on the whole document when writing). – Didier Malenfant Apr 13 '12 at 16:29
  • I have `NSXMLNodePrettyPrint` on the whole document and `NSXMLNodePreserveCharacterReferences | NSXMLNodePreserveEntities` on the comments attribute node when writing. I do not have any options when reading. Just using `[[anElement attributeForName:@"Comments"] stringValue]` on the node. – Didier Malenfant Apr 13 '12 at 16:35
  • The `Preserve` options are only useful when reading/parsing XML. This is in the documentation. Look up `NSXMLNodePreserveCharacterReferences` and scroll down to the discussion section. Your other option is to do the substitution yourself using standard `NSString` methods and then set it on the `NSXMLNode` using `-setStringValue:resolvingEntities:`, passing `NO`. – Ken Thomases Apr 14 '12 at 06:24
  • I will give that a try, thank you. It's odd that it isn't consistent with its read/write behavior (i.e it converts upend reading but does not convert it back upon writing). – Didier Malenfant Apr 17 '12 at 20:59
  • I have used one of my support requests with Apple to try and diagnose the problem. I will report back here any solution. – Didier Malenfant Nov 08 '12 at 03:57

2 Answers2

1

Checked with Apple, this is a known issue with NSXMLDocument and it has now been filed as a bug report.

Suggested workaround include using libxml2 for the time being.

I will post a comment if I see this fixed in a future release.

Didier Malenfant
  • 729
  • 1
  • 10
  • 25
-1

Apple says:

The options with “Preserve” in their names are applicable only when external sources of XML are parsed; they have no effect on node objects that are programmatically created. Other options are used in initialization and output methods of NSXMLDocument; see the NSXMLDocument reference documentation for details.` It dose not work for me, I think it is a bug.

I solved this problem with KissXML.

Wolfgang Kais
  • 4,010
  • 2
  • 10
  • 17
Xiaomin Liu
  • 1
  • 1