在 xml CDATA 部分中放置包含 Enter（字符 10 或 13）的字符串有什么用处？
我目前正在研究一些具有以下结构的旧代码。
Document doc = org.w3c.Document
Element root = doc.getDocumentElement();
if ( string contains \n or \r )
then
root.appendChild(doc.createCDATASection(string))
else
root.appendChild(doc.createTextNode(string))
endif
我想不出当字符串包含“\n”或“\r”时需要将字符串放入 CDATA 部分的任何用法。 我相信使用 createTextNode 不会导致文本中的任何换行符的修剪或删除，以防字符串在设置或检索值时类似于“mytext\n\n\n”。
有人能想到一个有效/有用的情况，您希望将这样的字符串放入 CDATA 部分吗？
I'm currently working on some old code that has the following construct.
Document doc = org.w3c.Document
Element root = doc.getDocumentElement();
if ( string contains \n or \r )
then
root.appendChild(doc.createCDATASection(string))
else
root.appendChild(doc.createTextNode(string))
endif
I can not think of any usage that would need to put a string a CDATA section when it contains an "\n" or an "\r". I believe using createTextNode will not cause any trimming or removal of newlines in the text in case string is like "mytext\n\n\n" when you either set it or retrieve the value.
Can somebody think of a valid/usefull case where you would want to put such a string in a CDATA section?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我知道这听起来很明显，但如果您要嵌入纯 ascii 文本文件并且想要逐字保留文件的手动格式。 这将是一个有用的案例。
我遇到的其他情况是从图像输出元数据，我无法控制它们的格式。
I know it sounds obvious, but if you are embedding a plain ascii text file and you want to preserve the manual formatting of the file verbatim. That would be a useful case.
Other cases that I have encountered are outputting metadata from images and I have no control over their formatting.
在 XML 中，CDATA 保留空格，而普通文本则不然。
In XML, CDATA preserves whitespace, ordinary text does not.
我可能会偏离这一点，但我似乎记得将 Javascript 代码放入 CDATA 标记中是一个很好的建议。 事实上，请参阅此堆栈溢出问题的选定答案，因为它在回答原因方面做得很好： When is a脚本标记中是否需要 CDATA 部分？
I could be way off base on this, but I seem to remember it being a good recommendation to put Javascript code inside CDATA tags. In fact see the selected answer for this stack overflow question as it does a decent job on answering why: When is a CDATA section necessary within a script tag?
我想说这完全取决于您的 XML 解析是否去除空格和控制字符。 我相当肯定 .NET 中的 System.Xml 不会这样做，MSXML 或 Xerces 也不会，但有一些选项可以做到这一点。
I would say it depends entirely on whether your XML parse strips whitespace and control characters. I'm fairly certain the System.Xml ones in .NET don't, nor MSXML or Xerces but there are options to do it.
将文本放入 CDATA 部分应确保任何解析器都会忽略它，因此上面的代码可用于确保正确的格式，无论解析器被告知如何处理空格。
我认为它有效地说明了换行符在该部分中是有意义的，而不仅仅是偶然的。 不知道为什么你会仅在存在换行符的情况下放入 CDATA 部分，所以我猜这只是一种解决方法，而不是给定代码中的按设计。
Putting text inside a CDATA section should ensure that any parser ignores it, so the code above might be used to ensure correct formatting regardless what a parser is told to do with whitespace.
I supposed that it effectively says that the line breaks are meaningful in that section, and not just incidental. Not sure why you would only put a CDATA section in if there were linebreaks present though, so I would guess it's just a workaround rather than a by-design thing in the code given.
由于 CDATA 部分允许您将任意数据放入 XML 文档中，而无需了解 XML 对象将如何处理它，因此它们经常被那些不了解 XML 对象如何处理的人使用。 XML 对象起作用。 一般来说，当我看到有人在 XML 中创建 CDATA 时，我首先假设他们并不真正知道自己在做什么，除非他们提供了很好的解释。 （通常情况下，好的解释表明他们不知道自己在做什么。）
最初的开发人员可能混淆了 DOM 对包含空格的文本节点的处理与仅包含 的文本节点的处理 空白。 DOM 经常标准化纯空白文本节点，这在 XML 中可能是一个问题，例如：
如果 DOM 将第二个元素中的四个空格标准化为一个空格，则会改变该转换的功能，这无疑是一件坏事。
但是您看不到像这样的 XSLT 是有原因的：
XSLT 处理器是由了解 XML 对象如何工作的人编写的，并且知道在特定情况下告诉 DOM 保留空格很重要在纯空白文本节点中。
Since CDATA sections allow you to put arbitrary data inside an XML document without having to understand anything about how the XML objects are going to handle it, they're frequently used by people who don't understand how the XML objects work. Generally speaking, when I see someone creating CDATA in their XML I start from the assumption that they don't really know what they're doing unless they've included a good explanation. (And more often than not, that good explanation reveals that they didn't know what they were doing.)
The original developer is probably confusing the DOM's handling of text nodes that contain whitespace with its handling of text nodes that contain only whitespace. DOMs frequently normalize whitespace-only text nodes, which can be a problem in XML like:
If the DOM normalizes the four spaces in that second element down to one space, that changes the functionality of that transform, which is an unambiguously bad thing.
But there's a reason you don't see XSLT that looks like this:
And that's that XSLT processors are written by people who understand how the XML objects work, and who know that in their specific case, it's important to tell the DOM to preserve whitespace in whitespace-only text nodes.