JSON, XML czy CSV? Wybór właściwego formatu danych do zadania
13 października 2026
JSON, XML i CSV istnieją po to, by przenosić dane strukturalne między systemami, ale traktowanie ich jako wymiennych to sposób, w jaki projekty integracyjne kończą z utraconymi danymi, zepsutymi importami lub rozdętymi plikami. Każdy z tych formatów dokonał realnych kompromisów projektowych względem problemów i epok, które miał rozwiązywać, a znajomość tych kompromisów sprawia, że wybór właściwego do danego zadania staje się prosty.
W czym CSV jest naprawdę dobry i gdzie zawodzi?
CSV (wartości oddzielone przecinkami) jest tak prosty, jak to tylko możliwe dla formatu strukturalnego — czysty tekst, jeden wiersz na linię, wartości oddzielone przecinkami — co czyni go uniwersalnie czytelnym dla oprogramowania arkuszy kalkulacyjnych, baz danych i praktycznie każdego narzędzia do danych, jakie kiedykolwiek zbudowano. Jest doskonały do płaskich, tabelarycznych danych: listy rekordów, w których każdy wiersz ma te same pola. Zawodzi w momencie, gdy dane mają jakąkolwiek prawdziwą strukturę wykraczającą poza płaską tabelę — zagnieżdżone obiekty, relacje jeden-do-wielu, czy pola, które legalnie zawierają przecinki lub znaki nowej linii (obsługiwane niespójnie w różnych implementacjach CSV) — wszystko to wykracza poza to, do czego CSV został zaprojektowany.
Dlaczego JSON stał się domyślnym wyborem konkretnie dla API webowych?
Struktura obiektów i tablic JSON mapuje się niemal bezpośrednio na sposób, w jaki większość nowoczesnych języków programowania już reprezentuje dane w pamięci, co oznacza, że ładunek JSON można często sparsować bezpośrednio do natywnej struktury danych przy minimalnym nakładzie na tłumaczenie — poważna praktyczna zaleta dla API webowych, gdzie liczy się szybkość i prostota zarówno produkowania, jak i konsumowania danych. Jest też stosunkowo zwięzły i czytelny dla człowieka, co stanowi równowagę, która uczyniła go naturalnym domyślnym wyborem wraz z rozpowszechnianiem się API webowych, w dużej mierze wypierając XML w projektowaniu nowych API, mimo że XML pojawił się wcześniej.
Co XML potrafi zrobić, czego JSON strukturalnie nie potrafi?
XML wspiera atrybuty na elementach (metadane dołączone do samego znacznika, odrębne od jego zawartości), przestrzenie nazw (unikanie kolizji nazw przy łączeniu słowników z różnych źródeł) oraz dojrzały, formalny ekosystem walidacji schematów (XSD) do rygorystycznego definiowania i egzekwowania tego, co dokładnie musi zawierać poprawny dokument — możliwości, których prostszy model obiektów/tablic JSON natywnie nie oferuje (JSON Schema istnieje, ale pojawił się później i jest mniej powszechnie przyjęty). To właśnie dlatego XML utrzymuje się w dziedzinach wymagających rygorystycznej walidacji dokumentów, dokumentów z mieszanym słownictwem, lub długo ustanowionych standardów danych korporacyjnych i rządowych, które poprzedzają wzrost popularności JSON.
Dlaczego konwersja CSV do zagnieżdżonego formatu, jak JSON, wymaga czegoś więcej niż mechanicznej konwersji?
CSV nie ma pojęcia zagnieżdżenia — każdy wiersz jest płaski — więc konwersja danych CSV do formatu wspierającego hierarchię (jak JSON reprezentujący, powiedzmy, zamówienie z wieloma pozycjami) wymaga faktycznej decyzji o tym, jak płaskie wiersze mapują się na zagnieżdżoną strukturę: czy każdy wiersz staje się osobnym obiektem najwyższego poziomu, czy wiele wierszy dzielących wspólny identyfikator zostaje pogrupowanych w jeden obiekt z zagnieżdżoną tablicą? Ta decyzja mapowania nie da się odtworzyć wyłącznie z samych danych CSV — zależy od zrozumienia rzeczywistych relacji w danych, dlatego «po prostu przekonwertuj mój CSV na JSON» czasem daje technicznie poprawny, ale praktycznie bezużyteczny wynik, jeśli struktura nie została określona.
Czy rozmiar pliku lub szybkość parsowania znacząco różnią się między tymi trzema formatami?
CSV jest generalnie najbardziej zwięzły dla naprawdę płaskich, jednolitych danych, ponieważ ma niemal zerowy narzut strukturalny — brak powtarzających się nazw znaczników czy nazw kluczy w każdym rekordzie. JSON jest bardziej zwięzły niż XML dla tych samych zagnieżdżonych danych, ponieważ brakuje mu redundancji znaczników zamykających XML-a, ale zawiera więcej narzutu niż CSV z powodu powtarzających się nazw kluczy w każdym obiekcie, chyba że użyje się bardziej zwięzłego kodowania opartego na tablicach. XML jest zwykle największy z tej trójki dla równoważnych danych z powodu rozwlekłych znaczników otwierających i zamykających, choć rzadko jest to czynnik decydujący w porównaniu z tym, jakich możliwości strukturalnych i ekosystemu narzędziowego faktycznie potrzebuje dana integracja.