Articol
Conversia între CSV, XML, JSON și YAML: un ghid practic
CSV, JSON, XML și YAML sunt cele patru formate pe care dezvoltatorii le întâlnesc cel mai des în pipeline-urile de date, fișierele de configurare și API-uri. Conversia între ele este simplă atunci când modelele de date coincid și surprinzător de distructivă când nu coincid. Acest ghid acoperă ce poate și ce nu poate reprezenta fiecare format, unde dispar informațiile la conversie și capcanele de codare care produc corupție silențioasă. Instrumentul data-converter de pe acest site gestionează trei din cele patru formate (CSV, JSON și YAML) complet în browser; secțiunile despre XML de aici sunt informații de fundal pentru situațiile în care muți date manual sau cu un instrument separat.
Cele patru formate și modelele lor de date
CSV organizează datele ca un tabel plat de rânduri și coloane. Primul rând denumește de obicei coloanele; fiecare rând următor reprezintă o înregistrare. Nu există imbricare, nicio informație de tip și niciun standard dincolo de text simplu în celule. Fiecare valoare este un șir de caractere, cu excepția cazului în care aplicația care îl citește impune un tip. JSON modelează datele ca un arbore de obiecte (mapări cheie-valoare) și tablouri. Valorile pot fi șiruri de caractere, numere, valori booleene, null, obiecte imbricate sau tablouri de orice adâncime. Astfel, un singur document JSON poate reprezenta o înregistrare client cu obiecte adresă imbricate, tablouri de articole și totaluri numerice tipizate. XML modelează datele ca un arbore de elemente. Fiecare element poate conține atribute cu nume și poate include elemente copil sau conținut text. Nu există un tip numeric sau boolean integrat; totul este text. Schemele precum XSD pot impune tipuri la momentul validării, dar formatul de transport este întotdeauna date de tip caracter. YAML folosește indentarea pentru a exprima același model de obiecte și tablouri ca JSON, cu o sintaxă mai curată, ușor de citit de om. YAML este un superset al JSON: orice document JSON valid este și YAML valid. Adaugă șiruri pe mai multe rânduri, comentarii și referințe ancoră-alias pentru blocuri repetate. YAML este comun în fișierele de configurare; JSON este comun în răspunsurile API.
Conversii cu pierderi: aplatizarea și ambiguitatea XML
Cea mai frecventă conversie cu pierderi este aplatizarea JSON sau XML imbricat în CSV. Un obiect JSON cu un câmp adresă imbricat nu se poate mapa curat pe un rând CSV. Soluția tipică este utilizarea numelor de coloane cu notație punct: customer.address.city devine propria sa coloană. Aceasta funcționează pentru un nivel de imbricare, dar eșuează complet când apare un tablou. Un client cu trei numere de telefon necesită fie trei coloane separate (codificând numărul maxim), împărțirea într-un al doilea fișier CSV, fie codificarea tabloului ca șir delimitat într-o singură celulă. Niciuna dintre aceste opțiuni nu se poate converti înapoi la JSON-ul original fără metadate suplimentare. XML introduce o ambiguitate separată: alegerea între atribut și element copil. Valoarea Paris ar putea fi stocată ca atribut (<city name="Paris">) sau ca element copil (<city><name>Paris</name></city>). Când un convertor citește XML și produce JSON, trebuie să decidă cum să mapeze atributele. Convențiile comune includ prefixarea cheilor de atribut cu @ sau plasarea lor sub o cheie „_attributes". Alegerea nu este standardizată, ceea ce înseamnă că doi convertori care citesc același XML pot produce JSON cu structuri diferite. Dacă intenționați să transferați date între XML și JSON, stabiliți o convenție înainte de a începe.
Capcane CSV: delimitatori, ghilimele și codare
CSV nu are un standard formal unic, doar RFC 4180 ca referință frecvent citată. Cel mai comun delimiter este virgula, dar punctele și virgulele (frecvente în localele europene unde virgulele servesc ca separatori zecimali), tabulatorii (TSV) și caracterul pipe apar toate în practică. Un fișier numit .csv poate folosi oricare dintre acestea fără a indica care. Atunci când valoarea unui câmp conține chiar delimitatorul, RFC 4180 impune înconjurarea câmpului cu ghilimele duble: „San Francisco, CA". Un ghilimele duble în interiorul unui câmp între ghilimele trebuie scăpat prin dublare: „He said ""hello""". Un câmp care conține un caracter de rând nou real trebuie și el pus între ghilimele. Parsere care omit acest pas produc erori de număr de rânduri greu de depistat. Codarea este o capcană separată. Fișierele CSV din instrumente Windows conțin adesea un UTF-8 BOM (byte order mark: cei trei octeți EF BB BF la începutul fișierului). BOM-ul ajută Excel să identifice codarea, dar mulți parseri din limbajele de programare tratează BOM-ul ca parte din primul nume de coloană, producând o coloană numită „id" în loc de „id". Aceasta rupe orice cod din aval care caută coloane după nume. Când citiți un fișier CSV programatic, eliminați BOM-ul înainte de parsare sau utilizați o bibliotecă care îl gestionează explicit.
Alegerea unui format: configurare, schimb de date și foi de calcul
Alegerea formatului este de obicei determinată de context, nu de preferință. JSON este implicit pentru API-urile REST și schimbul de date browser-server. Este compact, parsat nativ în orice limbaj de programare și transportă informații de tip pentru numere și valori booleene. Slăbiciunea sa este absența comentariilor, ceea ce îl face nepotrivit pentru fișierele pe care dezvoltatorii le citesc și editează manual. YAML este preferat pentru fișierele de configurare (manifeste Kubernetes, definiții de pipeline CI, playbook-uri Ansible) deoarece permite comentarii inline și este mai ușor de citit decât JSON cu multe niveluri de indentare. Principalul risc este că erorile de indentare sunt silențioase: o cheie greșit indentată se mută la un alt scop fără nicio eroare de parsare. XML rămâne standard în sistemele enterprise mai vechi, serviciile web SOAP, formatele de document (DOCX, SVG, RSS) și contextele care necesită validare de schemă sau dezambiguizare de spații de nume. Este verbose, dar instrumentele XPath și XSLT sunt mature. CSV este alegerea corectă când datele sunt cu adevărat plate și consumatorul este o aplicație foaie de calcul sau un analist de date. Nu este potrivit pentru configurare sau schimb de date prin API deoarece nu are sistem de tipuri și nu suportă imbricare.
Conversie locală cu data-converter
Instrumentul data-converter de pe acest site parsează și convertește între CSV, JSON și YAML complet în browser; nu citește și nu scrie XML. Nicio dată nu este transmisă unui server în niciun moment. Conversia rulează în runtime-ul JavaScript local, iar rezultatul este disponibil pentru descărcare sau copiere fără ca ceva să părăsească dispozitivul. Aceasta contează pentru date pe care nu aveți dreptul să le partajați: răspunsuri API care conțin informații personale, fișiere de configurare cu nume de host interne sau exporturi CSV din baze de date interne. Lipind aceste date într-un convertor web care rulează pe un server înseamnă că conținutul este trimis prin rețea și procesat pe hardware pe care nu îl controlați. Cu data-converter, tab-ul de browser este mediul de procesare. Instrumentul aplică ghilimelele RFC 4180 la citirea sau scrierea CSV și se așteaptă la un tablou plat de obiecte pentru conversia din JSON sau YAML în CSV: o valoare obiect sau tablou imbricată sub o cheie nu primește aplatizare automată prin notație punct, așa că aplatizează tu însuți acele câmpuri înainte de conversie dacă ai nevoie de ele ca coloane separate. Dacă trebuie să muți date către sau dinspre XML, convertește-le mai întâi în JSON sau YAML cu un instrument dedicat XML, apoi adu rezultatul aici.
Instrumente din acest articol
Întrebări frecvente
Pot converti JSON prin CSV și să obțin înapoi originalul?
Doar dacă JSON-ul este un tablou plat de obiecte fără câmpuri imbricate și fără tablouri ca valori. Din momentul în care există un obiect imbricat sau o valoare tablou, reprezentarea CSV necesită o decizie structurală (coloane cu notație punct, rânduri multiple sau șiruri codificate) care nu poate fi inversată automat. Dacă datele au imbricare, JSON, XML sau YAML se vor converti complet; CSV nu se va converti.
De ce arată greșit CSV-ul meu în Excel după exportul dintr-o aplicație europeană?
Localele europene folosesc adesea punct și virgulă ca delimiter CSV deoarece virgulele sunt rezervate pentru notația zecimală. Excel pe o locală europeană se așteaptă la punct și virgulă. Dacă fișierul folosește virgule, Excel tratează întregul rând ca o singură coloană. Soluția este fie să schimbați delimitatorul în setările de export, fie să utilizați expertul de import de date Excel, care vă permite să specificați delimitatorul manual. Problema UTF-8 BOM este separată: fără BOM, Excel poate citi greșit și caracterele accentuate ca text distorsionat.
Care este diferența practică dintre YAML și JSON?
Ambele reprezintă același model de date de bază: obiecte, tablouri, șiruri de caractere, numere, valori booleene și null. YAML adaugă comentarii (linii care încep cu #), literale de șiruri pe mai multe rânduri și referințe ancoră pentru blocuri repetate. JSON este strict un subset al YAML valid, dar parserii JSON nu citesc YAML. Regula practică: folosiți JSON pentru payload-uri API și stocare de date; folosiți YAML pentru fișierele de configurare pe care oamenii le editează și care beneficiază de comentarii inline.