Gültig

Validierung als Akzeptanz- oder Ablehnungs-Parsing

Bevor eine Anwendung einem Dokument vertraut, muss sie eine engere Frage beantworten: Ist dieser Text für das behauptete Format wohlgeformt? Validierung in dieser Familie bedeutet syntaktische und strukturelle Prüfungen—kann ein standardsbewusster Parser die Eingabe fehlerfrei verarbeiten—, nicht vollständige Geschäftsregeln oder Schema-Zertifizierung (es sei denn, die Definition von „gültig“ für ein Format schließt das Schema bereits ein).

Die Valid-Tools teilen diese Aufgabe für HTML, XML, SVG, JSON, YAML und CSV. Beginnen Sie mit Valid JSON, wenn Sie API-Payloads debuggen; dasselbe Prinzip gilt für Markup und tabellarischen Text bei den unten genannten Geschwistern.

Was „gültig“ je nach Format bedeutet

Formate unterscheiden sich darin, wie tief „gültig“ reicht:

• JSON — ECMA-404 / RFC 8259 Grammatik: passende Klammern, in Anführungszeichen gesetzte Schlüssel, keine nachgestellten Kommas, zulässige Zahlenformen. Ein standardmäßiger „JSON Schema“-Schritt ist in reiner Parse-Validierung nicht enthalten.
• YAML — YAML 1.1/1.2 Ladefähigkeit: Einrückungsstruktur, erlaubte Tags und Skalarstile. YAML kann Typen und Anker ausdrücken, die JSON nicht kann; ein erfolgreiches Laden ist nicht dasselbe wie „sicher, nicht vertrauenswürdiges YAML zu laden“ in jeder Laufzeitumgebung.
• XML — Wohlgeformtheit (passende Tags, gültige Namen, Entitätsregeln). Schema-Gültigkeit (XSD/DTD) ist eine separate, strengere Schicht.
• HTML — lebende HTML-Parsing-Regeln unterscheiden sich von XHTML. Validatoren können je nach Konformitätsprofil des Engines nicht geschlossene Elemente, falsch platzierte Tags oder veraltete Konstrukte melden.
• SVG — XML-basiertes Grafikvokabular. Wohlgeformtes XML ist nötig; gültiges SVG impliziert auch korrekte Elementverschachtelung und Attribute für den SVG-Namespace, wobei leichtgewichtige Tools oft zuerst Parse-/Wohlgeformtheitsprüfungen fokussieren.
• CSV — Zeilen von Feldern, getrennt durch ein Trennzeichen (oft Komma) mit Anführungsregeln (RFC 4180 Familie). „Gültig“ bedeutet meist konsistente Spaltenanzahlen, korrektes Escaping von Anführungszeichen und lesbare Kodierung—nicht, dass Zellwerte einem Geschäftsschema entsprechen.

Zu wissen, welche Schicht Sie brauchen, verhindert falsches Vertrauen: wohlgeformtes XML kann trotzdem eine Branchen-XSD verletzen; parsebares JSON kann trotzdem Pflichtfelder vermissen.

Subtools in dieser Familie

• Valid HTML — HTML-Markup auf Parser-Ebene typischer Probleme in Seiten und Fragmenten prüfen.
• Valid XML — wohlgeformte XML-Dokumente und Snippets prüfen.
• Valid SVG — SVG-Quelltext als strukturiertes Grafik-Markup prüfen.
• Valid JSON — JSON-Text nach Standard-Grammatikregeln akzeptieren oder ablehnen.
• Valid YAML — YAML parsen und Ladefehler bzw. Strukturfehler anzeigen.
• Valid CSV — getrennten tabellarischen Text auf strukturelle Konsistenz prüfen.

Wählen Sie das Tool, das zu Content-Type oder Dateierweiterung passt, die Sie tatsächlich haben. Validieren Sie YAML nicht mit einem JSON-Parser oder HTML nicht mit einem reinen XML-Checker, es sei denn, Sie verlangen absichtlich die strengere Variante (z. B. XHTML).

Warum browserseitige Validierung hilft

Lokale Validierung verkürzt die Feedback-Schleife beim Erstellen von Fixtures, Bearbeiten von CMS-Fragmenten oder Prüfen eines kopierten Response-Bodys. Sie sehen zeilenorientierte Fehler, bevor Sie Dateien committen oder Konfigurationen deployen. Das Dokument im Browser zu halten, vermeidet auch das Hochladen sensibler Entwürfe an einen Remote-Lint-Dienst—obwohl Zwischenablage und Bildschirmfreigabe Inhalte weiterhin preisgeben können.

Validierung ergänzt Unit-Tests: Tests sollten in CI weiterhin kanonische Fixtures mit denselben Bibliotheken prüfen, die Ihre Produktionsparser nutzen. Online-Checks dienen der Erkundung und Triage; CI dient der Regression.

Fehlerformen, die man erkennen sollte

JSON. Unerwartetes Token, nicht abgeschlossene Zeichenkette, nachgestelltes Komma, einfache Anführungszeichen, NaN. Editoren, die JSONC akzeptieren, bestehen lokal und scheitern in strikten Produktionsparsern.

YAML. Tabs vs. Leerzeichen, falsche Einrückung unter einem Schlüssel, mehrdeutige unquoted Strings (on/off-Booleanisierung in YAML 1.1) und doppelte Schlüssel je nach Loader-Einstellungen.

XML/SVG. Nicht passende End-Tags, rohes < im Text, undefinierte Präfixe, mehrere Top-Level-Elemente oder unzulässige Steuerzeichen. SVG-Dateien, die als HTML-eingebettete Fragmente gedacht sind, können als eigenständige XML-Dokumente scheitern.

HTML. Überlappende Tags, veraltete Attribute und Fehler bei Void-Elementen. HTML-Parser reparieren oft; ein Validator, der Probleme meldet, kann trotzdem einen Baum beschreiben, den ein Browser rendert—behandeln Sie Warnungen als Qualitätssignale, nicht immer als harte Laufzeitfehler.

CSV. Nicht escapte Anführungszeichen, eingebettete Zeilenumbrüche in Feldern ohne Quoting, gemischte Trennzeichen (Komma vs. Semikolon) und unregelmäßige Zeilen mit abweichender Spaltenanzahl.

Validierung versus Transformation

Validatoren antworten mit ja/nein (und wo es scheiterte). Formatter und Konverter ändern Bytes. Ein Dokument kann ungültig sein und im nachsichtigen HTML-Parser eines Browsers trotzdem „in Ordnung aussehen“, oder gültiges JSON sein und dennoch für Ihr API-Schema falsch. Typische Pipeline:

1. Syntax für das behauptete Format validieren.
2. Optional gegen ein Schema (JSON Schema, XSD usw.) im Anwendungscode validieren.
3. Erst dann transformieren, mergen oder persistieren.

Schritt 1 zu überspringen verschwendet Zeit mit mysteriösen Transformationsfehlern, die von Anfang an Parse-Fehler waren.

Sicherheitshinweise je Format

• XML: Billion Laughs / Entitäts-Expansion und externe Entitäten (XXE) sind relevant, wenn Parser DTDs oder Entitäten auflösen. Bevorzugen Sie Parser mit deaktivierten externen Entitäten für nicht vertrauenswürdige Eingaben.
• YAML: manche Loader können beliebige Objekte konstruieren (!!python/object-artige Tags). Bevorzugen Sie safe-load-APIs für nicht vertrauenswürdiges YAML.
• HTML/SVG: Script- und Event-Handler-Attribute sind eine XSS-Oberfläche, wenn Markup in Seiten eingebettet wird. Validierung ≠ Sanitisierung.
• CSV: Formel-Injektion in Tabellenkalkulations-Clients (=CMD(...)) ist relevant, wenn CSV in Excel geöffnet wird; strukturelle Gültigkeit neutralisiert das nicht.
• JSON: generell sicherer zu parsen als die obigen Formate, aber riesige Payloads können dennoch Speicher-DoS verursachen; begrenzen Sie die Größe auf Servern.

Praktische Workflows

• Fügen Sie einen API-Fehlerbody in Valid JSON ein, bevor Sie Anwendungslogik beschuldigen.
• Prüfen Sie ein Kubernetes- oder CI-Konfigurationsfragment mit Valid YAML, wenn die Einrückung verdächtig wirkt.
• Bestätigen Sie einen Export aus einer Tabelle mit Valid CSV, bevor Sie einen Importer schreiben.
• Verifizieren Sie handbearbeitete Icons mit Valid SVG, bevor Sie sie bündeln.

Einschränkungen

Diese Tools ersetzen keine Domänenschemata, Barrierefreiheits-Audits oder vollständige HTML-Konformitätssuiten (z. B. jeden WHATWG-Check). Sie beweisen nicht, dass XML eine bestimmte XSD erfüllt, JSON OpenAPI erfüllt oder CSV-Spalten einem Datenbank-DDL entsprechen. Sie sanitisieren auch keine aktiven Inhalte. Nutzen Sie sie als erstes Tor: Struktur zuerst, Bedeutung danach.

Verwandte Werkzeuge

Nach erfolgreicher JSON-Validierung nutzen Sie Pretty-print JSON für Layout oder From JSON to XML für Baumprojektion. Validierung sagt, ob das Dokument verdaulich ist; andere Familien entscheiden, was gekocht wird.