实际上PCDATA和CDATA是什么？

Question

似乎PCDATA和CDATA的松散定义就是这样

1. PCDATA是字符数据，但要进行解析。
2. CDATA是字符数据，不需要解析。

但后来有人告诉我CDATA实际上已被解析或者PCDATA实际上没有被解析...所以这有点混乱。有谁知道真正的交易是什么？

更新：我实际上在维基百科上添加了PCDATA定义...所以不要太认真地回答这个问题，因为这只是我对它的粗略理解。

Answer 1

来自WIKI：

PCDATA

简单来说，PCDATA代表解析字符数据。这意味着字符将由XML，XHTML或HTML解析器解析。 （<将更改为<p>将被视为段落标记等）。将其与CDATA进行比较，其中字符不由XML，XHTML或HTML解析器解析。

CDATA

术语CDATA（意思是字符数据）用于标记语言SGML和XML中的不同但相关的目的。该术语表示文档的某一部分是一般字符数据，而不是具有更具体，有限结构的非字符数据或字符数据。

Answer 2

PCDATA和CDATA都被解析。它们都是人物数据。

它们都必须包含有效字符。例如，如果您的文档编码是UTF-8，则CDATA部分的内容仍必须是有效的UTF-8字符。因此，随机二进制数据可能会阻止文档格式正确。此外，CDATA部分仍然被解析，如果只是为了找到结束部分标记。但其他类似标记的字符，如<，>和＆，将被解析器忽略并按原样传递。

必须转义PCDATA litteral <和＆（以及属性值中的'或'）中的OTOH，否则它们将被解释为标记。实体也将被扩展。

所以是的，确实解析了CDATA部分。我不知道为什么你被告知虽然没有解析PCDATA。

Answer 3

PCDATA - 解析的字符数据

CDATA - （未分析）字符数据

http://www.w3schools.com/XML/xml_cdata.asp

Answer 4

• PCDATA是将由解析器解析的文本。文本中的标签将被视为标记，实体将被扩展。
• CDATA是解析器不会解析的文本。文本中的标签不会被视为标记，实体也不会被展开。

默认情况下，一切都是PCDATA。在下面的示例中，将忽略根，将解析它，它将没有内容，但只有一个子。

<?xml version="1.0"?>
<foo>
<bar><test>content!</test></bar>
</foo>

当我们想要指定一个元素只包含文本而没有子元素时，我们使用关键字PCDATA，因为该关键字指定该元素必须包含可解析的字符数据 - 即除了字符小于（< ），大于（>），＆符号（＆），引号（'）和双引号（“）。

在下一个示例中，bar是CDATA，未解析，并且内容为“content！”。

<?xml version="1.0"?>
<foo>
<bar><![CDATA[<test>content!</test>]]></bar>
</foo>

SGML中有几种内容模型。 #PCDATA内容模型表示元素可能包含纯文本。它的“解析”部分意味着它中的标记（包括PI，注释和SGML指令）被解析而不是显示为原始文本。它还意味着实体引用被替换。

另一种允许纯文本内容的内容模型是CDATA。在XML中，元素内容模型可能不会隐式设置为CDATA，但在SGML中，它意味着在元素的内容中忽略标记和实体引用。但是，在CDATA类型的属性中，实体引用被替换。

在XML中#PCDATA是唯一的纯文本内容模型。如果您想要允许元素中的文本内容，则使用它。 CDATA内容模型可以通过#PCDATA中的CDATA块标记显式使用，但元素内容可能不会默认定义为CDATA。

在DTD中，包含文本的属性类型必须是CDATA。属性声明中的CDATA关键字与XML文档中的CDATA部分具有不同的含义。在CDATA部分中，除“]]>”结束标记外，所有字符都是合法的（包括<，>，＆，'和“字符）。

#PCDATA不适合属性的类型。它用于“叶子”文本的类型。

由于历史原因，＃PCDATA前缀为哈希（也称为“哈希标签”或octothorp）。

Answer 5

你的第一个定义是正确的。

解析PCDATA，这意味着实体被扩展，文本被视为标记。 XML解析器不解析CDATA。

Answer 6

如果在XHTML DTD中默认情况下只将元素设置为CDATA，则会节省大量丑陋的手动覆盖...为什么脚本块会包含其他元素？如果存在这样的元素，它们将由JS解释器在DOM操作操作中处理 - 在这种情况下，在文档插入和呈现之前，XML解析器仍应完全忽略它们。我想它可能是为了强制使用外部脚本资源文件而设计的，这最终是一件好事。