2009-03-25 16 views
0

Ist es möglich, Leerräume innerhalb von Tags zu erhalten?"whitespace" innerhalb von Tags beibehalten

Ich greife XML-Knoten (XHTML-Inhalt) in einem XPathDocument mit einem XPathNodeIterator.

Einige der Tags in den Knoten sind nicht "strikt" XHTML (und dies ist in der endgültigen Ausgabe des Werkzeugs erlaubt). Einige Knoten enthalten Image-Tags ohne das nachfolgende Leerzeichen.

<img src="filename.png" alt="description"/> 

Wenn ich die resultierenden Knoten speichern, werden sie schön mit dem nachgestellten Leerzeichen formatiert.

<img src="filename.png" alt="description" /> 

Ist es möglich, den Inhalt des Knotens zu erhalten, unter Beibehaltung der In-Tag-Abstand (in diesem Fall nicht den Raum)? Ich dachte über etwas ähnlich wie PreserveWhitespace.

Eine vereinfachte Probe des Codes verwendet

xmlDoc = New XPathDocument(fileIn, xmlSpace.Preserve) 
xmlNav = xmlDoc.CreateNavigator() 
Dim xmlNode As XPathNodeIterator 
Dim ns As XmlNamespaceManager = new XmlNamespaceManager(xmlNav.NameTable) 

xmlNode = xmlNav.Select("/export/contents[target[@translate='True']]") 
While xmlNode.MoveNext() 
    target = xmlNode.Current.selectSingleNode("target").InnerXML 
    ' ... ' 
End While 

Einige Hintergrundinformationen: Als Marc dort darauf hingewiesen, ist kein Unterschied in der Bedeutung der resultierenden XML in Bezug auf die nicht-signifikanten Leerzeichen innerhalb der Tags (oder die Tag-Reihenfolge für diese Angelegenheit).

Das Hauptproblem, auf das ich stoße, ist, dass die Daten von einem CMS-System stammen, das sowohl neue als auch alte Inhalte verarbeitet. Der Inhaltserstellungsprozess wurde erst vor kurzem in XML/XHTML verschoben, so dass noch immer nicht strenger XHTML-Inhalt im System vorhanden ist.

Die verwendeten QA-Tools sind immer noch hauptsächlich textbasiert und erstellen für HTML und werden von einer anderen Abteilung ausgeführt (der QA-Prozess muss angepasst/aktualisiert werden). Aus diesem Grund möchte ich die Tags so nah wie möglich am ursprünglichen Format halten.


als vorübergehende Behelfslösung fügte ich einige regulären Ausdrücke (neue und frühere Versionen des Knoten Vergleich) zu suchen und zu beheben, die „Unterschiede“ eingeführt, indem die XML mit .NET Parsen

+0

Ich bearbeite den Inhalt lieber nicht, also ist das Hinzufügen von xml: whitespace zum Inhalt nicht wirklich eine Option. – barry

+0

Können Sie uns ein Codebeispiel zeigen, das zeigt, wie Sie auf die XML-Knoten zugreifen und diese ausgeben? – Cerebrus

+0

Ich fügte Beispielcode – barry

Antwort

1

Ich kenne kein Parser/XML-Tool/etc (zumindest in .NET), das zwischen diesen zwei (unbedeutenden Leerzeichen) unterscheiden würde. Im Hinblick auf die Bedeutung, sie sind identisch - die gleichen, wie sie sind identisch mit:

<img alt="description" src="filename.png" /> 
+0

yeah das Endergebnis ist genau das selbe (das abschließende XHTML wird auch identisch angezeigt). Problem ist, dass ein einfacher Textvergleich einen Raumunterschied zeigt. Ich stimme zu, dass es keinen Unterschied gibt, aber die Anforderung sagt Abstand in Tags muss identisch sein ... – barry

+0

Dann ist die Anforderung ignoriert die Natur von XML ... –

+0

Ich tue mein Bestes, um den Kunden davon zu überzeugen, dass in jeder Hinsicht kein Risiko in das Ergebnis involviert ist. Und technisch gesehen enden sie mit "saubereren" Inhalten. – barry

0

Post-Prozess die Datei mit einem regulären Ausdruck s/[] [/] [>]/[/] [>]/G.

Beachten Sie, dass bei der Generierung von XHTML durch Ersetzen von < br /> einige Downlevel-Browser beschädigt werden können. < br /> wird als HTML-Tag mit unbekanntem Attribut "/" betrachtet, das dann ignoriert wird. < br /> wird als unbekanntes HTML-Tag "br /" gesehen.

+0

Danke. Im Moment wird ein automatisierter Tag-für-Tag-Vergleich der "verarbeiteten" Tags mit den Quellen im CMS durchgeführt und, falls erforderlich, werden die Tags (mit regulären Ausdrücken) "repariert". Da die Ziele derzeit nicht streng XHTML sind und es einige Mindestanforderungen für den Browser gibt, muss ich mich glücklicherweise nicht um die Kompatibilität auf niedriger Ebene kümmern. – barry