Produktionsdaten wechseln in Druckereien ständig das System. Ein Webshop übergibt Bestellungen, ein MIS plant Arbeitsgänge, die Vorstufe verarbeitet Jobtickets und das ERP erwartet Material- oder Rechnungsdaten. Häufig fällt dabei früh die Frage: Sollen die Informationen als XML, CSV oder JSON ausgetauscht werden?
Die richtige Antwort hängt nicht vom modernsten Format ab, sondern von Struktur, Umfang und Verwendung der Daten. Dieser Artikel vergleicht die drei Formate aus Sicht realer Druck- und Medienworkflows. Außerdem erfährst du, welche Regeln für einen zuverlässigen Austausch wichtiger sind als die Dateiendung.
Ein Datenformat ist noch keine Schnittstelle
CSV, XML und JSON beschreiben, wie Daten strukturiert werden. Sie legen aber nicht automatisch fest, wann eine Übertragung stattfindet, welches System verantwortlich ist oder wie Fehler zurückgemeldet werden. Dafür braucht es zusätzlich einen Transportweg und einen fachlichen Vertrag.
- Eine REST-API kann JSON oder XML liefern.
- Ein SFTP-Verzeichnis kann CSV-, XML- oder JSON-Dateien aufnehmen.
- Eine Nachrichtenwarteschlange kann einzelne Ereignisse in unterschiedlichen Formaten transportieren.
- JDF und XJDF definieren zusätzlich ein druckspezifisches Datenmodell.
Bevor du ein Format auswählst, solltest du deshalb Dateninhalt, Auslöser, Zielsystem, Rückmeldung und Fehlerbehandlung kennen. Der Artikel MIS, ERP und Webshop verbinden zeigt, wie diese Verantwortung im Gesamtprozess verteilt wird.
CSV, XML und JSON im direkten Vergleich
| Kriterium | CSV | XML | JSON |
|---|---|---|---|
| Datenstruktur | Zeilen und Spalten | Hierarchische Elemente und Attribute | Objekte und Listen |
| Datentypen | Nicht eindeutig im Format | Über Schema detailliert definierbar | Grundtypen wie Text, Zahl und Wahrheitswert |
| Validierung | Nur mit zusätzlicher Definition | Ausgereift über XML Schema | Über zusätzliche Schemas möglich |
| Lesbarkeit | Sehr gut bei einfachen Tabellen | Gut, aber umfangreich | Kompakt und gut lesbar |
| Typischer Einsatz | Listen, Exporte, Stapelimporte | Jobtickets und komplexe Fachmodelle | Web-APIs und Anwendungsdaten |
Die Tabelle zeigt eine Orientierung, keine Rangfolge. Ein sauber definierter CSV-Import kann zuverlässiger sein als eine unvollständig dokumentierte API. Umgekehrt wird eine verschachtelte Produktkonfiguration in CSV schnell unübersichtlich.
CSV: stark für einfache Listen und Stapelimporte
CSV steht für Comma-Separated Values. Datensätze werden zeilenweise gespeichert, Felder durch ein Trennzeichen getrennt. Das Format eignet sich besonders für gleichartige, tabellarische Daten. Typische Beispiele sind Papierstammdaten, Preislisten, Adressen, Lagerbestände oder einfache Betriebsdatenauszüge.
In der Praxis ist das Trennzeichen nicht immer ein Komma. Im deutschsprachigen Umfeld wird wegen des Dezimalkommas häufig ein Semikolon verwendet. Auch Zeichencodierung, Datumsformat und Kopfzeile müssen vereinbart werden. RFC 4180 dokumentiert ein verbreitetes CSV-Verhalten, beseitigt aber nicht die unterschiedlichen Konventionen vorhandener Programme.
Wann CSV gut passt
- Jeder Datensatz hat dieselben Spalten.
- Die Datei wird als vollständiger oder inkrementeller Stapel verarbeitet.
- Menschen sollen die Daten leicht in einer Tabellenkalkulation prüfen können.
- Hierarchien und wiederholte Unterelemente sind nicht erforderlich.
Wo CSV an Grenzen stößt
CSV kennt ohne Zusatzvereinbarung keine sicheren Datentypen, Einheiten oder Pflichtfelder. Mehrere Lieferadressen, verschiedene Weiterverarbeitungsschritte oder verschachtelte Produktoptionen lassen sich nur über Hilfskonstruktionen abbilden. Werden Dateien manuell in Excel geöffnet und gespeichert, können führende Nullen, Datumswerte oder lange Nummern unbeabsichtigt verändert werden. Solche Risiken behandelt auch der Beitrag Excel in der Druckerei.
XML: belastbar für komplexe und druckspezifische Daten
XML bildet Informationen als benannte Elemente und Attribute ab. Verschachtelte Strukturen, Namensräume und definierte Schemata machen das Format für umfangreiche Fachmodelle geeignet. Ein System kann nicht nur prüfen, ob die Datei formal lesbar ist, sondern mit einem Schema auch, ob erwartete Elemente und Datentypen vorhanden sind.
In Druckworkflows ist XML besonders durch JDF und XJDF bekannt. Jobticket, Ressourcen und Produktionsvorgaben lassen sich damit strukturiert zwischen Management- und Produktionssystemen austauschen. Die aktuelle XJDF-Spezifikation 2.2 bevorzugt weiterhin XML, erlaubt aber zusätzlich JSON als zweite Codierung.
Wann XML gut passt
- Die Daten besitzen mehrere Hierarchieebenen.
- Ein etabliertes Branchenschema wie JDF oder XJDF wird verwendet.
- Dokumente müssen streng validiert und langfristig nachvollziehbar sein.
- Namensräume trennen Inhalte verschiedener Fachmodelle.
Wo XML an Grenzen stößt
Start- und End-Tags vergrößern Dateien und machen einfache Nachrichten umfangreicher. Die technische Verarbeitung ist ausgereift, erfordert aber Erfahrung mit Schemata, Namensräumen und Versionen. Ein vollständiges JDF-Dokument zu erzeugen, obwohl nur drei Statuswerte benötigt werden, wäre unnötig komplex. Wie der Standard sinnvoll eingegrenzt wird, erklärt JDF und JMF einfach erklärt.
JSON: kompakt für APIs und moderne Anwendungen
JSON ist ein textbasiertes, sprachunabhängiges Austauschformat. Es kennt Objekte, Listen, Zeichenketten, Zahlen, Wahrheitswerte und null. Die Struktur passt gut zu Web-APIs und Anwendungen, die Bestellungen, Produktkonfigurationen oder Statusereignisse unmittelbar verarbeiten.
Im Vergleich zu XML ist JSON meist kompakter und für Entwickler schnell zugänglich. Eine Bestellung kann Positionen als Liste enthalten, jede Position wiederum technische Optionen als Objekt. Damit ist JSON deutlich flexibler als eine flache CSV-Datei.
Wann JSON gut passt
- Webshop, Kundenportal oder Webanwendung kommuniziert über eine API.
- Objekte und Listen sollen kompakt übertragen werden.
- Ereignisse wie „Datei geprüft“ oder „Auftrag freigegeben“ werden gemeldet.
- Viele gängige Programmiersprachen sollen die Daten direkt verarbeiten.
Wo JSON an Grenzen stößt
Auch JSON erklärt nicht automatisch, ob eine Zahl Millimeter, Bogen oder Euro bedeutet. Datumsformat, Dezimalstellen, Pflichtfelder und zulässige Werte brauchen eine separate Spezifikation. Zahlen können in verschiedenen Programmiersprachen außerdem unterschiedlich genau verarbeitet werden. Geldbeträge und sehr lange Kennungen sollten deshalb bewusst modelliert werden.
Praxisbeispiel: Drei Formate in einem Auftragsworkflow
Ein Papierlieferant stellt täglich eine CSV-Datei mit Artikelnummer, Format, Grammatur, Bestand und Preis bereit. Das ERP importiert die Liste, prüft Spalten und aktualisiert nur freigegebene Felder. Für diese flachen Stammdaten ist CSV ausreichend.
Der Webshop übergibt eine Bestellung per JSON-API an das MIS. Die Nachricht enthält Kunde, Lieferziel und mehrere Positionen mit individuellen Produktoptionen. Nach der Auftragsanlage erhält der Shop eine eindeutige MIS-Nummer zurück.
Das MIS sendet Produktionsdaten als XJDF an die Vorstufe und den Produktionscontroller. Statusmeldungen fließen zurück und werden für Webshop und ERP auf die jeweils benötigten Informationen reduziert. Dieser gemischte Ansatz ist kein Mangel. Jedes Format übernimmt die Aufgabe, für die es am besten geeignet ist.
Diese Regeln machen den Datenaustausch zuverlässig
- Felder eindeutig beschreiben: Name, Bedeutung, Datentyp, Länge, Einheit und Beispiel gehören in die Dokumentation.
- Stabile IDs verwenden: Kunden, Artikel, Aufträge und Dateien dürfen nicht nur über sichtbare Namen zugeordnet werden.
- Zeichencodierung festlegen: UTF-8 ist für neue Schnittstellen eine praxistaugliche Grundlage. Sender und Empfänger müssen dieselbe Codierung verwenden.
- Einheiten mitsenden oder definieren: Millimeter, Gramm pro Quadratmeter, Stück und Bogen dürfen nicht aus dem Kontext geraten.
- Datum und Uhrzeit normieren: Zeitzone und Format müssen eindeutig sein, besonders bei Lieferterminen und Statusmeldungen.
- Versionen kennzeichnen: Änderungen an Feldnamen oder Bedeutungen benötigen eine nachvollziehbare Schnittstellenversion.
- Fehler maschinenlesbar melden: Ursache, betroffener Datensatz und Korrekturmöglichkeit müssen erkennbar sein.
- Wiederholungen absichern: Ein erneut gesendeter Auftrag darf keine unbemerkte Dublette erzeugen.
So wählst du das passende Format
Beginne nicht mit „XML oder JSON?“, sondern mit einem konkreten Datenfluss. Für jede Übertragung beantwortest du sechs Fragen:
- Sind die Daten flach oder hierarchisch?
- Werden einzelne Vorgänge oder komplette Listen übertragen?
- Gibt es einen Branchenstandard oder ein vorhandenes Schema?
- Muss die Übertragung sofort oder zeitgesteuert erfolgen?
- Welche Systeme und Dienstleister müssen das Format unterstützen?
- Wie werden Validierung, Fehler und neue Versionen behandelt?
Für einen einfachen Bestandsimport ist CSV oft die wirtschaftlichste Wahl. Für moderne Web-APIs bietet sich JSON an. Bei komplexen Jobtickets und vorhandener JDF-Infrastruktur bleibt XML fachlich stark. Der übergeordnete Prozess entscheidet, wie auch der Überblick Druckerei-Prozesse digitalisieren zeigt.
Fazit
CSV, XML und JSON lösen unterschiedliche Aufgaben. CSV ist einfach und effizient für tabellarische Listen. XML bietet starke Möglichkeiten für hierarchische, validierbare Fachmodelle und etablierte Druckstandards. JSON ist kompakt und eignet sich besonders für APIs, Webshops und ereignisbasierte Anwendungen.
Die Zuverlässigkeit entsteht jedoch nicht durch das Format allein. Erst klare Datenverantwortung, stabile IDs, definierte Einheiten, Versionierung und eine sichtbare Fehlerbehandlung machen Produktionsdaten belastbar. Wähle das kleinste Format, das den konkreten Prozess vollständig und verständlich abbildet.
Auch interessant
FAQ
Ist JSON grundsätzlich moderner und besser als XML?
Nein. JSON ist kompakt und für viele Web-APIs sehr praktisch. XML bietet dagegen ausgereifte Schemata, Namensräume und etablierte Fachstandards. In Druckworkflows kann XML durch JDF oder XJDF die bessere Wahl sein. Entscheidend sind Datenmodell, vorhandene Systeme, Validierungsbedarf und der konkrete Prozess.
Kann CSV für Produktionsaufträge verwendet werden?
Für sehr einfache, gleichartige Aufträge kann CSV ausreichen. Sobald ein Auftrag mehrere Positionen, Dateien, Lieferziele oder Arbeitsgänge enthält, wird die flache Struktur unübersichtlich. Dann sind JSON, XML oder ein druckspezifisches Jobticket meist geeigneter. Pflichtfelder, Einheiten und Fehlerregeln müssen in jedem Fall separat definiert werden.
Warum verursacht CSV im DACH-Raum häufig Importfehler?
Programme verwenden je nach Sprache und Einstellung unterschiedliche Trennzeichen, Dezimalzeichen, Datumsformate und Zeichencodierungen. Ein Komma kann Feldtrenner oder Dezimalzeichen sein. Lege deshalb Trennzeichen, Anführungsregeln, Kopfzeile, UTF-8-Codierung und Zahlenformat verbindlich fest und teste den Import mit Sonderzeichen sowie leeren Feldern.
Was ist der Unterschied zwischen XML und XJDF?
XML definiert allgemeine Regeln für hierarchische Textdaten. XJDF verwendet diese Regeln für ein konkretes Fachmodell der Druckproduktion. Es beschreibt Job- und Ressourcendaten für den Austausch zwischen Managementanwendungen und ausführenden Systemen. XJDF 2.2 erlaubt neben der bevorzugten XML-Codierung inzwischen auch JSON.
Müssen alle Systeme in einer Druckerei dasselbe Format verwenden?
Nein. Ein Workflow kann CSV für Preislisten, JSON für Webshop-Bestellungen und XJDF für Produktionsjobs nutzen. Wichtig ist, dass jede Übergabe eindeutig dokumentiert und überwacht wird. Eine zentrale Integrationsschicht kann Formate übersetzen, sollte dabei aber IDs, Einheiten und fachliche Bedeutung unverändert erhalten.