Datenformate: JSON und XML

Ein Protokoll bewegt Bytes. Ein Datenformat, auch Datenprotokoll genannt, legt fest, was diese Bytes aussagen, damit die Maschine am anderen Ende sie wieder zerlegen und die Temperatur finden kann.

Zwei Formate sind gebräuchlich: JSON und XML. Wenn Sie neu im IoT sind und noch nie eines davon lesen mussten, ist dies die Seite, die Sie sorgfältig lesen sollten, denn nahezu jede Payload, jede API-Antwort und jede Konfigurationsdatei, die Ihnen von hier an begegnet, wird das eine oder das andere sein.

JSON

JSON, JavaScript Object Notation, ist ein leichtgewichtiges Textformat für strukturierte Daten. Es ist Text, Sie können es also lesen, und es ist streng, eine Maschine kann es also eindeutig verarbeiten. Es ist die übliche Wahl für moderne IoT-Arbeit.

Hier eine vollständige IoT-Payload:

{
  "deviceId": "sensor-042",
  "timestamp": "2026-08-14T09:15:00Z",
  "temperature": 25.5,
  "humidity": 41,
  "batteryOk": true,
  "errorMessage": null,
  "location": {
    "building": "Stadtbibliothek",
    "floor": 2
  },
  "recentReadings": [25.1, 25.3, 25.5]
}

Alles in JSON besteht aus zwei Behältern und vier einfachen Werten.

Die zwei Behälter

Ein Objekt ist eine ungeordnete Sammlung von Name-Wert-Paaren, umschlossen von geschweiften Klammern. Der Name ist immer ein String in doppelten Anführungszeichen, gefolgt von einem Doppelpunkt und dann dem Wert. Die Paare werden durch Kommas getrennt.

{"temperature": 25.5, "humidity": 41}

Ein Array ist eine geordnete Liste von Werten, umschlossen von eckigen Klammern und durch Kommas getrennt. Die Werte müssen nicht denselben Typ haben, auch wenn sie es in der Praxis meist tun.

[25.1, 25.3, 25.5]

Die Datentypen

Typ	Geschrieben als	Beispiel	Hinweise
String	Doppelte Anführungszeichen	"Stadtbibliothek"	Immer doppelte, nie einfache
Zahl	Nur Ziffern	25.5, 41, -3, 1.2e6	Keine Anführungszeichen, keine Einheit, kein Unterschied zwischen ganzen Zahlen und Dezimalzahlen
Boolean	true oder false	true	Kleingeschrieben, ohne Anführungszeichen
Null	null	null	Bedeutet "kein Wert", was nicht dasselbe ist wie 0 oder ""
Objekt	{ }	{"floor": 2}	Kann all dies enthalten, auch weitere Objekte
Array	[ ]	[1, 2, 3]	Kann all dies enthalten, auch weitere Arrays

Das ist das gesamte Typsystem. Mehr gibt es bewusst nicht, und die Folgen davon sind es wert, verstanden zu werden.

Beachten Sie außerdem: Dezimalzahlen werden in JSON immer mit Punkt geschrieben, nicht mit Komma. 25.5 ist eine Zahl; 25,5 ist kein gültiges JSON.

Verschachtelung

Objekte und Arrays enthalten einander, und so drückt JSON Struktur beliebiger Tiefe aus. In der Payload oben ist location ein Objekt innerhalb des Hauptobjekts, floor liegt also eine Ebene tiefer. Auf einen Wert verweisen Sie über seinen Pfad von oben:

temperature          → 25.5
location.building    → "Stadtbibliothek"
recentReadings[0]    → 25.1

Diese Punktschreibweise ist die Art, wie die meisten Werkzeuge, darunter Translatoren und Regelbedingungen, ein Feld adressieren. Dass Arrays bei null zu zählen beginnen, ist eine häufige Quelle für Fehler um eins.

Ein Array aus Objekten ist die übliche Weise, mehrere Messwerte auf einmal zu senden:

{
  "deviceId": "sensor-042",
  "readings": [
    {"time": "2026-08-14T09:00:00Z", "temperature": 25.1},
    {"time": "2026-08-14T09:05:00Z", "temperature": 25.3},
    {"time": "2026-08-14T09:10:00Z", "temperature": 25.5}
  ]
}

Die Regeln, über die man stolpert

JSON ist streng, und seine Fehlermeldungen sind oft wenig hilfreich. Die häufigen Fehler:

• Schlüssel müssen in doppelten Anführungszeichen stehen. {temperature: 25.5} ist kein JSON, auch wenn es so aussieht, als müsste es eines sein.
• Einfache Anführungszeichen sind nie gültig. {'a': 1} ist kein JSON.
• Kein abschließendes Komma. {"a": 1, "b": 2,} ist ungültig, und das ist der mit Abstand häufigste Fehler.
• Keine Kommentare. Es gibt keine Möglichkeit, JSON zu kommentieren, weshalb Konfigurationsdateien, die Kommentare brauchen, oft etwas anderes verwenden.
• true, false und null werden kleingeschrieben und ohne Anführungszeichen. "true" ist ein String, und eine Regel, die auf einen Boolean prüft, trifft ihn nicht.
• Zahlen tragen keine Einheit und keine Zusicherung zur Genauigkeit. 25.5 kann Celsius, Fahrenheit oder etwas ganz anderes sein; nur der Feldname oder ein Datenmodell sagt es Ihnen.
• Es gibt keinen Datumstyp. Zeitstempel sind Strings und sollten ISO 8601 in UTC verwenden, also "2026-08-14T09:15:00Z", was als Text korrekt sortiert und jede Frage nach der Zeitzone ausräumt.
• Sonderzeichen in Strings werden mit einem Backslash escapt: \" für ein Anführungszeichen, \\ für einen Backslash, \n für einen Zeilenumbruch.

Warum es zu IoT passt

JSON ist kompakt genug für schmalbandige Verbindungen, braucht kein Schema, um lesbar zu sein, und jede Sprache und jedes Werkzeug verarbeitet es nativ. Ein Mensch kann eine Payload öffnen und sie verstehen, und das zählt bei der Inbetriebnahme mehr als jede theoretische Eleganz.

Seine Grenzen sind die Kehrseite derselben Einfachheit. Nichts in JSON sagt, was ein Feld bedeutet, in welcher Einheit es steht oder welche Felder erforderlich sind. Genau diese Lücke füllen Datenmodelle.

XML

XML, eXtensible Markup Language, ist das ältere der beiden und beschreibt Daten mit verschachtelten Tags. Es ist ausführlicher als JSON und entsprechend expliziter.

Dieselbe Payload in XML:

<?xml version="1.0" encoding="UTF-8"?>
<measurement deviceId="sensor-042">
  <timestamp>2026-08-14T09:15:00Z</timestamp>
  <temperature unit="C">25.5</temperature>
  <humidity unit="%">41</humidity>
  <batteryOk>true</batteryOk>
  <location>
    <building>Stadtbibliothek</building>
    <floor>2</floor>
  </location>
  <recentReadings>
    <reading>25.1</reading>
    <reading>25.3</reading>
    <reading>25.5</reading>
  </recentReadings>
</measurement>

Die Bestandteile

• Die Deklaration, die erste Zeile, nennt XML-Version und Zeichencodierung.
• Ein Element besteht aus einem öffnenden Tag, Inhalt und einem passenden schließenden Tag: <floor>2</floor>. Jedes Element muss geschlossen werden, und ein leeres darf sich selbst schließen, als <floor/>.
• Elemente verschachteln sich, und es muss genau ein Wurzelelement geben, das alle anderen enthält. Hier ist es measurement.
• Ein Attribut ist ein Name mit Wert am öffnenden Tag: unit="C". Attributwerte stehen immer in Anführungszeichen.
• Kommentare schreibt man <!-- so -->, was XML erlaubt und JSON nicht.

Elemente oder Attribute

XML lässt dieselbe Information auf beide Arten ausdrücken, und das ist seine häufigste Entwurfsdiskussion:

<temperature unit="C">25.5</temperature>
<temperature><value>25.5</value><unit>C</unit></temperature>

Die Konvention, auf die sich die meisten einigen, lautet: Attribute tragen Metadaten über das Element, etwa eine Einheit oder eine Kennung, während Elemente die eigentlichen Daten tragen. Attribute können sich nicht verschachteln oder wiederholen, was die Frage entscheidet, sobald der Wert eine eigene Struktur hat.

Namensräume und Schemata

Zwei Eigenschaften erklären, warum XML sich in großen Systemen hält.

Ein Namensraum lässt Dokumente aus verschiedenen Vokabularen kombinieren, ohne dass die Namen kollidieren, indem ein Präfix an eine URI gebunden wird:

<rec:Building xmlns:rec="https://w3id.org/rec/">
  <rec:name>Stadtbibliothek</rec:name>
</rec:Building>

Ein Schema, meist XSD, ist ein eigenes Dokument, das formal festlegt, welche Elemente auftreten dürfen, in welcher Reihenfolge, wie oft und von welchem Typ. Ein Parser kann ein Dokument dagegen validieren und alles zurückweisen, was nicht entspricht, bevor irgendein Anwendungscode läuft. Diese Zusicherung ist der Grund, warum XML dort verbreitet bleibt, wo Korrektheit vertraglich zugesichert ist.

Wo Ihnen das im IoT begegnet

XML erscheint in Integrationen mit Unternehmenssystemen, in SOAP-Webdiensten, in einer Reihe von Gebäude- und Industriesystemen und in Austauschformaten wie denen der Open-BIM-Familie. Jede Plattform, die sich in einen bestehenden Bestand integriert, muss es lesen können.

Die beiden nebeneinander

	JSON	XML
Struktur	Objekte und Arrays	Verschachtelte Elemente
Metadaten	Felder im Objekt	Attribute oder Unterelemente
Kommentare	Nicht unterstützt	Unterstützt
Schemavalidierung	Optional, über JSON Schema	Ausgereift und weit verbreitet, über XSD
Namensräume	Nicht eingebaut	Eingebaut
Größe auf der Leitung	Kompakter	Ausführlicher
Typische Verwendung im IoT	Geräte-Payloads, REST-APIs, MQTT	Unternehmens-, Gebäude- und Industrieintegrationen

Beide drücken dieselbe Information aus. JSON ist die übliche Wahl für neue IoT-Arbeit, und XML ist das, was ein großer Teil der bestehenden Infrastruktur bereits spricht. Eine horizontale Plattform verarbeitet daher beides und konvertiert dort, wo es nötig ist.

Was keines von beiden sagt

Sehen Sie sich die JSON-Payload oben auf dieser Seite noch einmal an. Sie sagt "temperature": 25.5. Sie sagt nicht, welche Einheit das ist, welche Genauigkeit zu erwarten ist, ob das Feld erforderlich ist, welches physische Objekt gemessen wurde oder zu welchem Raum es gehört.

Formate tragen Struktur. Die Bedeutung kommt aus der Schicht darüber, und dort kommen Datenmodelle ins Spiel.