1. Warum überhaupt ein Format wählen? Kurze Erinnerung
Jedes .NET-Objekt im Speicher ist eine Sammlung von Adressen, Referenzen, Feldern, internen Strukturen und anderem "Maschinenkram". So etwas einfach in eine Datei zu schreiben funktioniert nicht: Dateien müssen in einem Format strukturiert sein, das nicht nur wir, sondern idealerweise auch andere Programme lesen (und schreiben) können. Genau hier kommt die Wahl des Serialisierungsformats ins Spiel.
Hauptaufgaben eines Serialisierungsformats:
- Kompaktheit: Platz auf der Festplatte oder Übertragungsgeschwindigkeit im Netzwerk.
- Lesbarkeit (für Menschen!): Kann man die Datei in einem Texteditor öffnen und verstehen, was darin steht.
- Universalität: Eignet es sich für Integration mit anderen Systemen und Sprachen.
- Unterstützung komplexer Strukturen: Verschachtelungen, Collections, Referenzen, Typen.
- Sicherheit und Kompatibilität.
2. Binäre Serialisierung (Binary Serialization)
Binäre Serialisierung stellt Daten als "rohen" Bytestrom dar. Stell dir vor, du hättest die Dinge nicht nur in eine Kiste gepackt, sondern einbetoniert — schnell, kompakt, aber später findest du deine Socken nicht ohne Presslufthammer.
// Beispiel nur zur historischen Referenz:
using System.Runtime.Serialization.Formatters.Binary;
// ... Erstellung des Objekts
var user = new User { Name = "Ivan", Age = 42 };
// Serialisierung
using var fs = new FileStream("user.bin", FileMode.Create);
var formatter = new BinaryFormatter();
formatter.Serialize(fs, user);
Vorteile:
- Kompaktheit: sehr geringer Platzbedarf, hohe Geschwindigkeit.
- Eingebaute Unterstützung für "native" .NET-Typen.
Nachteile:
- Das Format ist völlig unlesbar — öffne die Datei im Editor und du landest in der Matrix (also bekommst du unlesbare Zeichen).
- Völlig nicht universell: nur für .NET (und selbst da nur für dieselbe Version!).
- Verwundbar gegenüber Kompatibilitätsproblemen zwischen Versionen.
Wo wurde es verwendet?
Innerhalb von .NET, wenn man schnell Objekte zwischen Prozessen auf derselben Maschine "dumpen" musste. Heute wird es stark nicht empfohlen, vor allem wenn dir Sicherheit und langfristige Wartbarkeit wichtig sind. Die Nutzung von BinaryFormatter in modernen Projekten ist schlechte Praxis.
3. Das XML-Format (Extensible Markup Language)
XML ist ein menschen- und maschinenlesbares Format, das auf Tags basiert, ähnlich wie HTML, aber ohne die Witze über <body>.
<User>
<Name>Ivan</Name>
<Age>42</Age>
</User>
Beispiel für Serialisierung:
using System.Xml.Serialization;
var user = new User { Name = "Ivan", Age = 42 };
var serializer = new XmlSerializer(typeof(User));
using var fs = new FileStream("user.xml", FileMode.Create);
serializer.Serialize(fs, user);
Vorteile:
- Lesbarkeit: man kann die Struktur mit bloßem Auge erkennen.
- Universalität: viele Sprachen und Programme können XML lesen.
- Flexibilität (Unterstützung für Schemata, Validierung, Namespaces usw.).
- Gut geeignet für komplexe Strukturen und verschachtelte Objekte.
Nachteile:
- "Rauschen" und schwergewichtig: belegt viel Platz und Traffic.
- Das Parsen ist langsamer als bei binären Formaten.
- Ungenauigkeiten bei der Serialisierung bestimmter Typen (z. B. Datum/Zeit).
- Erfordert zusätzliche Konfiguration für manche Collections oder unübliche Objekttypen.
Wo wird es eingesetzt?
Datenaustausch zwischen Enterprise-Systemen, Konfigurationen, Integration mit Systemen, die eine strikte Struktur verlangen.
4. Das JSON-Format (JavaScript Object Notation)
JSON ist ein kompaktes, leichtgewichtiges, gut lesbares Format, das aus der JavaScript-Welt stammt und fast überall für den Datenaustausch Fuß gefasst hat dank seiner Knappheit und Einfachheit.
{
"Name": "Ivan",
"Age": 42
}
Beispiel für Serialisierung:
using System.Text.Json;
var user = new User { Name = "Ivan", Age = 42 };
string json = JsonSerializer.Serialize(user);
File.WriteAllText("user.json", json);
Vorteile:
- Sehr gut lesbar für Menschen und Maschinen.
- Leichte Integration mit Web-Technologien (API, JavaScript und mehr).
- Kompakter als XML.
- Schnelle Serialisierung/Deserialisierung mit modernen Bibliotheken (System.Text.Json, Newtonsoft.Json).
Nachteile:
- Keine Unterstützung für Kommentare (dein JSON kann keine Witze über sich selbst machen).
- Beschränkungen bei Strukturen: kann z. B. keine Referenzen zwischen Objekten oder komplexe Datentypen (z. B. Dictionaries mit nicht-String-Keys) direkt darstellen.
- Uneinheitlichkeiten bei Datum/Zeit zwischen verschiedenen Implementierungen.
Wo wird es eingesetzt?
Praktisch überall, wo Austausch zwischen verschiedenen Plattformen nötig ist: Web-Services, mobile Apps, REST-APIs usw.
5. CSV (Comma-Separated Values)
CSV ist ein einfaches Textformat, das Daten als Tabelle (Zeilen und Spalten) darstellt, wobei Felder durch Kommata oder ein anderes Trennzeichen getrennt werden.
Name,Age
Ivan,42
Olga,27
Beispiel: CSV manuell schreiben:
// Zur Einfachheit schreiben wir mit einem normalen StreamWriter
var lines = new List<string>
{
"Name,Age",
"Ivan,42",
"Olga,27"
};
File.WriteAllLines("users.csv", lines);
Vorteile:
- Wird von vielen Programmen unterstützt (Excel, Google Docs, DBs usw.).
- Kurz und praktisch für tabellarische Daten.
Nachteile:
- Nicht geeignet für verschachtelte oder komplexe Objekte (nur "flache" Strukturen).
- Speichert keine Typinformationen (alles ist String).
- Probleme mit Escaping, wenn Daten Kommata, Anführungszeichen oder Zeilenumbrüche enthalten.
Wo wird es eingesetzt?
Export/Import zwischen DBs, Austausch einfacher Datensätze, Exporte aus Anwendungen.
6. Protokolle und Formate mit starker Typisierung
Protocol Buffers (protobuf) und MessagePack sind binäre Serialisierungsformate mit Verträgen (Schemata), die Serialisierung noch kompakter und schneller machen. Sie benötigen vorher beschriebene Datenschemata.
Vereinfachtes Beispiel in protobuf:
Nicht Teil des .NET-Standards, Paket Google.Protobuf wird benötigt.
message User {
string name = 1;
int32 age = 2;
}
Vorteile:
- Maximale Geschwindigkeit und Kompaktheit.
- Kreuzplattformfähig (viele Sprachen unterstützen protobuf).
Nachteile:
- Schwieriger zu erlernen und einzurichten.
- Benötigt Codegenerierung aus dem Schema.
- Nicht immer notwendig, wenn das Projekt nicht Millionen von Nachrichten pro Sekunde verarbeitet.
Wo wird es eingesetzt?
Hochlast-Systeme, Datenaustausch zwischen Microservices, Games, IoT.
7. Nützliche Feinheiten
Vergleichstabelle der Formate
| Format | Lesbarkeit | Kompaktheit | Universalität | Komplexe Objekte | Standard in .NET 9 | Sicherheit |
|---|---|---|---|---|---|---|
| Binary (.NET) | Nein | Ja | Nein | Ja | Nein | Nein |
| XML | Ja | Nein | Ja | Ja | Ja | Ja |
| JSON | Ja | Ja | Ja | Teilweise | Ja | Ja |
| CSV | Ja | Ja | Ja | Nein | Nein | Ja |
| Protobuf | Nein | Am besten | Ja | Ja | Nein | Ja |
Wie wählt man das Serialisierungsformat für seine Anwendung?
Du speicherst komplexe Datenstrukturen und Lesbarkeit für Menschen ist wichtig — nutze XML oder JSON.
Du musst große Datenmengen schnell zwischen kontrollierten Services übertragen — ziehe protobuf oder MessagePack in Betracht.
Du exportierst Reports für die Analyse in Excel oder eine DB — verwende CSV.
Du schreibst Konfigurationen für Services oder CI/CD — YAML hilft dir gut weiter.
Kompaktheit, Geschwindigkeit und Unterstützung für Referenzen zwischen Objekten sind kritisch? Dann musst du binäre Formate in Erwägung ziehen, aber denk an die Nachteile bei Sicherheit und Kompatibilität.
8. Trickreiche Punkte und häufige Fehler
Wenn du Daten im binären Format speichern willst, nur um sie "geheim" zu halten, denk daran: ein binärer Dump heißt nicht automatisch Sicherheit. Ein Angreifer kann den Stream trotzdem analysieren. Verwende Verschlüsselung, wenn nötig.
Ein häufiger Fehler: die Kodierung bei Textformaten (XML/JSON/CSV) vergessen — benutze UTF-8. Nicht alle Editoren und Systeme mögen BOM.
XML wirkt zwar "alt", ist aber gut für vertragliche Protokolle, wo eine strikte Validierungsbeschreibung der Struktur wichtig ist (z. B. XSD), während JSON für schnelle, flexible Austausche geeignet ist.
Bei der Serialisierung von Collections komplexer Objekte unterstützen nicht alle Formate verschachtelte oder rekursive Strukturen korrekt. JSON und XML gehen gut mit Arrays und Listen um, CSV jedoch nicht.
GO TO FULL VERSION