Článek
Konverze mezi CSV, XML, JSON a YAML: praktický průvodce
CSV, JSON, XML a YAML jsou čtyři formáty, s nimiž se vývojáři setkávají nejčastěji v datových pipeline, konfiguračních souborech a API. Konverze mezi nimi je přímočará, pokud datové modely odpovídají, a překvapivě ztrátová, pokud ne. Tento průvodce popisuje, co každý formát dokáže a co ne, kde informace při konverzi mizí a jaké problémy s kódováním způsobují tiché poškození dat. Nástroj data-converter na tomto webu zvládá tři ze čtyř formátů (CSV, JSON a YAML) celé v prohlížeči; části o XML zde slouží jako podklad pro případ, že data přesouváte ručně nebo pomocí samostatného nástroje.
Čtyři formáty a jejich datové modely
CSV organizuje data jako plochá mřížka řádků a sloupců. První řádek obvykle pojmenovává sloupce; každý další řádek je jeden záznam. Neexistuje žádné vnoření, žádné informace o typech a žádný standard pro cokoli nad rámec prostého textu v buňkách. Každá hodnota je řetězec, pokud ji konzumující aplikace sama nevytypuje. JSON modeluje data jako strom objektů (mapy klíč-hodnota) a polí. Hodnoty mohou být řetězce, čísla, logické hodnoty, null, vnořené objekty nebo pole libovolné hloubky. Jeden JSON dokument tak může reprezentovat záznam zákazníka s vloženými objekty adresy, poli položek objednávky a typovanými číselnými součty. XML modeluje data jako strom prvků. Každý prvek může nést pojmenované atributy a obsahovat podřízené prvky nebo textový obsah. Neexistuje žádný vestavěný číselný ani logický typ; vše je text. Schémata jako XSD mohou typy vynucovat při validaci, ale přenosový formát je vždy data ve znakové podobě. YAML používá odsazení k vyjádření stejného modelu objektů a polí jako JSON, ale s přehlednější syntaxí čitelnou pro člověka. YAML je nadmnožinou JSON: každý platný JSON dokument je zároveň platný YAML. Přidává víceřádkové řetězce, komentáře a reference na kotvy pro opakující se bloky. YAML je běžný v konfiguračních souborech; JSON je běžný v odpovědích API.
Ztrátové konverze: zploštění a nejednoznačnost XML
Nejčastější ztrátovou konverzí je zploštění vnořeného JSON nebo XML do CSV. Objekt JSON s vnořeným polem adresy nelze čistě namapovat na řádek CSV. Obvyklým řešením jsou názvy sloupců s tečkovou notací: customer.address.city se stane vlastním sloupcem. To funguje pro jednu úroveň vnoření, ale zcela selhává, když se objeví pole. Zákazník se třemi telefonními čísly vyžaduje buď tři samostatné sloupce (s pevně zakódovaným maximálním počtem), rozdělení do druhého souboru CSV, nebo zakódování pole jako odděleného řetězce v jediné buňce. Žádná z těchto možností se bez dalších metadat nedá zpětně převést do původního JSON. XML přináší samostatnou nejednoznačnost: volbu mezi atributem a podřízeným prvkem. Hodnota Paris může být uložena jako atribut (<city name="Paris">) nebo jako podřízený prvek (<city><name>Paris</name></city>). Když konvertor čte XML a produkuje JSON, musí rozhodnout, jak namapovat atributy. Běžné konvence zahrnují přidání prefixu @ ke klíčům atributů nebo jejich umístění pod klíč "_attributes". Volba není standardizována, takže dva konvertory čtoucí stejné XML mohou produkovat strukturálně odlišný JSON. Pokud plánujete data přenášet tam a zpět přes XML a JSON, dohodněte se na konvenci předem.
Úskalí CSV: oddělovače, uvozování a kódování
CSV nemá žádný jednotný formální standard, jen RFC 4180 jako hojně citovaný referenční dokument. Nejběžnějším oddělovačem je čárka, ale středníky (časté v evropských regionálních nastaveních, kde čárky slouží jako desetinné oddělovače), tabulátory (TSV) a svislé čáry se v praxi také vyskytují. Soubor s příponou .csv může používat kterýkoli z nich, aniž by to signalizoval. Pokud hodnota pole obsahuje samotný oddělovač, RFC 4180 vyžaduje uzavření pole do dvojitých uvozovek: "San Francisco, CA". Dvojitá uvozovka uvnitř pole uzavřeného v uvozovkách musí být nahrazena zdvojenou: "He said ""hello""". Pole obsahující doslova nový řádek musí být také uzavřeno v uvozovkách. Analyzátory, které tento krok přeskočí, produkují chyby v počtu řádků, které se obtížně dohledávají. Kódování je samostatná past. Soubory CSV z nástrojů Windows často nesou UTF-8 BOM (značka pořadí bajtů: tři bajty EF BB BF na začátku souboru). BOM pomáhá Excelu identifikovat kódování, ale mnoho analyzátorů programovacích jazyků zachází s BOM jako se součástí prvního názvu sloupce, čímž vznikne sloupec pojmenovaný "id" místo "id". To rozbije jakýkoli následující kód, který vyhledává sloupce podle jména. Při programatickém čtení souboru CSV odstraňte BOM před analýzou, nebo použijte knihovnu, která to řeší explicitně.
Výběr formátu: konfigurace, výměna dat a tabulky
Volba formátu je obvykle dána kontextem, nikoli preferencí. JSON je výchozím formátem pro REST API a výměnu dat mezi prohlížečem a serverem. Je kompaktní, nativně analyzovatelný v každém programovacím jazyce a nese informace o typech pro čísla a logické hodnoty. Jeho slabinou je absence komentářů, což ho činí nevhodným pro soubory, které vývojáři ručně čtou a upravují. YAML je preferován pro konfigurační soubory (manifesty Kubernetes, definice CI pipeline, playbooku Ansible), protože umožňuje vložené komentáře a je snáze čitelný než JSON s mnoha úrovněmi odsazení. Jeho hlavním rizikem je, že chyby odsazení jsou tiché: chybně odsazený klíč se přesune do jiného rozsahu bez jakékoli chyby analýzy. XML zůstává standardem ve starších podnikových systémech, webových službách SOAP, formátech dokumentů (DOCX, SVG, RSS) a kontextech vyžadujících validaci schématu nebo rozlišení jmenných prostorů. Je obsáhlý, ale nástroje XPath a XSLT jsou vyzrálé. CSV je správnou volbou, když jsou data skutečně plochá a konzument je tabulkový procesor nebo datový analytik. Není vhodný pro konfiguraci nebo výměnu přes API, protože nemá žádný typový systém ani vnoření.
Lokálně pomocí data-converter
Nástroj data-converter na tomto webu analyzuje a převádí mezi CSV, JSON a YAML celý uvnitř prohlížeče; XML nečte ani nezapisuje. V žádném okamžiku nejsou data přenášena na server. Konverze probíhá v místním prostředí JavaScript a výstup je dostupný ke stažení nebo kopírování, aniž by cokoli opustilo vaše zařízení. To je důležité pro data, která nesmíte sdílet: odpovědi API obsahující osobní informace, konfigurační soubory s interními názvy hostitelů nebo exporty CSV z interních databází. Vložení takových dat do webového konvertoru běžícího na serveru znamená, že obsah je odeslán po síti a zpracován na hardwaru, který nekontrolujete. S data-converter je záložka prohlížeče prostředím zpracování. Nástroj uplatňuje uvozování podle RFC 4180 při čtení nebo zápisu CSV a při převodu JSON nebo YAML do CSV očekává plochý seznam objektů: vnořený objekt nebo pole hodnot pod klíčem se automaticky nezplošťuje tečkovou notací, takže taková pole si před převodem zploštěte sami, pokud je potřebujete jako samostatné sloupce. Pokud potřebujete přesunout data do XML nebo z něj, nejprve je pomocí vyhrazeného nástroje pro XML převeďte na JSON nebo YAML a výsledek pak přineste sem.
Nástroje v tomto článku
Časté dotazy
Mohu JSON přenést přes CSV a dostat zpět originál?
Jen pokud je JSON plochým polem objektů bez vnořených polí a bez polí jako hodnot. Jakmile máte vnořený objekt nebo hodnotu pole, reprezentace v CSV vyžaduje strukturální rozhodnutí (sloupce s tečkovou notací, více řádků nebo kódované řetězce), které nelze automaticky obrátit. Pokud vaše data mají vnoření, JSON, XML nebo YAML zachovají strukturu při zpětném převodu; CSV ne.
Proč CSV po exportu z evropské aplikace vypadá v Excelu špatně?
Evropská regionální nastavení často používají středníky jako oddělovač CSV, protože čárky jsou vyhrazeny pro zápis desetinných čísel. Excel s evropským nastavením očekává středníky. Pokud soubor používá čárky, Excel zachází s celým řádkem jako s jedním sloupcem. Řešením je buď změnit oddělovač v nastavení exportu, nebo použít průvodce importem dat v Excelu, který umožňuje oddělovač zadat ručně. Problém s UTF-8 BOM je samostatný: bez BOM může Excel také špatně přečíst znaky s diakritikou.
Jaký je praktický rozdíl mezi YAML a JSON?
Oba reprezentují stejný základní datový model: objekty, pole, řetězce, čísla, logické hodnoty a null. YAML přidává komentáře (řádky začínající #), víceřádkové řetězcové literály a kotevní reference pro opakující se bloky. JSON je striktně podmnožinou platného YAML, ale analyzátory JSON neumějí číst YAML. Praktické pravidlo: používejte JSON pro datové obsažnosti API a úložiště dat; YAML pro konfigurační soubory, které lidé upravují a kde jsou vhodné vložené komentáře.