Статия
Конвертиране между CSV, XML, JSON и YAML: практическо ръководство
CSV, JSON, XML и YAML са четирите формата, с които разработчиците се срещат най-често в конвейери за данни, конфигурационни файлове и API. Конвертирането между тях е лесно, когато моделите на данните съвпадат, и изненадващо губещо, когато не съвпадат. Това ръководство обхваща какво може и не може да представи всеки формат, къде информацията изчезва по време на конвертиране, и капаните за кодиране, които причиняват мълчаливо повреждане. Инструментът data-converter на този сайт обработва три от четирите формата (CSV, JSON и YAML) изцяло в браузъра; разделите за XML тук са фон за случаите, когато премествате данни на ръка или с отделен инструмент.
Четирите формата и техните модели на данни
CSV организира данните като плоска мрежа от редове и колони. Първият ред обикновено именува колоните; всеки следващ ред е един запис. Няма вложеност, няма информация за тип и няма стандарт за нищо освен обикновен текст в клетките. Всяка стойност е низ, освен ако приложението, което я консумира, не наложи тип. JSON моделира данните като дърво от обекти (карти ключ-стойност) и масиви. Стойностите могат да бъдат низове, числа, булеви стойности, null, вложени обекти или масиви от произволна дълбочина. Това позволява един JSON документ да представя запис на клиент с вградени обекти за адрес, масиви с артикули и типизирани числови суми. XML моделира данните като дърво от елементи. Всеки елемент може да носи именувани атрибути и да съдържа дъщерни елементи или текстово съдържание. Няма вграден числов или булев тип; всичко е текст. Схеми като XSD могат да налагат типове при валидиране, но форматът на предаване е винаги символни данни. YAML използва отстъп, за да изрази същия модел обект-и-масив като JSON, с по-чист, лесен за четене от хора синтаксис. YAML е надмножество на JSON: всеки валиден JSON документ е и валиден YAML. Той добавя многоредови низове, коментари и референции тип котва-псевдоним за повтарящи се блокове. YAML е разпространен в конфигурационни файлове; JSON е разпространен в отговори на API.
Губещи конвертирания: изравняване и неяснотата в XML
Най-честото губещо конвертиране е изравняването на вложен JSON или XML в CSV. JSON обект с вложено поле за адрес не може да се преведе чисто в ред на CSV. Типичното заобиколно решение е имена на колони с точкова нотация: customer.address.city става своя собствена колона. Това работи за едно ниво на вложеност, но се проваля напълно, когато се появи масив. Клиент с три телефонни номера изисква или три отделни колони (твърдо кодиране на максималния брой), разделяне в отделен CSV файл, или кодиране на масива като разделен низ вътре в една клетка. Нито едно от тези решения не се обръща обратно към оригиналния JSON без допълнителни метаданни. XML въвежда отделна неяснота: изборът между атрибут и дъщерен елемент. Стойността Paris може да се съхрани като атрибут (<city name="Paris">) или като дъщерен елемент (<city><name>Paris</name></city>). Когато конвертор чете XML и произвежда JSON, той трябва да реши как да преведе атрибутите. Честите конвенции включват поставяне на префикс @ пред ключовете на атрибутите или поставянето им под ключ "_attributes". Изборът не е стандартизиран, което означава, че два конвертора, четящи един и същ XML, могат да произведат структурно различен JSON. Ако планирате да прехвърляте данни между XML и JSON, фиксирайте конвенция преди да започнете.
Капани при CSV: разделители, кавички и кодиране
CSV няма единен формален стандарт, само RFC 4180 като широко цитирана справка. Най-честият разделител е запетая, но точка и запетая (разпространена в европейски локали, където запетаите служат като десетични разделители), табулации (TSV) и вертикална черта също се срещат на практика. Файл с разширение .csv може да използва кое да е от тях, без да указва кое. Когато стойността на поле съдържа самия разделител, RFC 4180 изисква полето да се обгърне в двойни кавички: "San Francisco, CA". Двойна кавичка вътре в поле с кавички трябва да се екранира чрез удвояване: "He said ""hello""". Поле, съдържащо буквален нов ред, също трябва да бъде в кавички. Анализатори, които пропускат тази стъпка, произвеждат грешки в броя на редовете, които са трудни за проследяване. Кодирането е отделен капан. CSV файловете от Windows инструменти често носят UTF-8 BOM (маркер за ред на байтовете: трите байта EF BB BF в началото на файла). BOM помага на Excel да идентифицира кодирането, но много анализатори в програмни езици третират BOM като част от името на първата колона, произвеждайки колона с името "id" вместо "id". Това нарушава всеки последващ код, който търси колони по име. При програмно четене на CSV файл, премахнете BOM преди анализиране или използвайте библиотека, която го обработва изрично.
Избор на формат: конфигурация, обмен и таблици
Изборът на формат обикновено се определя от контекста, не от предпочитанието. JSON е стандартният избор за REST API и обмен между браузър и сървър. Той е компактен, анализира се нативно от всеки програмен език и носи информация за тип за числа и булеви стойности. Слабостта му е липсата на коментари, което го прави неподходящ за файлове, които разработчиците четат и редактират ръчно. YAML се предпочита за конфигурационни файлове (манифести на Kubernetes, дефиниции на CI конвейери, Ansible playbooks), защото позволява вградени коментари и е по-лесен за четене от JSON с много нива на отстъп. Главният риск е, че грешките в отстъпа са мълчаливи: погрешно наредена ключова дума преминава в различен обхват без каквато и да е грешка при анализиране. XML остава стандарт в по-стари корпоративни системи, SOAP уеб услуги, формати на документи (DOCX, SVG, RSS) и контексти, изискващи валидиране на схема или разграничаване на пространство от имена. Той е многословен, но инструментите XPath и XSLT са зрели. CSV е правилният избор, когато данните са наистина плоски и потребителят е таблично приложение или анализатор на данни. Не е подходящ за конфигурация или API обмен, защото няма система от типове и няма вложеност.
Правете го локално с data-converter
Инструментът data-converter на този сайт анализира и конвертира между CSV, JSON и YAML изцяло вътре в браузъра; той не чете и не записва XML. В нито един момент не се предават данни към сървър. Конвертирането работи в локалното ви JavaScript изпълнение, а резултатът е достъпен за изтегляне или копиране, без нищо да напуска устройството ви. Това е важно за данни, които не са ваши за споделяне: API отговори, съдържащи лична информация, конфигурационни файлове с вътрешни имена на хостове или CSV износи от вътрешни бази данни. Поставянето на тези данни в уеб-базиран конвертор, работещ на сървър, означава, че съдържанието се изпраща по мрежата и се обработва на хардуер, върху който нямате контрол. С data-converter, разделът на браузъра е средата за обработка. Инструментът прилага RFC 4180 кавички при четене или запис на CSV и очаква плосък масив от обекти за JSON или YAML, преобразувани към CSV: вложена стойност от тип обект или масив под даден ключ не получава автоматично изравняване с точкова нотация, така че изравнете тези полета сами преди конвертиране, ако ви трябват като отделни колони. Ако трябва да преместите данни към или от XML, конвертирайте ги в JSON или YAML с отделен инструмент за XML първо, а после донесете резултата тук.
Инструменти от тази статия
Често задавани въпроси
Мога ли да прехвърля JSON през CSV и да получа оригинала обратно?
Само ако JSON е плосък масив от обекти без вложени полета и без масиви като стойности. В момента, в който имате вложен обект или стойност-масив, CSV представянето изисква структурно решение (колони с точкова нотация, множество редове или кодирани низове), което не може да бъде автоматично обърнато. Ако данните ви имат вложеност, JSON, XML или YAML ще се прехвърлят чисто; CSV не.
Защо CSV-ът ми изглежда грешен в Excel след износ от европейско приложение?
Европейските локали често използват точка и запетая като разделител в CSV, защото запетаите са запазени за десетична нотация. Excel на европейски локал очаква точка и запетая. Ако файлът използва запетаи, Excel третира целия ред като една колона. Решението е или да промените разделителя в настройките за износ, или да използвате съветника за импортиране на данни на Excel, който ви позволява да посочите разделителя ръчно. Проблемът с UTF-8 BOM е отделен: без BOM, Excel може също да чете неправилно символи с ударения като повреден текст.
Каква е разликата между YAML и JSON на практика?
И двата представят един и същ основен модел на данни: обекти, масиви, низове, числа, булеви стойности и null. YAML добавя коментари (редове, започващи с #), буквали на многоредови низове и референции тип котва за повтарящи се блокове. JSON е строго подмножество на валиден YAML, но анализаторите на JSON не четат YAML. Практическото правило: използвайте JSON за полезни товари на API и съхранение на данни; използвайте YAML за конфигурационни файлове, които хората редактират и които се възползват от вградени коментари.