Стаття
Конвертація між 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), оскільки він дозволяє вбудовані коментарі та є легшим для читання, ніж 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 для конфігураційних файлів, які редагують люди та яким корисні вбудовані коментарі.