BrowserTools
Werbung
Startseite / Validatoren / XML-Validator und -Formatierer

XML-Validator und -Formatierer

Validiere und formatiere XML in deinem Browser mit dem DOMParser.

XML-Validator und -Formatierer wird geladen… Wenn nichts passiert, aktiviere JavaScript.

XML (eXtensible Markup Language) ist ein textbasiertes Format zum Speichern und Übertragen strukturierter Daten. Entwickelt von der XML-Arbeitsgruppe des W3C und 1998 erstmals als Empfehlung veröffentlicht, wurde XML so entworfen, dass es zugleich für Menschen lesbar und für Maschinen analysierbar, selbstbeschreibend und erweiterbar ist, was bedeutet, dass Entwickler ihre eigenen Tags und Dokumentstrukturen definieren konnten, statt auf ein festes Vokabular beschränkt zu sein. XML ging unmittelbar aus SGML (Standard Generalised Markup Language) hervor, dem komplexen ISO-Standard für technische Dokumentation, entfernte aber den größten Teil von SGMLs Komplexität, um etwas zu schaffen, das sich an einem Wochenende umsetzen ließ.

Beispiele

Eingabe <note><to>Ada</to></note>
Ausgabe Well-formed
Eingabe <note><to>Ada</note>
Ausgabe Not well-formed · unclosed <note>

Jedes öffnende Tag braucht ein passendes schließendes Tag, korrekt verschachtelt.

Häufig gestellte Fragen

Wird mein XML an einen Server gesendet?
Nein. Das Analysieren und Formatieren erfolgt vollständig in deinem Browser mit der eingebauten DOMParser-API, die Teil der Webplattform ist und lokal auf deinem Gerät läuft. Dein XML-Inhalt wird nie über das Netzwerk übertragen, was dieses Werkzeug für vertrauliche Konfigurationsdateien, interne Schemata oder proprietäre Datenformate sicher macht.
Was ist der Unterschied zwischen wohlgeformtem XML und gültigem XML?
Ein wohlgeformtes XML-Dokument befolgt die grundlegenden Syntaxregeln der XML-Spezifikation: Es hat ein einziges Wurzelelement, alle Tags sind korrekt verschachtelt und geschlossen, Attributwerte stehen in Anführungszeichen und reservierte Zeichen werden mit Entitätsreferenzen maskiert. Ein gültiges XML-Dokument entspricht zusätzlich einem deklarierten Schema, einer DTD (Document Type Definition) oder einem XSD (XML Schema Definition), das einschränkt, welche Elemente und Attribute in welcher Reihenfolge erlaubt sind. Dieses Werkzeug prüft nur die Wohlgeformtheit.
Wann müsste ich in der Praxis XML validieren?
Häufige Szenarien sind das Debuggen von SOAP-Webdienst-Anfragen und -Antworten, das Inspizieren von Maven- oder Gradle-Build-Dateien, das Untersuchen von Android-Ressourcendateien, das Überprüfen von RSS/Atom-Feed-Markup, das Prüfen von SVG-Bilddateien, das Formatieren von Spring-Framework-Bean-Konfigurationen und das Validieren von HL7- oder FHIR-Nachrichten in Gesundheitsintegrationen. Immer wenn ein Werkzeug oder eine Bibliothek einen XML-Parse-Fehler meldet, deckt das Einfügen des Inhalts hier schnell die problematische Zeile auf.
Wie unterscheidet sich XML von HTML?
HTML ist so ausgelegt, dass es fehlertolerant ist; Browser rendern eine Seite selbst bei nicht geschlossenen Tags, fehlenden Anführungszeichen und überlappenden Elementen und wenden dabei komplexe Fehlerbehebungsregeln an. XML ist streng: Ein einziger Syntaxfehler macht das gesamte Dokument ungültig und es darf nicht weiterverarbeitet werden. HTML verwendet ein festes Vokabular von Elementen, das durch die HTML-Spezifikation definiert ist; XML erlaubt beliebige Tag-Namen, die vom Autor des Dokuments oder von seinem maßgeblichen Schema definiert werden.
Validiert dieses Werkzeug gegen ein XSD- oder DTD-Schema?
Derzeit nicht. Dieses Werkzeug prüft nur die Wohlgeformtheit von XML, die korrekte Syntax, mit dem DOMParser des Browsers. Die Schemavalidierung gegen XSD (XML Schema Definition) oder DTD (Document Type Definition) ist ein komplexerer Vorgang, der einen spezialisierten Validator erfordert. Für die XSD-Validierung sind Befehlszeilenwerkzeuge wie xmllint (libxml2) oder Online-XSD-Validatoren, die sowohl das Schema als auch das Dokument annehmen, besser geeignet.
Was ist die maximale Größe von XML, die ich validieren kann?
Es gibt keine fest einprogrammierte Grenze, aber der verfügbare Arbeitsspeicher des Browsers und die Leistung des DOMParsers setzen praktische Schranken. Dokumente bis zu einigen Megabyte werden in Millisekunden analysiert und formatiert. Sehr große XML-Dateien, mehrere Hundert Megabyte, etwa Datenbankexporte oder große SOAP-Antworten, können dazu führen, dass der Browser-Tab langsam oder nicht reagierend wird. Für die XML-Verarbeitung im großen Maßstab sind Befehlszeilenwerkzeuge wie xmllint oder Saxon angemessener.
Funktioniert das Werkzeug mit XML-Namensräumen?
Ja. Der DOMParser unterstützt XML-Namensräume vollständig, so wie sie von der Spezifikation Namespaces in XML definiert sind. Namensraumpräfixe (xmlns:ns="...") und Standard-Namensräume (xmlns="...") werden analysiert und in der formatierten Ausgabe erhalten. Namensraumbewusste Elemente und Attribute werden mit unversehrten Präfixen angezeigt.
Kann ich dieses Werkzeug zum Formatieren von SVG-Dateien verwenden?
Ja. SVG-Dateien (Scalable Vector Graphics) sind wohlgeformte XML-Dokumente und können von diesem Werkzeug validiert und formatiert werden. Einen SVG einzufügen und schön zu formatieren ist eine schnelle Möglichkeit, seine Struktur zu inspizieren, auf fehlerhafte Pfade zu prüfen oder eingebettete Metadaten zu überprüfen. Beachte, dass der Formatierer das XML neu serialisiert, was die Reihenfolge der Attribute ändern kann (auch wenn dies das Rendering nicht beeinflusst).
Was sind XML-Entitäten, und muss ich Zeichen in meinem Inhalt maskieren?
XML definiert fünf vordefinierte Entitätsreferenzen für Zeichen mit besonderer Bedeutung in der XML-Syntax: &amp;amp; für &, &amp;lt; für <, &amp;gt; für >, &amp;apos; für ' und &amp;quot; für ". Diese müssen immer dann verwendet werden, wenn das literale Zeichen im Textinhalt eines Elements oder in Attributwerten erscheint. Ein rohes & oder < innerhalb des Inhalts zu verwenden, verursacht einen Wohlgeformtheitsfehler. In CDATA-Abschnitten (umschlossen von <![CDATA[...]]>) wird der Inhalt als literaler Text behandelt und es ist keine Maskierung nötig.
Was ist ein häufiger Fehler, der XML ungültig macht?
Der häufigste Fehler ist die Verwendung eines nicht maskierten Und-Zeichens (&) im Textinhalt, zum Beispiel in einer URL wie href="https://example.com/page?a=1&b=2", wo & als &amp; geschrieben werden muss. Andere häufige Fehler sind selbstschließende Tags, die ohne den abschließenden Schrägstrich geschrieben werden (<br> statt <br />), nicht übereinstimmende Tag-Groß-/Kleinschreibung (<Item> geschlossen als </item>) und fehlende Anführungszeichen um Attributwerte. Anders als HTML-Parser weigern sich XML-Parser, nach einem dieser Fehler fortzufahren.

Über XML-Validator und -Formatierer

Trotz JSONs Aufstieg zur Vorherrschaft bei Web-APIs bleibt XML tief in Unternehmens- und Systemsoftware verankert. SOAP-Webdienste, die im Bankwesen, im Gesundheitswesen (HL7 FHIR) und in Behördensystemen stark genutzt werden, übertragen XML-Nachrichten. Microsoft-Office-Dokumente (.docx, .xlsx) sind ZIP-Archive aus XML-Dateien. Android-Layoutdateien und Maven-Projektbeschreibungen sind XML. RSS- und Atom-Feeds sind XML. SVG-Bilder sind XML. Konfigurationssysteme wie Spring Framework, Hibernate und Ant-Build-Dateien nutzen XML ausgiebig. Jeder Entwickler, der mit Altintegrationen, Unternehmenssystemen oder Dokumentformaten arbeitet, wird regelmäßig auf XML stoßen.

Dieses Werkzeug validiert und formatiert XML vollständig in deinem Browser mit der im Browser eingebauten DOMParser-API, derselben Engine, die HTML-Seiten rendert. Es analysiert deine Eingabe und meldet den ersten Wohlgeformtheitsfehler mit Zeilen- und Spaltennummer, sodass du Probleme sofort eingrenzen kannst. Gültiges XML wird anschließend mit einheitlicher Einrückung neu serialisiert, um eine saubere, lesbare Ausgabe zu erzeugen. Da die gesamte Verarbeitung lokal erfolgt, werden deine XML-Dokumente, die proprietäre Schemata, Zugangsdaten in Konfigurationsdateien oder sensible Geschäftsdaten enthalten können, nie auf einen Server hochgeladen.

XML ist in wichtigen Punkten strenger als HTML, die Entwickler, die neu im Format sind, ins Stolpern bringen. Jedes Element muss ordnungsgemäß geschlossen werden (anders als HTML, das nicht geschlossene Tags toleriert). Attributwerte müssen immer in Anführungszeichen stehen. Das Dokument muss genau ein Wurzelelement haben. Die fünf vordefinierten Entitätsreferenzen (&amp;, &lt;, &gt;, &apos;, &quot;) müssen für die entsprechenden literalen Zeichen innerhalb von Text und Attributwerten verwendet werden. XML unterscheidet außerdem Groß- und Kleinschreibung: <Tag> und <tag> sind unterschiedliche Elemente. Wohlgeformtheit (korrekte Syntax) ist ein vom Begriff der Gültigkeit (Konformität mit einem Schema wie XSD oder DTD) getrennter Begriff, und dieses Werkzeug prüft nur die erstere.

XML und die Suche nach einem universellen Dokumentformat

XML entstand aus einem ein Jahrzehnt währenden Bemühen, SGML (Standard Generalised Markup Language) zu bändigen, einen mächtigen, aber enorm komplexen ISO-Standard, der ursprünglich für technische Dokumentation beim US-Verteidigungsministerium entworfen wurde. SGML war so verwickelt, dass nur spezialisierte Software es verarbeiten konnte. 1996 machte sich eine W3C-Arbeitsgruppe unter der Leitung von Jon Bosak daran, ein vereinfachtes 10 % von SGML zu schaffen, das 90 % der Anwendungsfälle abdecken würde, und zwar in einer Form, die sich an einem Wochenende statt in Jahren umsetzen ließ. XML 1.0 wurde am 10. Februar 1998 zu einer W3C-Empfehlung.

Die späten 1990er und frühen 2000er Jahre waren der Höhepunkt der XML-Begeisterung. Technologen stellten sich XML als den universellen Klebstoff des Internets vor: Dokumente, Daten, Konfiguration, Nachrichtenaustausch und sogar das Programmieren würden alle XML sein. Webdienste würden SOAP-Umschläge (Simple Object Access Protocol) aus XML verwenden. Anwendungen würden ihre Schnittstellen in WSDL (Web Services Description Language) beschreiben, das selbst ein XML-Dialekt ist. Die 'Spitzklammer-Steuer', die Wortfülle der XML-Syntax, galt als lohnender Preis für universelle Interoperabilität.

Die Gegenbewegung kam mit dem Aufstieg von JSON Mitte der 2000er Jahre. JSONs Kompaktheit und seine direkte Abbildung auf JavaScript-Objekte machten es für die Anwendungsfälle von Web-APIs dramatisch einfacher, und es verdrängte XML in diesem Bereich rasch. Doch XML verschwand nie. Es bleibt das vorherrschende Format in der Unternehmensintegration, bei Dokumentformaten (ODF, OOXML), in Konfigurationssystemen und überall dort, wo Schemata, Namensräume und die Fähigkeit, Dokument und Daten zu mischen, echten Wert haben. Die Transformationssprache XSLT und die Abfragesprache XPath des W3C, beide XML-basiert, haben für komplexe Dokumenttransformationsaufgaben keine echten JSON-Entsprechungen.

Werbung
Werbung
Werbung