Datenaustausch: JSON, XML, CSV

Wenn ein Frontend mit einem Backend redet (L8 REST), wenn Microservices Nachrichten austauschen, wenn ein Bericht in eine Datei exportiert wird – immer braucht es ein gemeinsames Format, in dem die Daten strukturiert übertragen werden. Drei Formate dominieren die Praxis: JSON für moderne APIs, XML für Enterprise- und Dokument-Welt, CSV für Tabellendaten und Excel-Exporte.

Jedes hat eine eigene Geschichte, eigene Stärken und Schwächen, und sehr unterschiedliche Use-Cases. In dieser Lektion lernst du alle drei lesen und schreiben, ihre Unterschiede einzuordnen, und in jeder IHK-Klausurfrage souverän das richtige Format zu wählen.

1) Wozu Datenformate?

Im Computer sind Daten zunächst nur Bytes – ein Strom von Nullen und Einsen. Damit ein anderes System sie verstehen kann, brauchen beide Seiten dasselbe Format: eine vereinbarte Konvention, wie Strukturen, Werte und Beziehungen in Text dargestellt werden. Ein gutes Datenformat ist:

• Maschinenlesbar: programme können es parsen, ohne raten zu müssen.
• Selbstbeschreibend: wer den Inhalt liest, versteht die Struktur ohne Zusatz-Dokumentation.
• Plattform-neutral: ein Java-Server und ein Python-Client können dieselben Daten austauschen.
• Textbasiert (in der Regel): debuggbar, mit jedem Editor lesbar.

Genau das leisten JSON, XML und CSV – jedes auf seine Art.

2) Dasselbe Beispiel in drei Formaten

Bevor wir Details vergleichen, schauen wir uns denselben Datensatz in allen drei Formaten an. Beispiel: zwei Produkte mit ID, Name, Preis und Kategorien. Klick die Tabs:

3) JSON: das Format für moderne APIs

JSON steht für JavaScript Object Notation. Erfunden in den 2000ern als kompaktes Format für JavaScript-Anwendungen, ist es heute das Standard-Format für REST-APIs. JSON kennt nur sehr wenige Datentypen – und genau diese Einfachheit ist seine Stärke:

Wichtige Syntax-Regeln: Schlüssel sind immer Strings in Anführungszeichen (doppelte, keine einfachen!). Werte werden durch Kommas getrennt. Nach dem letzten Element kein Komma (sonst Syntaxfehler). String-Werte ebenfalls in doppelten Anführungszeichen. Diese Strenge erleichtert das Parsen – jeder JSON-Parser folgt denselben Regeln.

4) JSON in Aktion: parsen und manipulieren

Probier es aus: gib einen JSON-Text ein und sieh, ob er gültig ist. Bei Fehlern zeigt der Parser, wo's klemmt:

5) XML: das Format für Enterprise und Dokumente

XML (eXtensible Markup Language) ist deutlich älter als JSON – aus den späten 90ern. Es wurde geschaffen, um sowohl Daten als auch Dokumente zu beschreiben, und ist bis heute Standard in Bankenfachsystemen, ERP-Systemen, Behörden-Schnittstellen und Konfigurationsdateien.

XML sieht aus wie HTML: alles steht in Tags mit Öffnungs- (<tag>) und Schluss-Element (</tag>). Attribute werden direkt am Öffnungs-Tag angebracht: <produkt id="1">. Verschachtelung beliebig tief möglich. Im Unterschied zu HTML sind die Tag-Namen frei wählbar – jede Anwendung definiert ihre eigenen.

Stärken von XML: sehr ausdrucksstark (Attribute + Inhalte), strenge Validierung über XSD-Schemata, Transformation über XSLT, sehr verbreitet in Enterprise-Umgebungen. Schwächen: ausführlich (viel Boilerplate), unhandlich zu lesen, kein nativer Boolean- oder Number-Typ (alles sind Strings, die du selbst interpretieren musst).

Spezialfall: Namespaces. Wenn zwei XML-Welten zusammenkommen (z.B. ein Bank-Schema und ein Adress-Schema), können Tag-Namen mit Präfixen versehen werden: <bank:konto> vs. <adresse:konto>. Das ist in IHK-Klausuren selten konkret gefragt, aber als Begriff wichtig.

6) XML-Beispiel mit Schema-Validierung

Ein großer Vorteil von XML: man kann den erwarteten Aufbau mit einem XSD-Schema formal beschreiben. Ein Schema definiert: welche Elemente gibt es, welche Datentypen, welche sind Pflicht. Beim Parsen wird automatisch validiert.

Konkretes Beispiel: ein XSD könnte vorschreiben, dass jedes <produkt>-Element ein id-Attribut vom Typ Integer und genau ein <name>-Element vom Typ String enthält. Verstößt eine XML-Datei dagegen, wird sie nicht akzeptiert. Das ist eine erhebliche Daten-Integritäts-Garantie – und in regulierten Branchen (Finanzen, Gesundheit) wertvoll. JSON kennt mit JSON-Schema ein analoges Konzept, aber XSD ist deutlich verbreiteter.

7) CSV: das Tabellen-Format

CSV steht für Comma-Separated Values – Komma-getrennte Werte. Es ist das einfachste der drei Formate: jede Zeile ein Datensatz, Felder durch Trennzeichen separiert. Klassische CSV-Datei:

Tücken von CSV: das Format wirkt einfach, ist aber im Detail überraschend tückisch. Was, wenn ein Wert ein Komma enthält? Antwort: in Anführungszeichen setzen: 1,"Müller, Hans",30. Was, wenn der Wert selbst Anführungszeichen enthält? Verdoppeln: "Er sagte ""Hallo""". Welches Trennzeichen? In Deutschland oft Semikolon statt Komma – weil Deutsch Komma als Dezimaltrenner verwendet. Welches Zeilenende? Windows (CRLF) oder Unix (LF) – mischen sorgt für Bugs.

Außerdem: CSV kann keine Verschachtelung. Wenn ein Datensatz selbst eine Liste enthält (z.B. mehrere Kategorien), muss man tricksen – z.B. mit einem zweiten Trennzeichen wie Semikolon innerhalb des Feldes. Das ist hackig und fehleranfällig.

8) Direktvergleich der drei Formate

Damit du in jeder Klausur-Frage das richtige Format wählst, hier die wichtigsten Kriterien nebeneinander:

9) Wann welches Format? – Use-Case-Übersicht

Eine klare Entscheidungshilfe für die Praxis:

10) Zeichenkodierung: das vergessene Thema

Ein Punkt, der in Klausuren und in der Praxis gerne untergeht: die Zeichenkodierung. Wie werden Umlaute, Sonderzeichen, Emojis gespeichert? Standard heute: UTF-8. Damit lassen sich praktisch alle Zeichen der Welt darstellen – Latein, Kyrillisch, Chinesisch, Emojis.

Probleme entstehen, wenn Sender und Empfänger unterschiedliche Kodierungen verwenden. Klassiker: ein CSV-Export ist UTF-8, Excel öffnet es aber als Windows-1252 → aus „Müller" wird „Müller". XML deklariert die Kodierung in der ersten Zeile: <?xml version="1.0" encoding="UTF-8"?>. JSON ist per Definition UTF-8 (laut RFC 8259). CSV hat keine Deklaration – hier muss man wissen, was der Sender verwendet.

Empfehlung für die Praxis: alles immer UTF-8. Andere Kodierungen nur, wenn der Geschäftspartner es explizit verlangt.

11) Datenformate in der praktischen Verarbeitung

In jeder Programmiersprache gibt es Standardbibliotheken zum Lesen und Schreiben dieser Formate. Ein paar Beispiele:

• Java: Jackson oder Gson für JSON, JAXB/DOM/SAX für XML, OpenCSV für CSV.
• Python: json-Modul (eingebaut!), xml.etree.ElementTree, csv-Modul oder die mächtige pandas-Bibliothek.
• JavaScript: JSON.parse() und JSON.stringify() nativ eingebaut. XML mit DOMParser. CSV oft mit Bibliotheken wie papaparse.
• C#: System.Text.Json oder Newtonsoft.Json, XmlSerializer, CsvHelper.

In der Klausur wird selten konkreter Code abgefragt, aber gerne die Konzepte: Serialisierung (Objekt → Text) und Deserialisierung (Text → Objekt). Diese Begriffe sollten dir geläufig sein.

12) Typische Klausurfehler

Zusammenfassung

Diese Lektion behandelte die drei wichtigsten Datenaustauschformate. JSON (JavaScript Object Notation): kompakt, web-nativ, Standard für moderne REST-APIs. Datentypen: String, Number, Boolean, null, Array, Object. Strenge Syntax: doppelte Anführungszeichen für Schlüssel und String-Werte, keine Trailing Commas, keine Kommentare. Per Definition UTF-8. XML (eXtensible Markup Language): ausdrucksstark, ausführlich, Standard in Enterprise (Banken, Behörden, SAP), für SOAP-Webservices, Konfiguration in Java-Welt, Dokumentenformate. Tag-Struktur mit Öffnungs- und Schluss-Tags, Attribute, beliebige Verschachtelung. Strenge Validierung über XSD-Schemata. Namespaces für Tag-Konflikte. Kodierung im Prolog deklariert. CSV (Comma-Separated Values): einfach, tabellarisch, direkter Excel-Import/Export. Erste Zeile typisch Header, danach ein Datensatz pro Zeile. Tücken: Komma in Feldern (Anführungszeichen), Anführungszeichen in Feldern (verdoppeln), Trennzeichen in DE oft Semikolon, Zeilenende-Variationen. Keine Verschachtelung möglich – Schwachpunkt gegenüber JSON/XML. Vergleich: JSON ist der Mittelweg (strukturreich + kompakt), XML maximal ausdrucksstark (aber ausführlich), CSV maximal kompakt (aber strukturarm). Use-Cases: JSON für APIs / Mobile / NoSQL (z.B. MongoDB), XML für SOAP / Banken / XRechnung / DOCX, CSV für Excel / Datenanalyse / Pandas / Daten-Dumps. Zeichenkodierung: heute Standard UTF-8. JSON ist per Definition UTF-8, XML deklariert es im Prolog, CSV hat keine Standard-Deklaration. Klausur-Fehler: einfache Anführungszeichen in JSON, Trailing Comma, XML-Schluss-Tags vergessen, CSV mit Komma im Feld, „JSON erlaubt Kommentare" (nein), „XML = HTML" (falsch). Die Begriffe Serialisierung (Objekt → Text) und Deserialisierung (Text → Objekt) sind in allen drei Welten zentral. Diese drei Formate begegnen dir täglich, wenn du eine Schichtenarchitektur aufbaust oder Microservices miteinander reden lässt. Die nächste Lektion fasst den ganzen Kurs zusammen: IHK-Aufgaben Softwarearchitektur mit Aufgabenblöcken, MC-Quiz und Cheatsheet.