ForHosting KIT · Entwickler-Tools

YAML-Einrückung und Syntax mit Zeilennummern prüfen

Finden Sie die Strukturfehler, die eine YAML-Datei zerbrechen: Im Beispiel ergeben port, in Zeile 4 nach Zeile 3 wiederholt, und ein Tabulator in Zeile 5 genau 2 Befunde, jeweils mit Zeile und klarer Erklärung. Kostenlos in Ihrem Browser.

Kostenlos
Läuft in Ihrem Browser
Ohne Anmeldung
Ihre Daten bleiben auf Ihrem Gerät

Im Browser ausführen – kostenlos API ansehen

Nutzen Sie es über WebAPIE-MailTelegramApp bald

Rechenbeispiel

Wenn Sie eingeben

Text: service: name: api port: 8080 port: 9090 debug: true

Erhalten Sie

Anzahl der Fehler: 2

Dieser Prüfer für YAML-Einrückung und -Syntax erkennt kleine Strukturfehler, die Konfigurationsdateien unzuverlässig machen: verborgene Tabulatoren am Zeilenanfang, unerwartete Änderungen der Einrückungstiefe und wiederholte Schlüssel in derselben Zuordnung. Jeder Fund nennt die Quellzeile, sodass Sie direkt zur fehlerhaften Einstellung gelangen. Text, der sich überhaupt nicht als YAML interpretieren lässt, wird abgelehnt. Dadurch bleibt eine missgebildete Eingabe klar von einem gültigen Dokument mit bloßen Lint-Hinweisen getrennt.

Nutzen Sie einen gezielten Bericht statt rätselhafter Parsermeldungen

Fügen Sie das vollständige YAML-Dokument in das Textfeld ein und starten Sie die Prüfung. Das Ergebnis zeigt, ob es bestanden hat, nennt die Anzahl der Funde und führt jedes Problem mit einer bei eins beginnenden Zeilennummer, einem stabilen Typ und einer Erklärung auf. Dieses kompakte Format eignet sich für Menschen, die eine Bereitstellungsdatei prüfen, ebenso wie für Skripte zur Kontrolle erzeugter Konfigurationen.

Der Prüfer konzentriert sich auf drei häufige Gefahren: Tabulatoren im führenden Leerraum, deren Breite zwischen Editoren variiert; Einrückungswechsel, die nicht zur übergeordneten Struktur passen; und doppelte Schlüssel innerhalb desselben Geltungsbereichs. Gleichnamige Schlüssel in getrennten Objekten bleiben zulässig. Kommentare und Leerzeilen verschieben die Verweise nicht.

Eine saubere Antwort enthält ein leeres Fehlerarray statt Platzhaltern und lässt sich daher unmittelbar als erfolgreiche Schranke in Builds oder Abläufen vor einem Commit verwenden.

Unterscheiden Sie Lint-Funde von ungültigen Eingaben

Ein Lint-Fund beschreibt Text, der trotz riskanter Struktur noch sinnvoll untersucht werden kann. Ein Tabulator in der Einrückung oder ein doppelter Schlüssel erzeugt deshalb ein normales Ergebnis mit der betreffenden Zeile. Ein Parserfehler bedeutet dagegen, dass das Dokument für eine verlässliche Strukturanalyse zu unvollständig oder fehlerhaft ist.

Nicht geschlossene Anführungszeichen, ungepaarte Klammern, leere Zuordnungsschlüssel oder einfacher Text an einer Stelle für Zuordnung beziehungsweise Sequenz führen zu einem Fehler wegen ungültiger Eingabe. Diese Trennung hilft bei der Automatisierung: Ihre Integration kann alle behebbaren Funde gemeinsam anzeigen, während ein Parserfehler die Pipeline stoppt. Die Prüfung ist deterministisch, schreibt nichts um, wählt keinen doppelten Wert aus und errät keine beabsichtigte Verschachtelung.

Bei Konfigurationen ist eine stille Bedeutungsänderung oft schlimmer als die Ablehnung. Beheben Sie zuerst den frühesten Parserfehler, prüfen Sie erneut und arbeiten Sie anschließend die nummerierten Hinweise ab.

Setzen Sie die Prüfung sicher in Editoren und Pipelines ein

Der Endpunkt ist für schnelle Kontrollen gedacht, bevor YAML ein Bereitstellungswerkzeug, eine Paketveröffentlichung, einen CI-Auftrag oder den Anwendungsstart erreicht. Senden Sie den genauen Quelltext statt eines bereits geparsten Objekts, da Einrückung und doppelte Schlüssel bei der Umwandlung in gewöhnliche Daten oft verloren gehen. Bewahren Sie Zeilenenden und Kommentare, damit die Positionen mit Ihrem Editor übereinstimmen.

Eine Pipeline kann nach der Vorlagenverarbeitung und vor dem Einfügen von Geheimnissen prüfen und bei valid gleich false oder ungültiger Eingabe fehlschlagen. Identischer Text liefert stabil dieselbe Antwort; Netzwerk, Zufall, Uhrzeit und umgebungsspezifischer Zustand spielen keine Rolle. Begrenzungen für Größe und Zeilen verhindern unbeschränkte Arbeit.

Zulässige Kubernetes-Felder, Workflow-Eigenschaften oder Anwendungsoptionen kennt sie nicht. Kombinieren Sie sie bei Bedarf mit dem schemaspezifischen Validator Ihres Zielsystems.

Anwendungsfälle

Bereitstellungskonfiguration prüfen

Erkennen Sie verschobene Verschachtelung, Tabulatoren und wiederholte Einstellungen, bevor das Bereitstellungswerkzeug die Datei auswertet.

Erzeugtes YAML validieren

Prüfen Sie Vorlagenausgaben im Build und erhalten Sie verwertbare Zeilennummern bei fehlerhaften Strukturen.

Konfigurationsänderungen begutachten

Ergänzen Sie die Codeprüfung um einen schnellen Strukturtest, damit Leerraumfehler nicht in großen Diffs verborgen bleiben.

Häufige Fragen

Was kostet eine Prüfung?

Die Browserversion können Sie direkt auf dieser Seite verwenden.

Verändert der Prüfer mein YAML?

Nein. Er meldet nur Funde und ändert weder Einrückungen noch Schlüssel oder doppelte Werte.

Sind gleiche Schlüssel in verschiedenen Objekten erlaubt?

Ja. Gemeldet wird ein Schlüssel nur bei Wiederholung im selben Zuordnungsbereich.

Warum werden optisch ausgerichtete Tabulatoren gemeldet?

Editoren zeigen sie unterschiedlich breit an; dadurch kann sich die YAML-Verschachtelung zwischen Werkzeugen ändern.

Was unterscheidet einen Befund von einer abgelehnten Datei?

Ein Befund wie ein Tabulator oder ein doppelter Schlüssel erhält trotzdem einen normalen Bericht mit Zeilennummer. Text, der zu kaputt für eine Analyse ist, etwa ein nicht geschlossenes Anführungszeichen oder ein leerer Schlüssel, wird abgelehnt – beheben Sie das zuerst und prüfen Sie erneut.

Für Entwickler — API-Zugang

Alles auf dieser Seite ist auch per API verfügbar. Dieser Abschnitt richtet sich an Teams, die es in ihre eigenen Systeme einbinden möchten; alle anderen nutzen einfach das Tool oben.

Endpunkt

POSThttps://api.kit.forhosting.com/dev2/yaml-lint-basic

Authentifizierung per Bearer-Token. Ein einziger POST stellt die Aufgabe in die Warteschlange; das Ergebnis erhalten Sie per Webhook oder über einen signierten Link.

Aufruf aus Ihrem Stack

curl -X POST https://api.kit.forhosting.com/dev2/yaml-lint-basic \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"text":"service:\n  name: api\n  ports:\n    - 8080\n    - 8081"}'

const res = await fetch("https://api.kit.forhosting.com/dev2/yaml-lint-basic", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "text": "service:\n  name: api\n  ports:\n    - 8080\n    - 8081"
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/dev2/yaml-lint-basic",
    headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
    json={
    "text": "service:\n  name: api\n  ports:\n    - 8080\n    - 8081"
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev2/yaml-lint-basic", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => '{"text":"service:\\n  name: api\\n  ports:\\n    - 8080\\n    - 8081"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"text":"service:\n  name: api\n  ports:\n    - 8080\n    - 8081"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev2/yaml-lint-basic", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Beispiel-Anfrage

{
  "text": "service:\n  name: api\n  ports:\n    - 8080\n    - 8081"
}

Beispiel-Antwort

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "dev2.yaml_lint_basic",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

Die API arbeitet asynchron: Sie erhalten sofort eine task_id. Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Preis

pro Anfrage$0.002

Der Preis steht auf der Seite – keine Tokens, keine Credits. Fehlgeschlagene Aufgaben werden nicht berechnet.

Fehler

HTTP	Code	Bedeutung
`401`	`unauthorized`	Der API-Schlüssel fehlt oder ist ungültig – prüfen Sie den Authorization-Header (Bearer).
`402`	`insufficient_balance`	Ihr Guthaben reicht für diese Aufgabe nicht aus – Aufladungen verfallen nicht.
`404`	`unknown_type`	Unbekannter Aufgabentyp – prüfen Sie das Feld „type“ gegen den Katalog.
`429`	`rate_limited`	Zu viele Anfragen – warten Sie kurz; Polling ist mit 1 Anfrage pro Sekunde erlaubt.

Technische Hinweise

Setzen Sie die Prüfung sicher in Editoren und Pipelines ein

Dies ist bewusst eine grundlegende Strukturprüfung, kein Schema-Validator.

Technische Fragen

Ist dies ein Kubernetes- oder Workflow-Schema-Validator?

Nein. Geprüft werden allgemeine YAML-Struktur und Basissyntax, nicht produktspezifische Felder, Typen oder Regeln.

Vollständige KIT-Dokumentation lesen →

YAML-Einrückung und Syntax mit Zeilennummern prüfen

Im Browser ausführen – kostenlos

Rechenbeispiel

Nutzen Sie einen gezielten Bericht statt rätselhafter Parsermeldungen

Unterscheiden Sie Lint-Funde von ungültigen Eingaben

Setzen Sie die Prüfung sicher in Editoren und Pipelines ein

Anwendungsfälle

Bereitstellungskonfiguration prüfen

Erzeugtes YAML validieren

Konfigurationsänderungen begutachten

Häufige Fragen

Verwandte Tools

Für Entwickler — API-Zugang

Endpunkt

Aufruf aus Ihrem Stack

Beispiel-Anfrage

Beispiel-Antwort

Preis

Fehler

Technische Hinweise

Setzen Sie die Prüfung sicher in Editoren und Pipelines ein

Technische Fragen

danke