1. Po co w ogóle wybierać format? Krótkie przypomnienie
Każdy obiekt .NET w pamięci — to zestaw adresów, referencji, pól, wewnętrznych struktur i całej „maszynowej kuchni”. Ale tak tego nie zapiszesz do pliku: pliki muszą być ustrukturyzowane w formacie, który potrafią czytać (i najlepiej też zapisywać) nie tylko my, lecz także inne programy. I tutaj pojawia się wybór formatu serializacji.
Główne zadania formatu serializacji:
- Kompaktowość: miejsce na dysku albo szybkość przesyłu po sieci.
- Czytelność (dla człowieka!): czy można otworzyć plik w edytorze tekstu i zrozumieć, co się dzieje.
- Uniwersalność: czy nadaje się do integracji z innymi systemami i językami.
- Wsparcie dla złożonych struktur: zagnieżdżenia, kolekcje, referencje, typy.
- Bezpieczeństwo i kompatybilność.
2. Serializacja binarna (Binary Serialization)
Serializacja binarna przedstawia dane jako „surowy” strumień bajtów. Wyobraź sobie, że nie tylko zapakowałeś rzeczy do pudełka, ale je zacementowałeś — szybko, kompaktowo, ale potem swoich skarpet nie znajdziesz bez młota pneumatycznego.
// Przykład tylko dla historycznej uwagi:
using System.Runtime.Serialization.Formatters.Binary;
// ... tworzenie obiektu
var user = new User { Name = "Iwan", Age = 42 };
// Serializacja
using var fs = new FileStream("user.bin", FileMode.Create);
var formatter = new BinaryFormatter();
formatter.Serialize(fs, user);
Zalety:
- Kompaktowość: minimalne zużycie miejsca na dysku, wysoka szybkość.
- Wbudowane wsparcie „rodzimych” typów .NET.
Wady:
- Format kompletnie nieczytelny — spróbuj otworzyć plik w Notatniku, trafisz do Matrixa (czyli zobaczysz nieczytelny zestaw znaków).
- Absolutnie nieuniwersalny: tylko dla .NET (i to często tylko tej samej wersji!).
- Wrażliwy na problemy z kompatybilnością między wersjami.
Gdzie był stosowany?
W obrębie .NET, gdy trzeba było szybko „zrzucić” obiekty między procesami na tej samej maszynie. Dziś zdecydowanie NIEzalecane, szczególnie jeśli zależy ci na bezpieczeństwie i długoterminowym wsparciu aplikacji. Używanie BinaryFormatter we współczesnych projektach to zła praktyka.
3. Format XML (Extensible Markup Language)
XML — czytelny dla człowieka i maszyny format oparty na tagach, podobny do HTML, ale bez żartów o <body>.
<User>
<Name>Iwan</Name>
<Age>42</Age>
</User>
Przykład serializacji:
using System.Xml.Serialization;
var user = new User { Name = "Iwan", Age = 42 };
var serializer = new XmlSerializer(typeof(User));
using var fs = new FileStream("user.xml", FileMode.Create);
serializer.Serialize(fs, user);
Zalety:
- Czytelność: można otworzyć i wzrokiem zobaczyć strukturę.
- Uniwersalność: XML potrafią czytać wiele języków i programów.
- Elastyczność (wsparcie dla schematów, walidacji, przestrzeni nazw itp.).
- Dobrze nadaje się do złożonych struktur i zagnieżdżonych obiektów.
Wady:
- „Szum i ciężar”: zajmuje dużo miejsca i transferu.
- Parsowanie wolniejsze niż w formatach binarnych.
- Nieścisłości przy serializacji niektórych typów (np. daty i czasu).
- Wymaga dodatkowej konfiguracji dla wsparcia niektórych kolekcji lub niestandardowych obiektów.
Gdzie stosować?
Wymiana danych między systemami korporacyjnymi, konfiguracje, integracja tam, gdzie potrzebna jest ścisła struktura.
4. Format JSON (JavaScript Object Notation)
JSON — kompaktowy, lekki, łatwy do odczytania format, zapożyczony ze świata JavaScript i zdobywający prawie cały świat wymiany danych dzięki swojej zwięzłości i prostocie.
{
"Name": "Iwan",
"Age": 42
}
Przykład serializacji:
using System.Text.Json;
var user = new User { Name = "Iwan", Age = 42 };
string json = JsonSerializer.Serialize(user);
File.WriteAllText("user.json", json);
Zalety:
- Bardzo czytelny dla człowieka i maszyny.
- Łatwo integruje się z technologiami webowymi (API, JavaScript i nie tylko).
- Kompaktowszy niż XML.
- Szybka serializacja/deserializacja w nowoczesnych bibliotekach (System.Text.Json, Newtonsoft.Json).
Wady:
- Brak wsparcia dla komentarzy (twój JSON nie będzie z siebie żartował).
- Ograniczenia strukturalne: nie potrafi serializować np. referencji między obiektami czy złożonych typów (np. słowników z nie-stringowymi kluczami).
- Różnice w interpretacji dat/czasu między implementacjami.
Gdzie stosować?
Praktycznie wszędzie tam, gdzie potrzebna jest wymiana informacji między różnymi platformami: web serwisy, aplikacje mobilne, REST API itd.
5. CSV (Comma-Separated Values)
CSV — prosty tekstowy format, przedstawiający dane w postaci tabeli (wiersze i kolumny), gdzie pola oddzielone są przecinkami lub innym separatorem.
Name,Age
Iwan,42
Olga,27
Przykład zapisu CSV ręcznie:
// Dla prostoty zapisujemy przez zwykły StreamWriter
var lines = new List<string>
{
"Name,Age",
"Iwan,42",
"Olga,27"
};
File.WriteAllLines("users.csv", lines);
Zalety:
- Obsługiwany przez ogromną liczbę programów (Excel, Google Docs, bazy danych itp.).
- Zwięzły i wygodny dla danych tabelarycznych.
Wady:
- Nie nadaje się do zagnieżdżonych lub złożonych obiektów (tylko „płaskie” struktury).
- Nie przechowuje informacji o typach danych (wszystko to stringi).
- Problemy z escapingiem, jeśli w danych pojawiają się przecinki, cudzysłowy, złamania linii.
Gdzie stosować?
Eksport/import danych między bazami, wymiana prostych zestawów rekordów, zrzuty z aplikacji.
6. Protokoły i formaty wymiany ze ścisłą typizacją
Protocol Buffers (protobuf) i MessagePack — binarne formaty serializacji z kontraktami (schematami), które sprawiają, że serializacja jest jeszcze bardziej kompaktowa i szybsza. Wymagają z góry opisanej schemy struktury danych.
Przykład w protobuf (upraszczając):
Nie wchodzi do standardu .NET, potrzebny pakiet Google.Protobuf.
message User {
string name = 1;
int32 age = 2;
}
Zalety:
- Maksymalna szybkość i kompaktowość.
- Krosplatformowość (wiele języków wspiera protobuf).
Wady:
- Trudniejsze do nauki i konfiguracji.
- Wymaga generacji kodu na podstawie schemy.
- Nie zawsze potrzebne, jeśli projekt nie obsługuje milionów wiadomości na sekundę.
Gdzie stosować?
Systemy wysokiego obciążenia, wymiana danych między mikroserwisami, gry, IoT.
7. Przydatne niuanse
Tabela-porównanie formatów
| Format | Czytelność | Kompaktowość | Uniwersalność | Złożone obiekty | Standard w .NET 9 | Bezpieczeństwo |
|---|---|---|---|---|---|---|
| Binary (.NET) | Nie | Tak | Nie | Tak | Nie | Nie |
| XML | Tak | Nie | Tak | Tak | Tak | Tak |
| JSON | Tak | Tak | Tak | Częściowo | Tak | Tak |
| CSV | Tak | Tak | Tak | Nie | Nie | Tak |
| Protobuf | Nie | Najlepsze | Tak | Tak | Nie | Tak |
Jak wybrać format serializacji dla swojej aplikacji?
Zapisujesz złożoną strukturę danych i zależy ci na czytelności dla człowieka — użyj XML albo JSON.
Trzeba szybko przesyłać dużą ilość danych między usługami, które kontrolujesz — rozważ protobuf albo MessagePack.
Eksportujesz raporty do analizy w Excelu lub bazie — użyj CSV.
Piszesz konfigurację dla serwisów lub CI/CD — YAML świetnie się sprawdzi.
Kompaktowość, szybkość i wsparcie referencji między obiektami — krytyczne? Trzeba szukać binarnych formatów, ale pamiętaj o minusach związanych z bezpieczeństwem i kompatybilnością.
8. Złośliwe momenty i częste błędy
Jeśli zdecydujesz przechowywać dane w formacie binarnym „dla tajemnicy”, pamiętaj: binarny zrzut nie oznacza bezpieczeństwa. Atakujący i tak może ten strumień „rozebrać”. Używaj szyfrowania, jeśli potrzeba.
Częsty problem: zapomnieć o kodowaniu przy pracy z formatami tekstowymi (XML/JSON/CSV) — używaj UTF-8. Nie wszystkie edytory i systemy lubią BOM.
XML, choć wydaje się „stary”, jest dobry dla kontraktowych protokołów, gdzie ważny jest ścisły opis walidacyjny struktury (np. schematy XSD), a JSON — do szybkich, elastycznych wymian.
Przy serializacji kolekcji złożonych obiektów nie wszystkie formaty poprawnie obsługują zagnieżdżone lub rekurencyjne struktury. JSON i XML dobrze współpracują z tablicami i listami, CSV — nie.
GO TO FULL VERSION