Sql CDATA部分真的没有必要吗？

开发人员Michael Rys相当激进地拒绝将CDATA节的解析包含到FOR XML路径中，这引发了这个问题，因为

我在CDATA节点和其他需要使用特殊或笨拙字符的内容中存储了大量HTML。然而，我觉得没有资格质疑Rys有争议的断言，因为我认为，在我为方便起见使用CDATA的场景中，他在技术上是正确的

真正让我头疼的是，当开发人员在互联网上寻求关于如何使用for XML PATH呈现CDATA段的建议时，受访者不断指示他们使用for XML EXPLICIT

如果我们真的可以在任何人可以建议的任何情况下都不使用CDATA，我想我们应该停止抱怨，拒绝CDATA的使用。但是，如果有明确定义的情况下CDATA是必不可少的，Rys已经承诺，他将把CDATA烘焙到XML路径中，在这个问题的最上面的链接中前进

---

那么它是哪一个呢？CDATA区域真的是过去的遗迹吗？或者Rys应该伸出手指，允许XML路径中的CDATA解析吗？同时，当我们在做这件事时，有没有什么方法可以让XML PATH返回CDATA节？

CDATA

节非常有用，如果您不关心其中数据的语义（即，您不需要解析它-它只是一系列字符），并且您不希望转义其中的任何XML

定义如下：

CDATA节可能出现在字符数据可能出现的任何地方；它们用于转义包含字符的文本块，否则这些字符将被识别为标记

发件人：

XML文档的新作者经常误解CDATA部分的用途，错误地认为其目的是“保护”数据，使其在处理过程中不会被视为普通字符数据。一些用于处理XML文档的API确实提供了独立访问CDATA部分的选项，但这些选项超出了XML处理系统的正常要求，并且仍然不会改变数据的隐含含义。字符数据是字符数据，无论是通过CDATA节还是普通标记表示

CDATA部分对于将XML代码作为XML文档中的文本数据编写非常有用。例如，如果希望使用XSL对书籍进行排版，以解释XML应用程序的使用，那么书籍中显示的XML标记将写入CDATA部分的源文件中。但是，CDATA节不能包含字符串“]]>，因此CDATA节不可能包含嵌套的CDATA节。使用CDATA节对包含空间坐标轴“]]>”的文本进行编码的首选方法是通过在“>”之前拆分空间坐标轴的每次出现来使用多个CDATA节。例如，要对“]]>”进行编码，可以编写：

---

您完全正确，CDATA在许多场景中都是必不可少的，它们是XML标准的一部分，应该得到每个XML操作工具/方法的支持。但事实是，她通常不在乎。。你知道，“640kB应该对每个人都足够”这种方法。

---

编辑：关于XML EXPLICIT-这是生成精确格式化的XML数据的最佳方法。是的，语法看起来有点痛苦和混乱，但一旦你使用它几次，你就会欣赏它的美丽和强大。

CDATA部分是不必要的。它们不是“过去的遗迹”，因为它们总是不必要的

这并不意味着它们没有用处。看看任何一种编程语言或库，你都可以找到大量你可以不用的东西，因为它们在语义上等同于其他东西，但是如果有人坐在那里写东西，它们是有用的

就这一点而言，即使使用程序化生产，也可以采取相反的方法，为每一条c数据使用CDATA部分（膨胀，但在其他地方可能会提高效率）

因为XML路径不需要一个人坐在那里写东西。它是一种从SQL查询结果生成有效XML的方法。（这也不是解析CDATA节的问题，而是生成它们的问题——这是另一回事）

而且，当您需要真正精细的控制时，您也不能抱怨XML EXPLICIT是另一种选择——XML EXPLICIT有时之所以难以使用，正是因为它提供了真正精细的控制。事实上，考虑一下，如果他们首先添加了CDATA部分的支持，然后添加对每个其他Twitter和配置选项的支持，这些选项看起来对其他人来说同样重要。由于XML EXPLICIT比XML PATH更简单，所以它需要多长时间才能成为自动选择

CDATA有四种用途：

你正坐在键盘前自己输入这些东西

您正在处理的是不同技术与不同标准的混合，这些技术在不同的时间设计，并将由不同的解析器以不同的方式进行解释（例如，嵌入XHTML的javascript——尽管这里不是100%必要，否则这是一场噩梦）

您试图用一些不理解XML的东西来解析XML

您试图使用构建在解析器上的东西，该解析器允许区分CDATA节和其他字符数据的低级访问，并且不适当地使用该低级访问

有趣的是，这四种情况也是禁止接受CDATA分区的四种情况

案例1不适用于这里，它不是人工生成的代码。 如果你正在做一些非常疯狂的事情，案例2可以在这里应用。坦率地说，缺少CDATA区域是您最不担心的问题；s