encoding/xml: line endings in data get replaced

[tehsphinx]

What version of Go are you using (go version)?

go version go1.9.3 darwin/amd64

Does this issue reproduce with the latest release?

I created a copy of the xml package and applied the code changes of
https://go-review.googlesource.com/c/go/+/46433
which is supposed to fix issue
#20614
but the issue persists.

What did you do?

I get some xml from another service with data that contains line endings.
After parsing the data all line endings are standardized to \n.

I found this on the subject but wonder if that is supposed to even touch line endings inside CDATA. If it is just let me kindly know and I can move on to finding a workaround.
https://www.w3.org/TR/REC-xml/#sec-line-ends

Here a reproducable sample with and without CDATA escaping:
https://play.golang.org/p/PdnIyRD6Qsv

What did you expect to see?

My data with \r\n line endings intact.

What did you see instead?

My data with \n line endings.

[andybons]

Hm. The section on CDATA makes no note about normalizing line endings, however CDATA sections are unparsed entities and the line endings section seems to only apply to parsed entities.

This could go either way. Do you know how other parsers handle it?

@ianlancetaylor @rsc?

[tehsphinx]

Did some more research on the topic:

Here on stackoverflow somebody argues that since this has to be done before parsing the xml parser does not yet know if the line ending is part of a CDATA section or not: stackoverflow

MSDN library states:

XML processors treat the character sequence Carriage Return-Line Feed (CRLF) like single CR or LF characters. All are reported as a single LF character. Applications can save documents using the appropriate line-ending convention.

So I guess golang xml parser is correctly implemented and I should use base64 encoding to get line endings across.

[andybons]

OK. Closing for now. Let us know if you have any other concerns and feel free to re-open if you like.