Przy eksporcie JSON do CSV i otwieraniu w Excelu z polskimi ustawieniami regionalnymi, liczby z kropką dziesiętną jak 3.14 bywają błędnie interpretowane — bo w Polsce przecinek jest separatorem dziesiętnym, a Excel oczekuje wtedy średnika (;) jako separatora kolumn zamiast przecinka.
Do czego służy każdy format
- YAML — wcięcia zamiast nawiasów klamrowych, standard w pipeline'ach CI/CD, Kubernetesie i Docker Compose.
- CSV — płaski i tabelaryczny, najmniejszy wspólny mianownik dla arkuszy kalkulacyjnych i narzędzi analitycznych.
- XML — starszy, z atrybutami i przestrzeniami nazw, wciąż podstawa usług SOAP i wielu systemów w administracji publicznej i firmach.
- TOML — zaprojektowany, by być jednoznaczny i łatwy do ręcznej edycji, znany głównie z
Cargo.tomlw Rust.
Dlaczego CSV może wyglądać na "zepsuty" po otwarciu w polskim Excelu
Excel ustala separator pól CSV na podstawie regionalnych ustawień systemu. Przy przecinku jako separatorze dziesiętnym (standard w Polsce) Excel oczekuje średnika między kolumnami, a nie przecinka. Plik wyeksportowany z przecinkami może po otwarciu dwuklikiem wyglądać jak jedna długa kolumna — selektor separatora w tym konwerterze pozwala wcześniej wybrać średnik, żeby tego uniknąć.
Pułapka automatycznego rozpoznawania typu w YAML
Parser YAML próbuje odgadnąć typ wartości bez cudzysłowów: version: 1.20 może zamienić się w liczbę 1.2, tracąc końcowe zero, a tekst NO może zamienić się w wartość logiczną false zgodnie z regułami YAML 1.1, które traktowały yes/no jako literały boolowskie. Wartości, które mają pozostać tekstem, warto jawnie ująć w cudzysłów przed konwersją do JSON.
Do czego to się przydaje w praktyce
- Przeniesienie konfiguracji z narzędzia oczekującego YAML do narzędzia oczekującego JSON, lub odwrotnie.
- Eksport danych z API do CSV, żeby szybko podejrzeć je w arkuszu kalkulacyjnym.
- Połączenie starszego systemu opartego na XML/SOAP z nowoczesnym API JSON.