Entwicklertools · Syntaxkonverter
XMLs Abstammung von SGML: Warum es Attribute, Namespaces und DTDs hat Die Besonderheiten von
· Hintergrund
xml Datenformate Sicherheit
XML (Attribute versus Elemente, Namespaces, DTDs, gemischter Inhalt) machen Sinn, wenn man weiß, dass es als vereinfachtes SGML für Dokumente und nicht für Daten konzipiert wurde. In diesem Beitrag wird diese Abstammung nachgezeichnet und was es bedeutet, wenn Sie XML in JSON konvertieren.
Warum hat dieses Datenformat Attribute? – ein Entwickler, der XML in JSON umwandelt und eine Unterscheidung trifft, die JSON nie benötigt wird
JSON hat eine Art von Objekteigenschaft; XML unterscheidet Attribute, untergeordnete Elemente und Text. ToolAcre bildet diese Unterscheidung mit `@`-Attributen und gewöhnlichen untergeordneten Schlüsseln ab. Der Unterschied ist sichtbar, wenn ein Element sowohl `id="7"` als auch ein untergeordnetes Element `<id>` hat: Beide bleiben unter separaten Eigenschaften bestehen.
Diese Konvention erklärt die resultierende Form, ohne zu behaupten, dass Attribute eine universelle semantische Rolle haben. XML Autoren wählen sie nach ihren eigenen Schemata aus. Der Konverter behält die Knotenkategorie bei, die er beobachten kann, nicht den Geschäftsgrund, aus dem er ausgewählt wurde.
SGML und die Dokumententradition – ISO 8879, Markup für die Veröffentlichung und die Idee, Text mit Tags zu versehen, anstatt Datensätze zu kodieren
Gemischter Inhalt, geordnete untergeordnete Elemente, Attribute, Kommentare und Verarbeitungsanweisungen sind dokumentorientierte Funktionen, die in der Quelle XML vorhanden sind. Die Implementierung demonstriert deren Handhabung, enthält jedoch keine Belege für die SGML-Chronologie, die ISO-Publikationsgeschichte oder Beweggründe der Verlagsbranche.
Ein quellengebundener Artikel beginnt daher mit ausführbarem Verhalten. Text um untergeordnete Elemente herum ist verlustbehaftet; Kommentare und Verarbeitungshinweise entfallen; CDATA bleibt markiert. Diese Fakten erklären, warum ein Dokumentbaum nicht sauber in einen JSON-Wertebaum passt.
Dokumentorientierte XML-Funktionen, die in der Implementierung sichtbar sind, ohne SGML-Verlaufsanspruch
Der Parser validiert wohlgeformte XML und meldet Zeile und Spalte. Es ignoriert die Deklaration im resultierenden Wert und behält die fünf integrierten Entitäten und numerischen Zeichenreferenzen als dekodierten Text bei. Es werden keine Arbeitsgruppenziele oder ein Zehn-Prinzip-Entwurfskonto festgelegt.
Historische Ansprüche erfordern externe redaktionelle Quellen, die in dieser Aufgabe nicht hinzugefügt werden. Sie wegzulassen ist genauer, als Compliance oder Herkunft aus einem Abhängigkeitsnamen zu erfinden.
Der Parser verarbeitet die Syntax von XML; Repository-Beweise begründen nicht den 1998-Entwurfsverlauf
Attribute werden zu Schlüsseln mit dem Präfix `@`; Elemente behalten ihren Namen. Text innerhalb eines strukturierten Elements wird nach `#text` verschoben, während ein Nur-Text-Element zu einer Zeichenfolge reduziert wird. Dadurch werden Strukturkategorien soweit auseinandergehalten, wie es ein Objektmodell zulässt.
Das Schreiben von XML kehrt die Konvention um: `@id` wird zu einem Attribut. Ungültige Attribut- oder Elementnamen werden abgelehnt und nicht bereinigt. Diese Entscheidung verhindert, dass eine fehlerhafte Zuordnung mit stillschweigend geänderten Namen plausibel wird XML.
Attribute und Elemente bleiben gemäß der @-Konvention von ToolAcre unterschiedlich
Namespace-Präfixe werden wörtlich in Element- und Attributnamen beibehalten, einschließlich Namespace-Deklarationen. Sie werden nicht aufgelöst, entfernt oder neu geschrieben. Dadurch bleibt die Rechtschreibung der Quelle erhalten, es handelt sich jedoch nicht um eine Namespace-fähige Typauflösung.
Jeder DOCTYPE wird abgelehnt, bevor fast-xml-parser das Dokument empfängt. Die Maske vermeidet falsche Übereinstimmungen innerhalb von Kommentaren und CDATA. Dies verhindert externe Entitätsanfragen, lokale Entitätslesevorgänge und Entitätserweiterungsangriffe, ohne dass die Möglichkeit besteht, die Ablehnung zu umgehen.
Namespace-Präfixe werden wörtlich beibehalten und jeder DOCTYPE wird abgelehnt
In `<p>before<b>bold</b>after</p>` kommt es auf die Textplatzierung an. ToolAcre erkennt gemischte Inhalte, fügt Fragmente unter `#text` zusammen und warnt, dass ihre Positionen relativ zu untergeordneten Elementen verloren gehen. JSON-Objekteigenschaften können keine geordnete Folge abwechselnder Text- und Elementknoten reproduzieren.
Wiederholte untergeordnete Elemente mit demselben Namen werden zu Arrays, Geschwister mit unterschiedlichen Namen bleiben jedoch Eigenschaften. Code, der eine genaue Dokumentreihenfolge erfordert, sollte eine XML-Knotendarstellung verwenden, anstatt das konvertierte Objekt als vollständig zu behandeln.
Was dies nicht abdeckt – XSLT, XPath und XQuery, die Verarbeitungssprachen, die um XML entstanden sind
XSLT, XPath und XQuery werden nicht importiert oder verfügbar gemacht. Das Gremium validiert auch keine XSD, verarbeitet keine DTD-Deklarationen und erstellt auch keine typisierten Domänenobjekte. Es handelt sich um eine Datenprojektion mit expliziten Sicherheits- und Wiedergabetreuegrenzen.
Eine Abfrage- oder Transformationssprache kann die Knotenreihenfolge auf eine Weise beibehalten und navigieren, die bei dieser Klarwertkonvertierung nicht möglich ist. Wählen Sie dieses Werkzeug, wenn die Dokumentfunktionen Teil der Arbeit sind und nicht zufällig verpackt werden.
Fazit: XML ist ein Dokumentformat, das gelernt hat, Daten zu übertragen – und wie das Syntaxkonverter-Panel zeigt, was die Übersetzung in JSON überlebt Das beobachtbare Datenmodell von
XML enthält Unterscheidungen, die in JSON fehlen. ToolAcre markiert Attribute, CDATA und strukturierten Text, behält Namespace-Präfixe bei, löscht Nicht-Datenknoten und lehnt DOCTYPEs ab. Jede Auswahl ist sichtbar und getestet.
Verwenden Sie das Panel, um zu erfahren, was eine Projektion überlebt, nicht als historische Autorität oder als vollständiger XML-Prozessor. Wenn es um die Reihenfolge, Schemata oder Namespace-Semantik geht, behalten Sie den ursprünglichen Baum bei und verwenden Sie speziell entwickelte XML-Tools.
Sicherheit und Treue überschneiden sich auch an der DOCTYPE-Grenze. Das Verweigern der Deklaration verhindert die Entitätsverarbeitung, aber das Löschen aus einem beliebigen Legacy-Dokument kann Entitätsreferenzen oder Validierungsannahmen ändern. Wenn Sie Eigentümer der Quelle sind, ersetzen Sie erforderliche Entitäten durch expliziten sicheren Text und validieren Sie das resultierende Dokument. Wenn Sie nicht der Eigentümer sind, verwenden Sie einen genehmigten XML-Workflow, anstatt die Ablehnung abzuschwächen oder eine teilweise Konvertierung als Originalinhalt darzustellen.