JSON, XML или CSV? Как выбрать правильный формат данных для задачи
13 октября 2026 г.
JSON, XML и CSV все существуют для передачи структурированных данных между системами, но обращение с ними как со взаимозаменяемыми — верный способ довести интеграционный проект до потери данных, сломанных импортов или раздутых файлов. Каждый формат пошёл на реальные компромиссы ради задач и эпохи, для которых он создавался, и знание этих компромиссов делает выбор правильного формата для конкретной задачи простым.
В чём CSV реально хорош, а где он ломается?
CSV (значения, разделённые запятыми) — это едва ли не простейший из возможных структурированных форматов: обычный текст, одна строка на запись, значения разделены запятыми, — что делает его универсально читаемым программами для работы с таблицами, базами данных и практически любым когда-либо созданным инструментом для работы с данными. Он отлично подходит для плоских, табличных данных: списка записей, где у каждой строки одинаковые поля. Он ломается, как только у данных появляется реальная структура за пределами плоской таблицы — вложенные объекты, отношения «один ко многим» или поля, которые действительно содержат запятые или переносы строк (обрабатываемые непоследовательно в разных реализациях CSV), — всё это выходит за пределы того, для чего был создан CSV.
Почему JSON стал форматом по умолчанию именно для веб-API?
Структура объектов и массивов JSON почти напрямую ложится на то, как большинство современных языков программирования уже представляют данные в памяти, а значит полезная нагрузка JSON часто может быть разобрана прямо в нативную структуру данных с минимальной обработкой — важное практическое преимущество для веб-API, где скорость и простота как производства, так и потребления данных имеют значение. Он также сравнительно компактен и читаем человеком, обеспечивая баланс, который сделал его естественным выбором по умолчанию по мере распространения веб-API, во многом вытеснив XML из нового дизайна API, хотя XML появился раньше.
Что может XML структурно, а JSON — нет?
XML поддерживает атрибуты у элементов (метаданные, прикреплённые к самому тегу, отдельно от его содержимого), пространства имён (позволяющие избежать конфликтов имён при объединении словарей из разных источников) и зрелую формальную экосистему валидации по схеме (XSD) для строгого определения и обеспечения того, что именно должен содержать валидный документ, — возможности, которые более простая модель объектов/массивов JSON изначально не предоставляет (JSON Schema существует, но появилась позже и принята не так повсеместно). Именно поэтому XML сохраняется в областях, требующих строгой валидации документов, документов со смешанными словарями или давно устоявшихся корпоративных и государственных стандартов данных, появившихся раньше JSON.
Почему конвертация CSV во вложенный формат вроде JSON требует больше, чем механическое преобразование?
У CSV нет понятия вложенности — каждая строка плоская, — поэтому преобразование данных CSV в формат, поддерживающий иерархию (например, JSON, представляющий, скажем, заказ с несколькими позициями), требует реального решения о том, как плоские строки отображаются на вложенную структуру: становится ли каждая строка отдельным объектом верхнего уровня, или несколько строк с общим идентификатором группируются в один объект с вложенным массивом? Это решение о структуре невозможно восстановить из самих данных CSV — оно зависит от понимания реальных связей в данных, поэтому «просто сконвертируй мой CSV в JSON» иногда даёт технически валидный, но практически бесполезный результат, если структура не была явно задана.
Существенно ли различаются размер файла или скорость разбора между тремя форматами?
CSV обычно наиболее компактен для по-настоящему плоских, однородных данных, поскольку почти не имеет структурных накладных расходов — никаких повторяющихся имён тегов или ключей на каждую запись. JSON компактнее XML для тех же вложенных данных, поскольку у него нет избыточности закрывающих тегов XML, но несёт больше накладных расходов, чем CSV, из-за повторяющихся имён ключей в каждом объекте, если не используется более компактная кодировка на основе массивов. XML обычно самый объёмный из трёх форматов для эквивалентных данных из-за многословных открывающих и закрывающих тегов, хотя это редко становится решающим фактором по сравнению с тем, какие структурные возможности и экосистема инструментов реально нужны конкретной интеграции.