Daten aus JSON, XML und CSV sicher importieren

Drei Exporte sollen in dieselbe Anwendung

Die Nordhafen Gebäudetechnik führt Wartungsdaten aus drei bestehenden Systemen zusammen. Ein Messgerät exportiert JSON, die Auftragsverwaltung liefert XML und ein externer Dienstleister schickt eine CSV-Datei. Jeder Datensatz soll am Ende dieselben Angaben enthalten:

• die Gerätekennung als Text,
• den Zeitpunkt als Text im vereinbarten ISO-Format,
• die Temperatur als Zahl,
• eine optionale Notiz als Text.

Der Import darf einen Datensatz nicht einfach übernehmen, nur weil sich die Datei öffnen lässt. Er muss prüfen, ob die Zeichen lesbar sind, die Syntax stimmt, alle benötigten Felder vorhanden sind und die Werte fachlich brauchbar sind. Erst danach werden die Daten in die gemeinsame Zielstruktur überführt.

Du brauchst dafür keine Vorkenntnisse in einer bestimmten Programmiersprache. Die kurzen JavaScript-Beispiele zeigen den Ablauf, nicht den Aufbau einer vollständigen Anwendung. Nach der Lektion kannst du Austauschdateien lesen, typische Fehler einordnen und eine Formatentscheidung aus Anforderungen ableiten.

Ein Format ordnet Werte nach Regeln

Ein Datenformat legt fest, wie Werte in einer Datei oder Nachricht dargestellt und voneinander getrennt werden. Ein Parser liest diese Darstellung und erzeugt daraus Werte, mit denen ein Programm arbeiten kann.

Die Form allein garantiert noch keine brauchbaren Daten. Der JSON-Text {"temperatureC": -800} kann syntaktisch korrekt sein, obwohl die Temperatur für das Wartungsszenario unplausibel ist. Darum trennen wir vier Prüfungen:

1. Encoding: Lassen sich die gespeicherten Bytes als die vereinbarten Zeichen lesen?
2. Syntax: Hält die Datei die Regeln ihres Formats ein?
3. Struktur und Datentypen: Sind die erwarteten Felder vorhanden und haben sie die vereinbarte Form?
4. Fachliche Gültigkeit: Passen Werte und Zusammenhänge zur betrieblichen Anforderung?

Diese Reihenfolge spart Umwege. Solange die Datei nicht zuverlässig dekodiert und geparst ist, kann die Anwendung ihre fachlichen Werte nicht sinnvoll prüfen.

JSON bildet Objekte und Listen kompakt ab

Die JavaScript Object Notation (JSON) stellt Werte als Objekte, Listen und einfache Datentypen dar. Das Messgerät liefert eine Liste mit zwei Messungen:

{
  "measurements": [
    {
      "deviceId": "KLIMA-17",
      "capturedAt": "2026-07-10T08:15:00Z",
      "temperatureC": 22.4,
      "note": null
    },
    {
      "deviceId": "KLIMA-21",
      "capturedAt": "2026-07-10T08:20:00Z",
      "temperatureC": 24.1,
      "note": "Filter prüfen"
    }
  ]
}

Geschweifte Klammern begrenzen ein Objekt aus Schlüssel-Wert-Paaren. Eckige Klammern begrenzen eine Liste, die in JSON Array heißt. Schlüssel und Textwerte stehen in doppelten Anführungszeichen. Zahlen stehen ohne Anführungszeichen. null drückt aus, dass hier kein Wert vorliegt.

JSON kennt die einfachen Wertarten Zeichenkette, Zahl, Wahrheitswert und null. Dazu kommen Objekte und Arrays. Ein eigener Datumstyp gehört nicht dazu. capturedAt ist deshalb zunächst Text. Erst eine zusätzliche Vereinbarung macht daraus einen Zeitstempel im ISO-Format.

Ein häufiger Fehler entsteht, wenn ein Zahlenwert wie Text geschrieben wird:

{
  "deviceId": "KLIMA-17",
  "temperatureC": "22.4"
}

Dieses Dokument ist gültiges JSON. Für eine Anwendung, die mit temperatureC rechnen soll, ist der Datentyp trotzdem falsch. Der Parser prüft die Formatregeln, nicht automatisch den fachlich erwarteten Typ.

XML macht Hierarchie und Benennung ausdrücklich sichtbar

Die Auftragsverwaltung liefert dieselben Arten von Angaben als Extensible Markup Language (XML). Elemente werden durch öffnende und schließende Tags begrenzt:

<?xml version="1.0" encoding="UTF-8"?>
<measurements>
  <measurement>
    <deviceId>KLIMA-17</deviceId>
    <capturedAt>2026-07-10T08:15:00Z</capturedAt>
    <temperatureC>22.4</temperatureC>
    <note />
  </measurement>
</measurements>

XML bildet verschachtelte Strukturen deutlich ab. Im Vergleich zum JSON-Beispiel stehen Zahlen und Zeitangaben im Dokument zunächst als Zeicheninhalt. Ein XML-Schema kann zusätzliche Regeln für Elemente, Reihenfolge und Datentypen beschreiben. Ohne ein solches Schema muss die importierende Anwendung diese Vereinbarungen selbst prüfen.

Ein XML-Dokument ist wohlgeformt, wenn es die grundlegenden XML-Regeln einhält. Es hat zum Beispiel genau ein Wurzelelement, korrekt geschlossene Tags und eine saubere Verschachtelung. Gültig bedeutet zusätzlich, dass es zu einer festgelegten Dokumentbeschreibung wie einem XML-Schema oder einer Document Type Definition passt.

<measurement>
  <deviceId>KLIMA-17</deviceId>
  <temperatureC>22.4</measurement>
</temperatureC>

Dieses Beispiel ist nicht wohlgeformt. Die Elemente überschneiden sich. Geöffnet wurde zuerst measurement, dann temperatureC. Geschlossen werden müsste deshalb zuerst temperatureC und danach measurement.

CSV passt zu flachen Tabellen

Der Dienstleister liefert eine Comma-Separated-Values-Datei (CSV). Jede Zeile steht für einen Datensatz, die Felder werden durch ein vereinbartes Trennzeichen getrennt:

device_id;captured_at;temperature_c;note
KLIMA-17;2026-07-10T08:15:00Z;22.4;
KLIMA-21;2026-07-10T08:20:00Z;24.1;"Filter prüfen; Termin abstimmen"

Obwohl der Name ein Komma nennt, verwenden viele Exporte ein Semikolon. Das Format allein verrät das Trennzeichen nicht zuverlässig. Sender und Empfänger müssen es vereinbaren. Dasselbe gilt unter anderem für Spaltennamen, Dezimaltrennzeichen, Zeilenenden und Zeichenkodierung.

Die Anführungszeichen in der zweiten Datenzeile sind nötig, weil die Notiz selbst ein Semikolon enthält. Ohne die Anführungszeichen würde ein Parser daraus zwei Felder machen. Ein doppeltes Anführungszeichen innerhalb eines umschlossenen Feldes wird üblicherweise verdoppelt:

KLIMA-21;2026-07-10T08:20:00Z;24.1;"Hinweis: ""Filter prüfen"""

CSV trägt keine Datentypen. 22.4, true und 2026-07-10 kommen zunächst als Zeichenfolgen an. Der Import muss sie anhand der Spaltenvereinbarung umwandeln. Verschachtelte Listen oder Objekte lassen sich in CSV nur durch zusätzliche, oft schwer lesbare Regeln abbilden.

Die Anforderung entscheidet über das Format

Keines der drei Formate ist allgemein das beste. Eine begründete Auswahl verbindet konkrete Anforderungen mit Eigenschaften des Formats.

Für die flache Liste des Dienstleisters kann CSV passend sein, wenn die beteiligten Systeme Trennzeichen und Spalten eindeutig vereinbaren. Für das Messgerät ist JSON geeignet, weil mehrere Messobjekte mit Zahlen und optionalen Werten kompakt übertragen werden. XML trägt den hierarchischen Export der Auftragsverwaltung und kann gegen eine festgelegte Dokumentstruktur geprüft werden.

Die Dateigröße allein reicht selten als Entscheidung. Komprimierung, vorhandene Bibliotheken, Wartbarkeit und die Fähigkeiten der Zielsysteme können wichtiger sein. Formuliere deshalb zuerst, was übertragen und geprüft werden soll. Danach lässt sich das Format begründen.

Encoding entscheidet, welche Zeichen ankommen

Eine Datei speichert Bytes. Eine Zeichenkodierung, oft kurz Encoding genannt, ordnet diese Bytes Zeichen zu. Sender und Empfänger müssen dieselbe Kodierung verwenden. UTF-8 kann die Zeichen aus den Beispielen darstellen und ist für den systemübergreifenden Austausch eine verbreitete Vereinbarung.

Wenn eine XML-Deklaration encoding="UTF-8" nennt, die Datei aber tatsächlich mit einer anderen Kodierung gespeichert wurde, widersprechen Angabe und Inhalt einander. Für JSON-Austausch außerhalb geschlossener Systemumgebungen fordert RFC 8259 UTF-8. Für CSV sollte die Kodierung ausdrücklich vereinbart werden, weil ältere Exporte weiterhin abweichende Annahmen verwenden können.

Zeichen wie ä, ß oder ° eignen sich für einen frühen Test. Aus Gerät wird bei einer falschen Dekodierung zum Beispiel ein beschädigter Text. Eine spätere Ersetzung einzelner Zeichen behebt die Ursache nicht zuverlässig. Der Import braucht die richtige Kodierung bereits beim Lesen der Bytes.

Aus drei Eingaben wird eine Zielstruktur

Eine Transformation ordnet Werte aus der Quellstruktur einer gemeinsamen Zielstruktur zu. Dazu brauchst du für jedes Format eine kleine Zuordnung:

Nach dem Parsen kann die CSV-Zeile beispielsweise als Objekt mit Textwerten vorliegen. Die Transformationsfunktion prüft die erwarteten Felder und wandelt die Temperatur um:

function transformCsvRow(row) {
  const rawTemperature = row.temperature_c?.trim()

  if (!row.device_id || !row.captured_at) {
    throw new Error("Gerätekennung oder Zeitpunkt fehlt")
  }

  if (rawTemperature === undefined || rawTemperature === "") {
    throw new Error("Temperatur fehlt")
  }

  const temperatureC = Number(rawTemperature)

  if (!Number.isFinite(temperatureC)) {
    throw new Error("Temperatur ist keine endliche Zahl")
  }

  if (temperatureC < -40 || temperatureC > 80) {
    throw new Error("Temperatur liegt außerhalb des Messbereichs")
  }

  return {
    deviceId: row.device_id,
    capturedAt: row.captured_at,
    temperatureC,
    note: row.note || null,
  }
}

Die Funktion setzt voraus, dass ein CSV-Parser die Zeile bereits anhand des vereinbarten Trennzeichens und der Maskierungsregeln gelesen hat. Die eigene Prüfung auf ein leeres Feld ist nötig, weil JavaScript leeren Text mit Number("") sonst in 0 umwandelt. Number.isFinite() verhindert anschließend Werte wie NaN und unendliche Zahlen. Der Temperaturbereich ist eine neue fachliche Regel des Szenarios, keine Eigenschaft von CSV.

Auch capturedAt braucht in einer vollständigen Importstrecke eine Prüfung gegen das vereinbarte Zeitformat. Diese Lektion lässt den Wert als Text stehen, damit der Unterschied zwischen Formatverarbeitung und umfassender Datumslogik sichtbar bleibt.

Entwickle einen Importplan für eine neue Quelle

{
  "meterId": "ENERGIE-04",
  "capturedAt": "2026-07-10T09:00:00Z",
  "energyKwh": 1842.7
}

{
  "meterId": "ENERGIE-04",
  "capturedAt": "2026-07-10T09:00:00Z",
  "energyKwh": "unbekannt"
}

Das nimmst du mit

JSON, XML und CSV lösen denselben Austauschbedarf auf unterschiedliche Weise. JSON bildet Objekte, Listen und einfache Datentypen kompakt ab. XML stellt benannte Hierarchien ausdrücklich dar und kann gegen eine Dokumentbeschreibung geprüft werden. CSV passt besonders zu flachen Tabellen, braucht aber klare Vereinbarungen zu Spalten, Trennzeichen, Maskierung und Encoding.

Ein erfolgreicher Parse ist nur der Anfang. Ein verlässlicher Import dekodiert die Bytes richtig, prüft die Syntax, kontrolliert Struktur und Datentypen und wendet danach fachliche Regeln an. Erst geprüfte Werte werden in die gemeinsame Zielstruktur transformiert.

Damit kannst du Daten aus vorhandenen Quellen zusammenführen. Wie eine API diese Daten transportiert und wie eine Anwendung ihre fachlichen Beziehungen modelliert, bleibt eine getrennte Entwurfsentscheidung.

Belegmatrix