2016-04-22 23 views
1

Wie soll ein Atom-Feed-Parser die folgende Zeile von XML in einem Feed handhaben:Wie sollten bei der Analyse von Atom XML-Feeds Konflikte mit CDATA- und Entity-Escape-Elementen behandelt werden?

<title type="html"><![CDATA[Johnson &amp; Johnson]]></title> 

Aus Gründen der Diskussion, lässt vermuten, dass die ursprünglich vorgesehene Text in der Tat Johnson & Johnson war. Ich kam in diesen online discussion zu diesem Problem und es schien 2 verschiedene Meinungen zu sein:

  1. Opinion #1 - claims that this content is double-encoded. Der Text "Johnson & Johnson" -Text wurde Entity-Escapezeichen und dann erneut codiert, indem es in einen CDATA-Abschnitt eingepackt wurde. Er gibt an, dass ein XML-Parser mit gutem Verhalten Johnson &amp; Johnson zurückgibt, weil die XML spec CDATA-codierten Daten so behandelt werden sollten.

  2. Opinion #2 - claims that the Atom spec takes precedent. Er erklärt, dass die CDATA als Passthrough fungiert. Johnson &amp; Johnson kommt als Johnson &amp; Johnson heraus. Wenn dies nur ein XML-Dokument wäre, würde es dort enden. Da es jedoch Atom ist, müssen wir uns dann das Atom spec ansehen, um das richtige Verhalten zu bestimmen. Die Atomspezifikation besagt, dass jedes Element mit der Entität type="html" html entkommt. Daher sollten wir frei sein, es zu entschlüsseln.

Welche dieser Fakten ist richtig? Sollte ein richtiger Atom XML-Parser produzieren: Johnson & Johnson oder Johnson &amp; Johnson angesichts dieser besonderen Situation?

Antwort

0

CDATA sind Zeichendaten, die vom Parser vollständig ignoriert werden. Es muss sein, da xml & nicht verarbeiten kann. Daher gibt es keine "doppelte Codierung" - jeder Parser springt zum close-Tag und ignoriert alles dazwischen. Ich habe keinen Parser gefunden, der das eigentliche Verschachteln ermöglicht (eingebettete CDATA-Tags zum Öffnen und Schließen).

0

Inhalt zwischen CDATA-Markern wird nicht für Entitäten von Tags analysiert, daher lautet der analysierte Wert des Textknotens Johnson &amp; Johnson.

Beachten Sie, dass das Attribut type="html" lautet, also sollte es dann als HTML analysiert werden.

z.B. Wenn Sie dies als eine Webseite ausdrückten könnten Sie schreiben:

<h1>Johnson &amp; Johnson</h1> 

Wenn es gesagt hatte type="text" dann hätte man benötigt, um die Klartext als HTML zu codieren, die Sie gegeben hätte: Beide

<h1>Johnson &amp;amp; Johnson</h1> 
+0

Ihre Aussage „so ist es dann als HTML analysiert werden soll“, wo die Mehrdeutigkeit für mich kommt. Wenn die Atom-Bibliothek normalerweise für 'type =" html "' -Elemente den Text ihres Elements html-decodiert, wenn es keine CDATA gibt, meinst du, dass sie auch den Elementtext, der in eine CDATA eingeschlossen ist, html-dekodieren soll? – mmcdole

+0

* Wenn die Atom-Bibliothek, in der Regel für type = "html" * - Die Atom-Bibliothek sollte nicht, sollte der HTML-Renderer. – Quentin

+0

Warum sollten die Feed-Parser-Bibliotheken nicht dazu übergehen, Elemente zu entlarven, die als 'type =" html "markiert sind, wenn die Spezifikation eindeutig angibt, dass sie als solche maskiert sind? Wenn Sie Pythons 'feedparser'-Bibliothek oder PHP's Simplepie'-Bibliothek fragen, den' Titel' aus einem Feed zurückzugeben, dessen Titel wie folgt definiert wurde: Beispiel: < p> titel/p > ', sie werden alle zurückgeben Beispiel

Titel

'. Diese Frage dreht sich darum, ob das CDATA-Element das typische Unescaping umgehen sollte, das sie beim Analysieren der Daten in ihre nicht-gesicherte Form machen. – mmcdole

0

Meinungen sind richtig:

  • Der Titel als Text codiert ist Johnson & Johnson.
  • Der Titel als HTML codiert ist Johnson &amp; Johnson
  • Der Titel als HTML in XML kodiert ist <![CDATA[Johnson &amp; Johnson]]>