这个问题是由于开发人员Michael Rys非常激进地拒绝将CDATA部分解析为FOR XML PATH,因为"There is no semantic difference in the data that you store."
我在CDATA节点和其他需要使用特殊或笨拙字符的内容中存储了大量的HTML。但是我觉得有资格挑战Rys的有争议的断言,因为我认为,从技术上讲,他在我为了方便而使用CDATA的情况下是正确的。
我的面条是什么真正的烘焙,因为开发人员上网请求有关如何使用FOR XML PATH呈现CDATA段的建议,受访者不断指导他们使用FOR XML EXPLICIT,the XML rendering method Rys cited as being the "query from hell".
如果我们真的可以在每个用例中没有CDATA,任何人都可以建议我猜我们应该停止呻吟并拒绝CDATA使用。但是,如果有明确定义的CDATA必不可少的情况,Rys已经承诺将在此问题的最顶层链接中将其烘焙到FOR XML PATH中。
那是哪个? CDATA部分真的是过去的遗物吗?或者Rys应该拉出他的手指并允许在FOR XML PATH中进行CDATA解析?虽然我们在这方面,同时,是否有任何黑客可以让FOR XML PATH返回CDATA部分?
答案 0 :(得分:3)
CDATA部分是不必要的。它们不是“过去的遗物”,因为它们一直是不必要的。
这并不意味着它们没用。看看几乎任何编程语言或库,你可以找到许多你可以做的事情,因为它们在语义上等同于其他东西,但如果有人坐在那里必须写东西,那么它们很有用。 p>
就此而言,即使采用程序化生产,人们也可以采取相反的方法,并为每一段c数据使用CDATA部分(膨胀,但它可以在其他地方提高效率)。
FOR XML PATH不会让坐在那里的人不得不写东西。它是从SQL查询结果生成有效XML的一种方法。 (这也不是解析CDATA部分的问题,而是产生它们的问题 - 另一个问题)。
当你想要真正精确的控制时,你不能真的抱怨FOR XML EXPLICIT是另一种选择 - FOR XML EXPLICIT有时候使用它是如此令人讨厌的原因恰恰是因为它给你提供了非常好的控制。实际上,考虑一下他们是否首先添加对CDATA部分的支持,然后添加对其他调整和配置选项的支持,这对其他人来说似乎同样重要。 FOR XML EXPLICIT是自动选择需要多长时间,因为它比FOR XML PATH更简单
CDATA有四种情况有用:
有趣的是,这四个案例也是禁止接受CDATA部分的四个案例。
案例1不适用于此,它不是人为生成的代码。
如果您正在做一些非常疯狂的事情,案例2可以适用于此坦率地说,缺少CDATA部分是您最不担心的问题;切换到在查询中生成更简单的XML并将其转换为其他地方。
案例3可以在这里申请,但如果确实如此,那么向SQL人员投诉是不公平的,当你应该向破坏的XML解析器投诉时,不会将<example>
视为与<![CDATA[<example>]]>
相同。
案例4可以在这里申请,但是再次向编写错误代码的人投诉,而不是SQL人员。
答案 1 :(得分:2)
CDATA
部分是有用的,你不希望转义其中的任何XML。
根据w3的定义:
CDATA部分可能出现在可能出现字符数据的任何地方;它们用于转义包含字符的文本块,否则这些字符将被识别为标记。
来自wikipedia:
XML文档的新作者经常误解CDATA部分的目的,错误地认为其目的是“保护”数据在处理过程中不被视为普通字符数据。一些用于处理XML文档的API确实提供了对CDATA部分的独立访问的选项,但是这些选项存在于XML处理系统的正常要求之上,并且仍然不会改变数据的隐含含义。字符数据是字符数据,无论它是通过CDATA部分还是普通标记表达。
CDATA部分对于将XML代码作为文本数据写入XML文档非常有用。例如,如果希望使用XSL排版书籍来解释XML应用程序的使用,那么出现在书本身中的XML标记将被写入CDATA部分的源文件中。但是,CDATA部分不能包含字符串“]]&gt;”因此,CDATA部分不可能包含嵌套的CDATA部分。使用CDATA部分编码包含三元组“]]&gt;”的文本的首选方法通过在“&gt;”之前拆分三重态的每次出现来使用多个CDATA部分。例如,要编码“]]&gt;”一个人会写:
答案 2 :(得分:0)
你是绝对正确的,CDATA在许多场景中都是必不可少的,它们是XML标准的一部分,应该得到每个XML操作工具/方法的支持。但事情是,MS通常不关心......你知道,“640kB对每个人来说应该足够了”这种方法。
编辑:关于FOR XML EXPLICIT - 这是生成精确格式化XML数据的最佳方法。是的,语法有点痛苦,看起来很混乱,但是一旦你使用它几次,你会欣赏它的美丽和力量。
答案 3 :(得分:0)
有趣的是,有人可以用这种异想天开的方式抛出非常有价值的标准片。并非每个人都使用XML来处理几百个字符的HTML或一个项目列表以进行下拉。
我们中的一些人实际上使用XML来交换数据,非常复杂的数据,如CCD,CDA CDR,这些都是医疗保健领域的标准文档格式,并且随着ObamaCare变得越来越突出。这些文档结构的一部分包含附件,如DiCOM图像,PDF和其他二进制数据,解析器不应该读取CDATA定义的原因。
为什么我需要支付解析器读取CCD文档中嵌入的3兆字节DiCom图像的开销?当原始数据中的文档成为XML标准的一部分时,为什么要强制将文档分开。我希望能够找到并恢复文档,并且是XML内容。
这令我感到困惑,为什么你们都支持解析那些不被引擎解析的数据。如果引擎看到CDATA忽略它,它就很简单了。而一些不需要它的持续论点是无关紧要的。它是标准的一部分,应该保持标准。如果他们想要在调用时添加“功能”,则使用选项支持默认行为。
请停止解析CDATA并忽略它。