📦

Vorlesung 10

Datenformate — JSON, XML & HTML
Was eigentlich durch die Pipes reist — und wie zwei Programme sich verstehen

Verteilte Systeme
Prof. Dr. Alexandra Mikityuk
HTW Berlin

JSON XML HTML

Die letzte Vorlesung — und der Kitt, der die ganze Reihe zusammenhält. 🧩

Lernziele

Verstehen, warum es Datenformate gibt — Serialisierung: Struktur ⇄ Textstrom
HTML als Auszeichnungssprache zum Anzeigen einordnen (inkl. MIME-Typen & Formulare)
XML lesen: eigene Tags, Baumstruktur, wohlgeformt vs. gültig
JSON beherrschen: Datentypen, Objekte & Arrays — das Format der modernen Web-Welt
JSON vs. XML vergleichen und wissen, was durch HTTP, MQTT, Sockets & Blockchain reist

Rückblick: Was reist eigentlich durch die Pipes?

Das ganze Semester haben wir Leitungen gebaut. Aber worüber wir kaum gesprochen haben: Was fließt da drin?

🔌 Sockets (VL 9)

„Was reist durch den Socket?" — ein Byte-Strom. Aber welche Struktur?

🌐 HTTP/REST (VL 6)

Im Message Body stecken Nutzdaten. In welchem Format?

📡 MQTT (VL 7)

Der Payload einer Nachricht — reiner Inhalt, frei wählbar.

                Auch Blockchain (VL 4/5) serialisiert Transaktionen als strukturierte Daten. Überall dieselbe Frage: in welchem Format packt man Daten, damit die Gegenseite sie versteht? Heute die Antwort.
            

Das Problem: zwei Programme, zwei „Welten"

Ein Programm hat Daten im Speicher — als struct, Objekt, Liste. Das andere Programm (andere Sprache, anderer Rechner) sieht davon nichts. Durch die Leitung passen nur Bytes / Text.

Objekt im Speicher → serialisieren → Text: { … } → Netz → Text: { … } → parsen → Objekt im Speicher

                Ein Datenformat ist die vereinbarte Schreibweise für diesen Textstrom. Beide Seiten müssen dieselben Regeln kennen — sonst versteht der Empfänger nur „Buchstabensalat".
            

Der Kernbegriff: Serialisierung

📤 Serialisieren

Struktur aus dem Speicher → flacher Textstrom, der durch die Leitung passt. („marshalling")

📥 Deserialisieren / Parsen

Textstrom → wieder Struktur im Speicher der Gegenseite.

                Anforderungen an ein gutes Format: von Menschen lesbar (Debugging!), von Maschinen eindeutig parsbar, sprach- & plattformunabhängig, und möglichst kompakt. Genau daran messen wir gleich HTML, XML und JSON.
            

Drei Formate — drei Zwecke

Format	Ursprünglicher Zweck	Heute typisch für
HTML	Text anzeigen im Browser (Auszeichnung)	Webseiten (Präsentation)
XML	Beliebige Daten strukturiert beschreiben	Konfig, Dokumente, SOAP, RSS
JSON	Kompakter Datenaustausch zwischen Programmen	REST-APIs, MQTT, Configs

                Wichtige Unterscheidung: HTML ist zum Anzeigen für Menschen. XML und JSON sind zum Austausch zwischen Maschinen. Alle drei sind Text — und alle drei schauen wir uns jetzt an.
            

HTML — HyperText Markup Language

1989: Tim Berners-Lee entwickelt am CERN ein Internet-basiertes Hypertext-System.
1993: erster Internet-Draft für HTML.
Seit 1996: Standardisierung im W3C (World Wide Web Consortium).
Aktuell: HTML5. Idee: Text mit Tags formatieren, dazu Links, Bilder & Medien.

Kernidee „Markup": Man zeichnet Text mit Tags aus — „das ist eine Überschrift", „das ist ein Link" — und der Browser stellt es dar.

HTML — ein Beispiel

<!DOCTYPE html>
<html>
  <head>
    <title>Hello World Example</title>
  </head>
  <body>
    <h1>Hello World Example</h1>
    <p>Hello <i>World!</i></p>
    <ul>
      <li><a href="http://www.wikipedia.org">Wikipedia</a></li>
    </ul>
  </body>
</html>

Aufbau: ein <head> (Metadaten) und ein <body> (sichtbarer Inhalt), verschachtelte Elemente aus Start- und End-Tag.

HTML — Tags, Elemente, Attribute

🏷️ Element

Start-Tag + Inhalt + End-Tag:
<p>Text</p>

🪆 Verschachtelung

Elemente enthalten Kind-Elemente → Baumstruktur.

⚙️ Attribut

Zusatzinfo im Start-Tag:
<a href="…">

                Merke: HTML hat feste, vordefinierte Tags (h1, p, a, ul …). Das ist praktisch fürs Web — aber es beschreibt Darstellung, nicht die Bedeutung beliebiger Daten. Merkt euch diesen Punkt für XML.
            

HTML ist zum Anzeigen — nicht zum Datenaustausch

✅ Wofür HTML gut ist

Menschen eine Seite präsentieren: Überschriften, Absätze, Links, Bilder — im Browser gerendert.

❌ Wofür nicht

Programm-zu-Programm-Daten. <h1> sagt „große Schrift", nicht „das ist ein Buchtitel". Die Bedeutung fehlt.

                Genau diese Lücke — „ich will eigene, bedeutungstragende Tags" — führt zu XML. Vorher aber: Wie sagt der Server dem Browser überhaupt, was er schickt?
            

Woher weiß der Empfänger, was das ist? — MIME-Typen

Ein Server liefert HTML, Bilder, JSON … alles als Bytes. Der Content-Type-Header (MIME-Typ) sagt, wie sie zu deuten sind — direkter Rückgriff auf HTTP (VL 6).

Content-Type: text/html; charset=utf-8   # eine Webseite
Content-Type: image/png                  # ein Bild
Content-Type: application/json            # ← unsere Daten!
Content-Encoding: gzip                   # komprimiert übertragen

MIME = Multipurpose Internet Mail Extension (RFC 2045 ff.). application/json und application/xml sind die Typen, mit denen unsere Datenformate durchs Web reisen.

Daten vom Nutzer: HTML-Formulare

Auch der Weg zurück zum Server nutzt Formate — zwei klassische Wege (VL 6 lässt grüßen):

GET — Query String

GET /form?Vorname=Reiner&Name=Zufall HTTP/1.1

Name/Wert-Paare in der URL. Sonderzeichen kodiert (Leerzeichen = %20). URL ist längenbeschränkt.

POST — im Body

POST /form HTTP/1.1
Content-Type: application/x-www-form-urlencoded

Vorname=Reiner&Name=Zufall

Daten im Message Body — für große/umfangreiche Daten.

XML — eXtensible Markup Language

eXtensible

Erweiterbar: XML definiert keine Tags. Ihr erfindet eure eigenen.

Markup

Wie HTML aus Elementen (Tags) — aber viel mächtiger (Grammatiken, Transformationen).

Language

Eine Meta-Sprache: eine Sprache, um eigene Sprachen/Formate zu definieren.

                Seit 1998 (W3C). Strukturierte Daten in Textform — von Maschinen genutzt, für Menschen lesbar. Lizenzfrei, plattformunabhängig, breit unterstützt.
            

XML — Aufbau: alles ist ein Baum

<buch>
  <autor>Douglas Adams</autor>
  <titel>The Hitchhiker's Guide</titel>
  <jahr>1979</jahr>
</buch>

🌳 Baumstruktur

Element = Start-Tag + Inhalt + End-Tag
genau ein Wurzel-Element (buch)
Elemente enthalten Kind-Elemente

Der Unterschied zu HTML: <autor> und <titel> gibt es in HTML nicht — wir haben sie selbst erfunden. Die Tags tragen jetzt Bedeutung.

XML — Deklaration & Attribute

<?xml version="1.0" encoding="UTF-8"?>   # optionale Deklaration
<buch>
  <autor birthday="11. März 1952">Douglas Adams</autor>
  <titel>The Hitchhiker's Guide to the Galaxy</titel>
</buch>

Deklaration: Version & Zeichenkodierung des Dokuments.

Attribut: Name/Wert-Paar im Start-Tag. Wert in Anführungszeichen, kein Name doppelt.

XML — wohlgeformt (well-formed)

Ein XML-Dokument ist wohlgeformt, wenn es die Syntax-Regeln einhält:

genau ein Wurzelelement, das alle anderen enthält
jedes Element mit Inhalt hat Start- und End-Tag
Tags sind sauber verschachtelt — keine Überlappungen
kein Element hat zwei Attribute gleichen Namens; Attributwerte in Anführungszeichen
Groß-/Kleinschreibung zählt: <Buch> ≠ <buch>

❌ Nicht wohlgeformt: <b><i>Text</b></i> — die Tags überlappen sich. Ein Parser lehnt das ab.

XML — gültig (valid)

✅ wohlgeformt

hält nur die Syntax-Regeln ein (siehe vorige Slide).

✅✅ gültig

ist wohlgeformt und hält eine Grammatik ein: welche Tags, in welcher Reihenfolge, welche Typen.

                Grammatik festlegen mit DTD (Document Type Definition) oder — moderner & bevorzugt — XML Schema. Wichtig beim Datenaustausch: beide Seiten prüfen gegen dasselbe Schema.
            

XML in der Kritik — und warum es JSON gibt

Wortreich (verbose) & komplex — jeder Wert von zwei Tags umschlossen.
Parsen ist ressourcenaufwendig (Speicher, Laufzeit).
Der Baum lässt sich schwer auf typisierte Programm-Datenstrukturen abbilden.

                Folge: Speziell als Datenaustauschformat zwischen Programmen wurde XML als zu schwerfällig empfunden. Das führte zu einem leichteren Format — JSON.
            

JSON — JavaScript Object Notation

Entwickelt von Douglas Crockford, 2001. Standard: RFC 8259.
Kompaktes, für Mensch & Maschine leicht lesbares Textformat zum Datenaustausch.
Abgeleitet aus den Sprachelementen von JavaScript — aber sprachunabhängig einsetzbar.
Kurios: die Lizenz enthielt „The Software shall be used for Good, not Evil." 😇

Heute der De-facto-Standard für REST-APIs, Konfigurationsdateien, MQTT-Payloads und Web-Kommunikation (Ajax, WebSockets).

JSON — die Datentypen

🔢 4 primitive Typen

String — in doppelten "…"
Number — 42, -3.14
Boolean — true / false
Null — null

🧱 2 strukturierte Typen

Object — { … } Schlüssel-Wert-Paare
Array — [ … ] geordnete Liste

Wichtig: Die Werte sind typisiert — 12 ist eine Zahl, "12" ein String. Genau das musste man bei XML per Schema nachrüsten.

JSON — das Objekt `{ }`

{
  "autor": "Douglas Adams",
  "jahr": 1979,
  "verfilmt": true
}

beginnt mit {, endet mit }
Komma-getrennte, ungeordnete Liste von Schlüssel : Wert-Paaren
Schlüssel sind Strings (in "…") und sollten eindeutig sein
Werte dürfen beliebige JSON-Elemente sein — auch wieder Objekte/Arrays

JSON — das Array `[ ]`

{
  "titel": "Bestseller",
  "autoren": [ "Adams", "Pratchett", "Gaiman" ],
  "preise": [ 9.99, 12.50, 8 ]
}

beginnt mit [, endet mit ]
Komma-getrennte, geordnete Liste von Werten
gleiche oder verschiedene Typen erlaubt; leere Arrays [] sind zulässig

Objekt vs. Array: Objekt = benannte Felder (ungeordnet), Array = nummerierte Liste (geordnet). Verschachtelt ergibt das jede beliebige Struktur.

JSON — verschachtelt: das Buch komplett

{
  "buch": {
    "autor": "Douglas Adams",
    "titel": "The Hitchhiker's Guide",
    "publication-date": {
      "day": 12,
      "month": 10,
      "year": 1979
    }
  }
}

Objekte im Objekt — „Werte innerhalb von Werten". Genau so beschreibt JSON hierarchische Daten, ganz ohne einen einzigen End-Tag.

Dieselben Daten: XML vs. JSON

XML

<buch>
  <autor>Douglas Adams</autor>
  <jahr>1979</jahr>
</buch>

JSON

{
  "autor": "Douglas Adams",
  "jahr": 1979
}

Auf einen Blick: JSON kommt ohne schließende Tags aus, 1979 ist direkt eine Zahl — weniger Text, weniger Overhead, direkt typisiert.

JSON vs. XML — die Unterschiede

	XML	JSON
selbst-beschreibend	ja	ja
hierarchisch	ja (Baum)	ja (verschachtelt)
Syntax	Tags, End-Tags	einfacher, kürzer
Overhead	hoch (viele Tags)	gering
Typen	nur mit Schema	eingebaut
Attribute vs. Kinder	beides möglich (mehrdeutig)	nur Schlüssel-Wert

Fairerweise: XML kann mehr (Namespaces, Schemata, Transformationen) und ist in Dokumenten/Enterprise weiter verbreitet. Für schlanken Datenaustausch gewinnt JSON.

Wo JSON überall steckt — der Kurs in einer Slide

🌐 REST (VL 6)

API-Antworten sind fast immer JSON: Content-Type: application/json.

📡 MQTT (VL 7)

Der Payload einer Nachricht ist typischerweise ein JSON-Objekt (Sensorwerte …).

🔌 Sockets (VL 9)

Über den Byte-Strom schickt man JSON-Text — Struktur endlich beantwortet.

                Und mehr: Bitcoin/Ethereum sprechen JSON-RPC, KI-Agenten & MCP (VL 2/3) tauschen JSON, Konfigurationen (package.json …) sind JSON. JSON ist der Kitt der ganzen Vorlesungsreihe.
            

JSON im Code — lesen & schreiben

Kein Format selbst parsen — dafür gibt es Bibliotheken. Text ⇄ Struktur in einer Zeile:

Python

import json
d = json.loads(text)
text = json.dumps(d)

JavaScript

d = JSON.parse(text)
text = JSON.stringify(d)

C

// z.B. cJSON
cJSON *d =
  cJSON_Parse(text);

Muster überall gleich: parse macht aus Text eine Struktur, stringify/dumps macht aus einer Struktur Text — das ist Serialisierung von Slide 5, konkret.

Ein echtes Beispiel: eine REST-Antwort

# Anfrage
GET /api/users/42 HTTP/1.1
Host: api.example.com

# Antwort
HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 42,
  "name": "Anna",
  "roles": [ "admin", "user" ],
  "active": true
}

Alles kommt zusammen: HTTP transportiert (VL 6), der Content-Type deklariert das Format, und im Body reist JSON — typisiert, kompakt, für Client & Server verständlich.

🧠 Mini-Quiz (1/2)

Welches Format eignet sich am besten für den Datenaustausch zwischen Programmen?

A HTML

B XML — weil es die meisten Tags hat

C JSON — kompakt, typisiert, leicht parsbar

D Egal, Hauptsache es sind Bytes

Warum C: HTML ist zum Anzeigen; XML kann's, ist aber wortreich. JSON ist kompakt, hat eingebaute Typen und ist überall leicht zu parsen — der De-facto-Standard für APIs.

🧠 Mini-Quiz (2/2)

Was ist kein gültiger JSON-Datentyp?

A Boolean (true/false)

B Array ([ … ])

C Date (ein eigener Datumstyp)

D Null (null)

Warum C: JSON kennt nur String, Number, Boolean, Null, Object & Array. Ein Datum gibt es nicht als Typ — man kodiert es als String (z. B. "1979-10-12") oder als Zahlen-Objekt.

Zusammenfassung — & ein Semester geschafft 🎓

Serialisierung: Struktur ⇄ Textstrom — die Voraussetzung, dass zwei Programme sich verstehen.
HTML: Auszeichnung zum Anzeigen (feste Tags, MIME-Typen, Formulare) — nicht für Datenaustausch.
XML: eigene Tags, Baum, wohlgeformt vs. gültig (DTD/Schema) — mächtig, aber wortreich.
JSON: kompakt & typisiert, Objekte {} & Arrays [] — Standard für REST, MQTT, Configs.
Der rote Faden: Genau das reist durch alle Pipes, die wir gebaut haben — HTTP, MQTT, Sockets, Blockchain.

Damit schließt sich der Kreis der Verteilten Systeme: Systeme verbinden (VL 1–9) — und wissen, was zwischen ihnen fließt (VL 10).

Vielen Dank!

Jetzt wisst ihr, was durch die Leitung fließt. 📦

Prof. Dr. Alexandra Mikityuk

HTW Berlin

Quellen: RFC 8259 (JSON) · W3C (HTML, XML) · T. Scheffler, „Verteilte Systeme"

Viel Erfolg bei der Klausur — ihr habt die ganze Kette gesehen. 💪

Vorlesung 10

Datenformate — JSON, XML & HTMLWas eigentlich durch die Pipes reist — und wie zwei Programme sich verstehen

Lernziele

Rückblick: Was reist eigentlich durch die Pipes?

🔌 Sockets (VL 9)

🌐 HTTP/REST (VL 6)

📡 MQTT (VL 7)

Das Problem: zwei Programme, zwei „Welten"

Der Kernbegriff: Serialisierung

📤 Serialisieren

📥 Deserialisieren / Parsen

Drei Formate — drei Zwecke

HTML — HyperText Markup Language

HTML — ein Beispiel

HTML — Tags, Elemente, Attribute

🏷️ Element

🪆 Verschachtelung

⚙️ Attribut

HTML ist zum Anzeigen — nicht zum Datenaustausch

✅ Wofür HTML gut ist

❌ Wofür nicht

Woher weiß der Empfänger, was das ist? — MIME-Typen

Daten vom Nutzer: HTML-Formulare

GET — Query String

POST — im Body

XML — eXtensible Markup Language

eXtensible

Markup

Language

XML — Aufbau: alles ist ein Baum

🌳 Baumstruktur

XML — Deklaration & Attribute

XML — wohlgeformt (well-formed)

XML — gültig (valid)

✅ wohlgeformt

✅✅ gültig

XML in der Kritik — und warum es JSON gibt

JSON — JavaScript Object Notation

JSON — die Datentypen

🔢 4 primitive Typen

🧱 2 strukturierte Typen

JSON — das Objekt { }

JSON — das Array [ ]

JSON — verschachtelt: das Buch komplett

Dieselben Daten: XML vs. JSON

XML

JSON

JSON vs. XML — die Unterschiede

Wo JSON überall steckt — der Kurs in einer Slide

🌐 REST (VL 6)

📡 MQTT (VL 7)

🔌 Sockets (VL 9)

JSON im Code — lesen & schreiben

Python

JavaScript

C

Ein echtes Beispiel: eine REST-Antwort

🧠 Mini-Quiz (1/2)

Welches Format eignet sich am besten für den Datenaustausch zwischen Programmen?

🧠 Mini-Quiz (2/2)

Was ist kein gültiger JSON-Datentyp?

Zusammenfassung — & ein Semester geschafft 🎓

Vielen Dank!

Datenformate — JSON, XML & HTML
Was eigentlich durch die Pipes reist — und wie zwei Programme sich verstehen

JSON — das Objekt `{ }`

JSON — das Array `[ ]`