Details
-
Type:
Bug
-
Status:
Closed
-
Resolution: Fixed
-
Affects Version/s: None
-
Fix Version/s: 1.4.2
-
Component/s: None
-
Labels:None
-
JDK version and platform:Sun 1.4.2_08-b03 for Windows
Description
PropertiesConverter makes some bad assumptions about the Strings that
appear in the name-value pairs. From the PropertiesConverter javadoc:
Special converter for java.util.Properties that stores properties in a
more compact form than java.util.Map. Because all entries of a
Properties instance are Strings, a single element is used for each
property with two attributes; one for key and one for value.
The problem is that the XML spec
(http://www.w3.org/TR/REC-xml/#AVNormalize) and the
org.xmlpull.mxp1.MXParser "normalize" attributes to remove tabs,
newlines, and carriage returns.
So a value inside a Properties object called "my<tab>property" gets
normalized to "my<space>property" when reading the attribute (see
MXParser.parseAttribute()).
When writing Properties to a file, Java escapes the tabs with a \t so
that it would appear in the property files as
key=my\tproperty
PropertiesConverter should probably be removed entirely and Properties
should be encoded just like any other Map using XML entities. It could
still use attributes, but it would have to use [[CDATA]] in order to
work with the XML spec.
Issue Links
Activity
Sadly that I never realized that the XML spec is quite clear: Attributes are written by default as CDATA. And while '\n', '\t' and '\r' are replaced with spaces by the attribute normalization, they are replaced with the real character if these characters are delivered as entities. Therefore will the PrettyPrintWriter (and derived) encode these characters now with entities. Note, that the writers based on 3rd party code may still fail to do so. BEA's and Woodstox' StAX writer and the XOM writer are compliant and will encode these whitespace characters, while JDK's StAX writer and Dom4J's XML writer fail.
Jörg Schaible
added a comment - Sadly that I never realized that the XML spec is quite clear: Attributes are written by default as CDATA. And while '\n', '\t' and '\r' are replaced with spaces by the attribute normalization, they are replaced with the real character if these characters are delivered as entities. Therefore will the PrettyPrintWriter (and derived) encode these characters now with entities. Note, that the writers based on 3rd party code may still fail to do so. BEA's and Woodstox' StAX writer and the XOM writer are compliant and will encode these whitespace characters, while JDK's StAX writer and Dom4J's XML writer fail. 
Hi
As discussed with Jörg Schaible in the user's mailing list, XStream's PrettyPrintWriter should treat & escape '\n' and '\t' the same way it treats & escape '\r' (else the xml parseur on the other end will just replace them by white-spaces). This should be the case for the values as well as for the attributes (anyway, the PrettyPrintWriter's escaping is done in a single method for the 2, so there is only the writeText method to change.
And btw, thank's for the great lib !