XML-Validator
Wohlgeformtheit und Schemaprüfung. Nichts wird hochgeladen.
Alles läuft in diesem Tab. Nichts, was Sie einfügen, wird hochgeladen, protokolliert oder irgendwohin gesendet. Öffnen Sie Ihr Netzwerkpanel und prüfen Sie es.
Fügen Sie oben ein Dokument ein, und es wird während der Eingabe geprüft. Jedes Problem wird mit Zeile, Spalte und dem, was stattdessen dort stehen sollte, gemeldet – und zwar alle auf einmal, statt beim ersten abzubrechen. Nichts wird hochgeladen: Parser, Schema-Engine und Editor laufen in diesem Tab. Öffnen Sie das Netzwerkpanel Ihres Browsers und sehen Sie zu, wie es beim Arbeiten leer bleibt.
Der letzte Punkt ist keine Werbezeile. Mehrere der Werkzeuge, die für diese Suche gut ranken, schicken Ihr Dokument zum Prüfen an einen Server. Eines davon lässt Sie ein Häkchen setzen, mit dem Sie bestätigen, verstanden zu haben, dass Ihre Daten auf deren Servern gespeichert und aufbewahrt werden können. Wenn Sie eine SOAP-Envelope mit einem Bearer-Token oder eine Konfigurationsdatei mit einem Connection String debuggen, ist das ein echtes Problem – und der Grund, warum es diese Seite gibt.
Der Validator führt beide Prüfungen durch, die XML definiert, und hält sie auseinander, denn sie beantworten verschiedene Fragen, und fast jedes kostenlose Werkzeug wirft sie zusammen.
Wohlgeformt und gültig sind nicht dieselbe Prüfung
Ein Dokument ist wohlgeformt, wenn seine Syntax stimmt: Tags sind geschlossen und richtig verschachtelt, es gibt genau ein Wurzelelement, Sonderzeichen sind maskiert und Attributwerte stehen in Anführungszeichen. Dafür braucht es nichts außer dem Dokument selbst, deshalb läuft diese Prüfung automatisch während der Eingabe.
Ein Dokument ist gültig, wenn es wohlgeformt ist und zusätzlich zu einem Schema passt: Die Elemente, die da sein sollen, sind da, in der richtigen Reihenfolge, mit den richtigen Typen. Dafür braucht es eine zweite Datei, ein XSD oder eine DTD, und deshalb ist es eine eigene Aktion, die Sie bewusst auslösen.
Der Unterschied ist wichtig, weil „gültiges XML“ das ist, was Leute sagen, wenn sie eines von beiden meinen. Hat ein System Ihr Dokument mit dem Hinweis „ungültig“ abgelehnt, hat es vermutlich eine Schemaprüfung gemacht, und ein grüner Haken einer Wohlgeformtheitsprüfung sagt Ihnen nicht, woran es lag. Das Ergebnisfeld hier nennt immer, welche Prüfung gelaufen ist.
- Wohlgeformt, aber nicht gültig: <note><to>Alice</to></note> gegen ein Schema, das auch <from> verlangt. Die Syntax ist einwandfrei; der Inhalt ist falsch.
- Gültig, aber nicht wohlgeformt: unmöglich. Gültigkeit schließt Wohlgeformtheit ein, weshalb die Schemaprüfung sich weigert zu laufen, solange die Syntax nicht sauber ist.
Was Ihnen die Fehler tatsächlich sagen
Die Lücke in dieser Kategorie sind nicht die Funktionen, sondern die Fehlermeldungen. Browser-Parser halten beim ersten Problem an und formulieren es für den, der den Parser geschrieben hat. Firefox meldet ein nicht maskiertes Kaufmanns-Und als „EntityRef: expecting ';'“. libxml2 nennt dasselbe „xmlParseEntityRef: no name“. Keiner erwähnt das Und-Zeichen, das Maskieren oder den URL-Querystring, der es fast sicher verursacht hat.
Jede Diagnose hier benennt den Fehler mit den Worten, die Sie benutzen würden, gibt die genaue Stelle an und schlägt die Lösung vor. Ein Klick auf die Marke Zeile:Spalte setzt den Cursor dorthin. Wo ein Fehler häufig genug ist, führt ein Link zu einer Seite, die die Ursache erklärt – samt der entsprechenden Meldung von sechs anderen Parsern, damit Sie ihn wiedererkennen, wenn Ihr Build ihn das nächste Mal anders formuliert.
Große Dokumente und feindselige Dokumente
Das Parsen läuft in einem Web Worker, die Oberfläche bleibt also bedienbar, während ein großes Dokument geprüft wird. Eine 100-KB-Datei ist in etwa 20 Millisekunden geprüft, 1 MB in rund 110, und 10 MB in etwas über einer Sekunde. Über 20 MB lehnt das Werkzeug ab: Alles liegt im Speicher dieses Tabs, und ein so großes Dokument macht den Browser nicht langsam, sondern unbedienbar.
XML kennt Denial-of-Service-Muster, die JSON nicht hat, und sie werden hier begrenzt statt vorausgesetzt. Ein Dokument mit verschachtelten Entities, die exponentiell expandieren – das Muster „billion laughs“ – wird in etwa zwei Millisekunden abgelehnt, weil die Expansionskosten aus den Deklarationen berechnet werden, bevor ein einziges Zeichen expandiert ist. Die quadratische Variante, eine große Entity, die tausendfach referenziert wird, fällt unter dasselbe Budget. Die Verschachtelungstiefe ist gedeckelt, Entity-Zyklen werden erkannt statt durchlaufen, und externe Entities werden gemeldet, aber nie geladen.
Die Dokumente, die hier tatsächlich eingefügt werden
Ein Validator ist ein Allzweckwerkzeug, aber die Dokumente, die bei einem ankommen, verteilen sich nicht gleichmäßig. Eine Handvoll Formen macht den größten Teil des Verkehrs aus, und jede scheitert auf ihre eigene charakteristische Weise.
In den meisten dieser Fälle sind Validieren und Formatieren dieselbe Aufgabe. Die Datei ist unlesbar, weil sie minifiziert ankam oder nacheinander von drei verschiedenen Werkzeugen eingerückt wurde, und der Fehler bleibt unsichtbar, bis sie ordentlich gesetzt ist. Die Schaltfläche Formatieren oben formatiert an Ort und Stelle, ohne Umweg über eine andere Website; der XML-Formatierer ist die vollständige Fassung, mit Kontrolle über die Einrücktiefe und darüber, was mit Kommentaren geschieht.
- XML-Sitemaps. Der Sitemap-Validator prüft das sitemaps.org-Protokoll und nicht nur die Syntax: die Obergrenzen von 50.000 URLs und 50 MB, das W3C-Datetime-Format, das lastmod tatsächlich verlangt, und die Regel, dass jede URL auf demselben Host liegen muss wie die Sitemap. Eine Google-Sitemap kann einwandfrei wohlgeformt und trotzdem abgelehnt sein, und fast immer ist es eines dieser drei Dinge.
- SEPA und andere ISO-20022-Zahlungsnachrichten. Ein pain.008-Lastschriftauftrag oder ein camt.053-Kontoauszug ist nur sinnvoll, wenn er gegen sein veröffentlichtes XSD geprüft wird, also gehören die in den XSD-Validator, mit dem Schema daneben eingefügt. Das ist die Kategorie, in der die Zusage, nichts hochzuladen, aufhört, eine Abstraktion zu sein: Eine Testdatei trägt immer noch echte IBANs und Gläubiger-Identifikationsnummern.
- Konfiguration von Spieleservern. DayZ, Arma und die Server auf derselben Engine lesen beim Start types.xml, cfgspawnabletypes.xml und events.xml, und ein einziges nicht geschlossenes <type>-Element hält den Server mit einer Meldung an, die weder die Datei noch die Zeile nennt. Wird die Datei hier eingefügt, bekommt man beides, dazu die Verschachtelungstiefe an der Bruchstelle.
- SOAP-Envelopes und die Antworten, die von ihnen zurückkommen. Das sind die Dokumente, die am ehesten ein Bearer-Token oder eine Verbindungszeichenfolge enthalten, und genau deshalb gibt es den SOAP-Formatierer als eigene Seite.
- RSS- und Atom-Feeds, bei denen der übliche Fehler ein rohes Und-Zeichen in einer URL innerhalb eines Titels ist, während der Feedreader nur meldet, dass der Feed kaputt sei.
Wenn Sie es gewohnt sind, in Notepad++ zu validieren
Notepad++ bringt keine eigene XML-Unterstützung mit. Das Plugin XML Tools fügt sie hinzu, und dieses Plugin ist eine Anbindung an libxml2, also genau die Engine, die diese Website nach WebAssembly kompiliert. Die eigentlichen Prüfungen stimmen daher überein. Was sich unterscheidet, ist alles drumherum.
Das Plugin meldet einen Fehler in einem Dialogfenster statt am Dokument: Man liest eine Zeilennummer und geht sie dann suchen. Es läuft nur unter Windows, weil Notepad++ das tut, und der Plugin-Build muss zur Architektur des Editors passen, was der übliche Grund für ein ausgegrautes Menü nach frischer Installation ist. Schemavalidierung gibt es, aber sie erwartet, dass das XSD über die Deklaration im Dokument selbst erreichbar ist, was ein aus einer größeren Datei herausgelöstes Fragment selten hat.
Keines der beiden Werkzeuge ersetzt das andere, und die ehrliche Aufteilung hängt davon ab, wo das Dokument schon liegt. Ist es eine Datei auf der Platte, sind Sie ohnehin im Editor und haben kein Netz, ist das Plugin der kürzere Weg. Kam es in einem Support-Ticket, in der Zwischenablage oder in einem Browser-Tab an, wollen Sie alle Fehler in einem Durchgang statt einen pro Dialog, oder sind Sie nicht unter Windows, ist eine Seite zu laden schneller als ein Plugin zu installieren. Dasselbe gilt für den Schema-Fall: Ein XSD in das zweite Feld hier einzufügen braucht überhaupt keine Deklaration im Dokument.
Dasselbe in Code
Dieselbe Prüfung in den Sprachen, die am meisten XML verarbeiten. Jedes Beispiel steht in seiner sicheren Form: Die Standardeinstellungen mehrerer dieser Bibliotheken lösen externe Entities bereitwillig auf – das ist die XXE-Schwachstelle. Die Flags unten sind also der Kern und keine Formalität.
// DOMParser does not throw on malformed input. It returns a document
// containing a <parsererror> element instead, which is why so much code
// silently accepts broken XML.
function parseXml(source) {
const doc = new DOMParser().parseFromString(source, 'application/xml');
const error = doc.querySelector('parsererror');
if (error) {
throw new Error(error.textContent.trim());
}
return doc;
}
// Browsers do not resolve external entities, so XXE is not reachable here.
// Internal entity expansion is, so cap the input size before parsing.# The standard library is not safe against entity-expansion attacks.
# defusedxml is the maintained answer and is a drop-in replacement.
from defusedxml.ElementTree import fromstring, ParseError
try:
root = fromstring(source)
except ParseError as e:
# e.position is a (line, column) tuple, 1-based line, 0-based column
line, column = e.position
raise SystemExit(f"XML error at line {line}, column {column + 1}: {e}")
# With lxml, disable resolution explicitly:
# parser = etree.XMLParser(resolve_entities=False, no_network=True,
# huge_tree=False, load_dtd=False)
# root = etree.fromstring(source.encode(), parser)import javax.xml.XMLConstants;
import javax.xml.parsers.DocumentBuilderFactory;
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
// FEATURE_SECURE_PROCESSING caps entity expansion. The three
// disallow-doctype settings close XXE. None of this is the default.
factory.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true);
factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
factory.setFeature("http://xml.org/sax/features/external-general-entities", false);
factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
factory.setXIncludeAware(false);
factory.setExpandEntityReferences(false);
var builder = factory.newDocumentBuilder();
try {
var document = builder.parse(new java.io.ByteArrayInputStream(bytes));
} catch (org.xml.sax.SAXParseException e) {
System.err.printf("XML error at line %d, column %d: %s%n",
e.getLineNumber(), e.getColumnNumber(), e.getMessage());
}using System.Xml;
var settings = new XmlReaderSettings
{
// Null resolver means external DTDs and entities are never fetched.
DtdProcessing = DtdProcessing.Prohibit,
XmlResolver = null,
MaxCharactersFromEntities = 1024 * 1024,
MaxCharactersInDocument = 20L * 1024 * 1024,
};
try
{
using var reader = XmlReader.Create(new StringReader(source), settings);
var document = new XmlDocument { XmlResolver = null };
document.Load(reader);
}
catch (XmlException e)
{
Console.Error.WriteLine(
$"XML error at line {e.LineNumber}, column {e.LinePosition}: {e.Message}");
}<?php
// libxml_disable_entity_loader was deprecated in PHP 8.0 because external
// entity loading became off by default. On PHP 7 you still need it.
libxml_use_internal_errors(true);
$doc = new DOMDocument();
$loaded = $doc->loadXML($source, LIBXML_NONET | LIBXML_NOENT & ~LIBXML_NOENT);
if (!$loaded) {
foreach (libxml_get_errors() as $error) {
fprintf(
STDERR,
"XML error at line %d, column %d: %s\n",
$error->line,
$error->column,
trim($error->message)
);
}
libxml_clear_errors();
exit(1);
}# xmllint is part of libxml2 and is almost certainly already installed.
# --nonet stops it fetching a DTD referenced by the document.
xmllint --noout --nonet document.xml
# Validate against a schema:
xmllint --noout --nonet --schema schema.xsd document.xml
xmllint --noout --nonet --valid document.xml # against its own DTD
# Exit status is 0 when valid. Note that xmllint's exit code does not
# always reflect namespace errors, so check the output too.Jedes dieser Beispiele schaltet etwas ab. Das ist kein Zufall: Das unsichere Verhalten ist der Standard in Java, in PHP vor 8.0 und in Pythons Standardbibliothek – und auf genau diesen Standardwerten läuft der Großteil des XML-Parsens in Produktion.
Häufige Fragen
Wird mein XML irgendwohin hochgeladen?
Nein. Parser, Formatierer und Schema-Engine sind JavaScript und WebAssembly, die in diesem Tab laufen. Es gibt keine serverseitige Komponente, an die sich etwas senden ließe.
Sie müssen das nicht glauben. Öffnen Sie die Entwicklerwerkzeuge Ihres Browsers, wechseln Sie auf den Netzwerk-Tab, fügen Sie ein Dokument ein und validieren Sie es. Sie sehen die Assets der Seite einmal laden und danach nichts mehr. Diese Seite hat keine Analytics mit Zugriff auf den Editor, keine Skripte Dritter und keinen Fehlerberichtsdienst.
Was ist der Unterschied zwischen wohlgeformt und gültig?
Wohlgeformt heißt, die Syntax stimmt: geschlossene Tags, korrekte Verschachtelung, ein Wurzelelement, maskierte Sonderzeichen, Attributwerte in Anführungszeichen. Gültig heißt wohlgeformt und zusätzlich einem Schema entsprechend, also einer separaten Datei, die beschreibt, welche Elemente wo erlaubt sind.
Ein Dokument kann wohlgeformt sein, ohne gültig zu sein. Gültig ohne wohlgeformt geht nicht. Wenn ein System sagt, Ihr XML sei „ungültig“, hat es meist eine Schemaprüfung ausgeführt – eine reine Syntaxprüfung erklärt den Fehlschlag dann nicht.
Kann es gegen ein XSD validieren?
Ja, und es ist ungewöhnlich, das ohne Server zu tun. Browser haben keinen eingebauten Schemavalidator, also lassen kostenlose Werkzeuge die Schemaprüfung entweder weg oder laden Ihre Dateien hoch. Diese Seite führt libxml2 als WebAssembly aus und bietet damit XSD-1.0- und DTD-Validierung vollständig im Browser.
Die Engine ist komprimiert etwa 480 KB groß und wird deshalb erst geladen, wenn Sie tatsächlich eine Schemaprüfung anfordern, nicht beim Seitenaufruf. Beachten Sie: libxml2 implementiert nur XSD 1.0. Schemata mit XSD-1.1-Funktionen wie xs:assert lassen sich nicht kompilieren, und das Werkzeug sagt das, statt einen verwirrenden Strukturfehler zu melden.
Warum meldet es mehrere Fehler, wo andere Validatoren einen melden?
Weil ein Fehler selten die ganze Geschichte ist, und weil ein Parser, der beim ersten Problem stehen bleibt, Sie ein großes Dokument in vielen Runden korrigieren lässt.
Der Scanner setzt nach einem Fehler wieder auf und macht weiter, sodass ein Durchlauf das Attribut ohne Anführungszeichen in Zeile 4, das rohe Und-Zeichen in Zeile 12 und das nicht geschlossene Tag am Ende findet. Etwas Vorsicht ist angebracht: Ein früher Fehler wie ein nicht geschlossenes Tag kann alles danach falsch aussehen lassen. Beheben Sie die ersten und prüfen Sie erneut, statt die Liste von unten abzuarbeiten.
Wie große Dateien schafft es?
Bis 20 MB. Ein 10-MB-Dokument wird in etwas über einer Sekunde geprüft, und das Parsen läuft in einem Web Worker, die Seite friert also nicht ein.
Die Grenze ist bewusst gesetzt und nicht durch Abstürze entdeckt. Alles liegt im Speicher dieses Tabs, und jenseits von etwa 20 MB kann der Parse-Baum mehrere hundert Megabyte belegen. Für wirklich große Dateien ist ein Streaming-Parser auf Ihrem eigenen Rechner das richtige Werkzeug: xmllint, Pythons iterparse oder ein SAX-Parser – keiner davon baut den ganzen Baum auf.
Behandelt es Namensräume korrekt?
Ja. Präfixe werden gegen die im Gültigkeitsbereich sichtbaren Deklarationen aufgelöst, und die Verwendung eines nicht gebundenen Präfixes wird als Fehler gemeldet, samt der Deklaration, die fehlt. Das passiert häufig, wenn ein Fragment aus einem größeren Dokument kopiert wird und die xmlns-Deklaration am ursprünglichen Wurzelelement zurückbleibt.
Der Editor stellt das Präfix zudem blasser dar als den lokalen Namen, sodass soap:Body als Body mit Gerüst drumherum zu lesen ist. Eine Kleinigkeit, die eine tief verschachtelte SOAP-Envelope aber deutlich leichter überblicken lässt.
Ist es sicher, ein Dokument mit Zugangsdaten einzufügen?
Sicherer als in jedem Werkzeug, das es hochlädt, denn hier wird nichts übertragen. Das Dokument verlässt den Tab nicht, wird nicht protokolliert und taucht in keinem Fehlerbericht auf.
Eine Einschränkung gehört dazu: Ihre Eingabe wird im localStorage dieses Browsers gespeichert, damit ein Neuladen die Arbeit nicht vernichtet. Das bleibt lokal auf Ihrem Rechner und wird nie übertragen, bedeutet aber, dass das Dokument bestehen bleibt, bis Sie es löschen. Die Schaltfläche „Leeren“ entfernt es sofort, und Dokumente über 300 KB werden gar nicht erst gespeichert.
Kann ich damit eine XML-Sitemap validieren?
Ja, und für eine Sitemap ist die eigene Seite des Sitemap-Validators die bessere. Diese hier prüft, ob das Dokument wohlgeformtes XML ist, was notwendig, aber nicht hinreichend ist: Eine Sitemap, die Google ablehnt, ist meist wohlgeformt und verletzt stattdessen eine Protokollregel.
Jene Seite prüft die Regeln selbst. Die Grenzen von 50.000 URLs und 50 MB unkomprimiert, den sitemaps.org-Namensraum, lastmod im W3C-Datetime-Format statt in dem, was Ihr Framework ausgegeben hat, und die Anforderung, dass jede URL auf demselben Host liegt wie die Sitemap-Datei. Sie markiert außerdem die Elemente, von denen Google öffentlich gesagt hat, dass es sie ignoriert, damit Sie aufhören, an Werten zu drehen, die nichts bewirken.
Kommt es mit SEPA und ISO-20022-Dateien wie pain.008 oder camt.053 zurecht?
Ja. Eine ISO-20022-Nachricht ist gewöhnliches XML mit einem großen Schema dahinter. Fügen Sie also die Nachricht in den XSD-Validator ein und das passende pain.008- oder camt.053-Schema in das zweite Feld. Die Validierung läuft gegen dieses Schema in Ihrem Browser, ohne Konto und ohne Obergrenze außer dem allgemeinen 20-MB-Limit.
Das ist der Fall, in dem es am meisten darauf ankommt, wohin das Dokument geht. Eine Zahlungsdatei, die nur ein Test ist, trägt trotzdem echte IBANs, Gläubiger-Identifikationsnummern und Mandatsreferenzen, und mehrere kostenlose Validatoren, die ISO-20022-Dateien annehmen, laden sie zuerst auf einen Server. Hier wird nichts übertragen, was Sie im Netzwerk-Tab während der Arbeit nachsehen können. Eine Grenze, die man kennen sollte: Die Engine implementiert XSD 1.0, und in dieser Fassung sind die veröffentlichten ISO-20022-Schemas geschrieben.
Kann ich es für DayZ-Serverdateien wie types.xml verwenden?
Ja, dafür eignet es sich gut. Die DayZ-Wirtschaftsdateien types.xml, cfgspawnabletypes.xml, events.xml und cfgeventspawns.xml sind einfaches XML, und der Server weigert sich zu starten, wenn eine davon fehlerhaft ist. Die Meldung, die er ausgibt, nennt meist weder die Datei noch die Position, und genau das macht aus einer fehlenden spitzen Klammer einen ganzen Abend.
Fügen Sie die Datei hier ein, und jeder Syntaxfehler wird auf einmal mit Zeile und Spalte gemeldet, sodass eine über mehrere Sitzungen von Hand bearbeitete Datei in einem Durchgang statt mit einem Neustart nach dem anderen in Ordnung kommt. Zwei Einschränkungen, die gesagt gehören: Für diese Dateien gibt es kein veröffentlichtes XSD, hier wird also geprüft, ob das XML wohlgeformt ist, und nicht, ob ein Attributwert einer ist, den das Spiel akzeptiert; und ein nominal- oder lifetime-Wert, der zulässiges XML, aber für Ihre Loot-Wirtschaft falsch ist, kommt hier durch und verhält sich im Spiel trotzdem falsch.
Wie schlägt sich das gegenüber dem XML-Validator in Notepad++?
Sie verwenden dieselbe Engine. Notepad++ liefert von sich aus keine XML-Unterstützung; das Plugin XML Tools stellt sie bereit und baut auf libxml2 auf, also auf dem, was diese Website als WebAssembly ausführt. Die beiden sind sich daher einig, ob ein Dokument wohlgeformt ist.
Die Unterschiede sind praktischer Natur. Das Plugin läuft nur unter Windows, und sein Build muss zur Architektur des Editors passen, weshalb eine frische Installation oft ein ausgegrautes Menü hat. Es meldet Fehler in einem Dialog statt am Dokument, und seine Schemavalidierung erwartet das XSD im Dokument deklariert, was ein kopiertes Fragment selten hat. Diese Seite nimmt ein XSD im zweiten Feld ohne jede Deklaration entgegen, meldet alle Syntaxfehler in einem Durchgang und läuft überall, wo es einen Browser gibt. Ist die Datei ohnehin in Notepad++ offen und Sie sind offline, nehmen Sie das Plugin; das ist der Fall, den es gewinnt.
Ist dieser XML-Validator kostenlos, und muss ich mich anmelden?
Er ist kostenlos, und es gibt kein Konto, keine E-Mail-Abfrage, kein Tageskontingent und keinen Bezahltarif, der die Schemavalidierung zurückhält. Nichts auf der Website ist gesperrt.
Das anzubieten ist leichter, als es klingt, weil die Rechnung eine andere ist. Ein Validator, der auf einem Server läuft, zahlt CPU für jedes Dokument, das Sie prüfen, und deshalb zählen solche Werkzeuge die Nutzung, begrenzen die Dateigröße oder verlangen eine Registrierung. Hier findet die Analyse auf Ihrem Rechner statt, eine 10-MB-Datei kostet die Website also nichts, und es gibt keinen Grund zu zählen, wie viele Sie validieren.
Kann ich XML online validieren, ohne etwas zu installieren?
Genau das ist diese Seite. Sie läuft in jedem aktuellen Browser unter Windows, macOS, Linux, Android oder iOS, ohne Installation, ohne Erweiterung und ohne Konto.
Eine Unterscheidung lohnt sich, weil das Wort online dort zwei Aufgaben erfüllt. Die meisten Online-Validatoren sind es in beiden Bedeutungen: Die Seite liegt im Web, und Ihr Dokument wird zur Prüfung an deren Server geschickt. Dieser hier ist nur im ersten Sinn online. Die Seite wird einmal über das Netz ausgeliefert, danach laufen Parser, Schema-Engine und Editor lokal im Tab. Einmal geladen, arbeitet sie auch ohne Netzverbindung weiter.
Ist das ein XML-Validator und -Formatierer, oder brauche ich zwei Werkzeuge?
Beides ist hier. Die Schaltfläche Formatieren in der Reihe oben formatiert das, was im Editor steht, an Ort und Stelle neu. Der übliche Ablauf, etwas Unlesbares einzufügen, es zu setzen und dann den Fehler zu finden, kommt also ohne Seitenwechsel aus.
Der XML-Formatierer ist die vollständige Fassung für den Fall, dass Formatieren die Aufgabe selbst ist und nicht ein Schritt auf dem Weg zu etwas anderem: Einrücken mit zwei Leerzeichen, vier Leerzeichen oder Tabulatoren, entscheiden, was mit Kommentaren geschieht, und in die Gegenrichtung minifizieren. Auch dort läuft die Validierung, denn ein Dokument muss wohlgeformt sein, bevor es überhaupt neu formatiert werden kann.
Kann es XML nicht nur prüfen, sondern auch verschönern?
Ja. Verschönern, Pretty-Printing und Formatieren sind dieselbe Operation: Das Dokument wird neu eingerückt, damit die Verschachtelung sichtbar wird, und genau das macht einen Fehler meist überhaupt erst auffindbar.
Ein Detail sollte man kennen, weil die meisten Verschönerer es falsch machen. Leerraum zwischen zwei Elementen ist unbedeutend und gefahrlos änderbar, aber Leerraum innerhalb eines Elements, das auch Text enthält, ist Inhalt, und ihn neu einzurücken ändert die Bedeutung des Dokuments. Ein Verschönerer, der <p>Hallo <b>dort</b></p> über drei eingerückte Zeilen verteilt, hat den Inhalt verändert und nicht nur seine Darstellung. Dieser lässt gemischten Inhalt genau so, wie er ihn vorgefunden hat, und deshalb bleiben Teile eines verschönerten Dokuments auf einer einzigen Zeile.
Was ist der beste XML-Validator?
Das hängt davon ab, wo das Dokument schon liegt und was geprüft werden soll, und eine ehrliche Antwort schließt die Fälle ein, in denen es nicht dieser hier ist.
Für ein Dokument, das Sie einfügen können, ist ein Browser-Werkzeug der kürzeste Weg, und die drei Punkte, die einen Vergleich lohnen, sind: ob es überhaupt gegen ein Schema validiert, ob es Ihre Datei dafür hochlädt, und ob Sie mit den gemeldeten Fehlern etwas anfangen können. Für eine Datei, die ohnehin in einem Projekt offen ist, liegt Ihr Editor näher: VS Code mit der XML-Erweiterung von Red Hat oder IntelliJ validieren beim Tippen gegen ein Schema. Für Dateien, die nicht in den Speicher passen, oder für einen Build-Schritt ist xmllint das richtige Werkzeug und auf den meisten Rechnern bereits installiert. In einer CI-Pipeline gehört der Validator der Sprache hin, in der die Pipeline geschrieben ist.
Dieser hier ist für den mittleren Fall gebaut: Schemavalidierung ohne Server, alle Syntaxfehler in einem Durchgang statt nur des ersten, und Meldungen, die für die lesende Person formuliert sind und nicht für den Autor des Parsers.