About encode /r/n

[H0LIXI]

problem
I found that in EPP version 7, when reading a cell without modifying its content and then saving it, all the newline characters get re-encoded.

Using Microsoft Excel, create a table and enter content with a newline. Save it directly. When you check the sharedStrings.xml file in hexadecimal, you can see that the newline character is 0D0A, which corresponds to \r\n.
After saving with EPP version 7, 0D0A gets re-encoded as 5F 76 30 30 30 44 5F 0A, which corresponds to x000D\n.
After saving with EPP version 6, 0D0A gets rewritten as 0A, which corresponds to \n. (This might be because version 6 uses XmlNodeList to read, which converts \r\n to \n, while version 7 uses XmlReader and can read the original \r\n.)

I'm not quite sure why \r needs to be re-encoded as x000D. Perhaps there's some historical reason for this. The encoding happens in ConvertUtil.ExcelEncodeString.

Desired Solution
I hope to retain the original \r\n because if the newline characters throughout the file change, it will cause a lot of differences when viewed in comparison tools like BeyondCompare5, which can be confusing.
Alternatively, could we refer to the behavior in EPP version 6, but replace \r\n with \n when saving? (Because BeyondCompare can recognize \r\n and \n as the same.)

[JanKallman]

I'll have a look at the encoding again. The x000D (for cr) encoding is used for characters below 0x20, but should probably not be used for crlf.