ИИ JSON конвертер

Форматы данных: JSON, YAML, CSV и PHP-массивы — когда и зачем их конвертировать

Мы храним и передаём конфигурации, ответы API, выгрузки из базы, прайс-листы — и каждый раз встаёт вопрос «в каком формате». Разберём четыре самых частых — JSON, YAML, CSV и нативный PHP-массив — по делу: чем они отличаются, для чего созданы, где ломаются и когда между ними действительно нужен конвертер.

Зачем вообще несколько форматов, если все они «про данные»

Потому что у каждого формата своя аудитория и задача:

• JSON создан для машин: это lingua franca веб-API. Строгий, однозначный, сериализуется в любом языке одной строчкой.
• YAML создан для человека: конфигурации, которые кто-то читает и правит руками (docker-compose, CI-пайплайны, Kubernetes-манифесты).
• CSV создан для таблиц: простейший способ перенести «строки и столбцы» между Excel, базами и скриптами.
• PHP-массив — это данные в их «родном» виде внутри кода: конфиг темы, результат get_option(), аргумент функции.

Формат хранения и формат потребления редко совпадают. Отсюда и конвертация: API вернул JSON, а бухгалтер просит Excel (CSV); конфиг человек написал в YAML, а скрипт читает только JSON; данные лежат в PHP-массиве, а их надо показать как JSON-ответ.

JSON: строгий ответственный за машины

JSON (RFC 8259) — набор типов: объект {}, массив [], строка "...", число, true/false, null.

Сильные стороны:

• Унификация: один и тот же текст читают PHP, JS, Python, Go.
• Вложенность «из коробки» — дерево любой глубины без костылей.
• Маппинг на объект/ассоциативный массив в любом языке тривиален.

Подводные камни:

• Нет комментариев. Хочешь пояснить конфиг — JSON не даст. Это главная причина, почему конфиги пишут в YAML.
• Нет типов-прирождённых для дат и бинарных данных. Дата — это строка, и каждый трактует её как хочет (2026-10-09, 09.10.2026, timestamp).
• null ≠ отсутствие поля. {"price": null} и {} — разные вещи для потребителя, и этот различие часто теряется при переносе в CSV.
• Ключи всегда строки. Числовой ключ {1: "a"} недопустим, будет {"1": "a"}.

{
  "id": 42,
  "title": "Куртка",
  "tags": ["winter", "sale"],
  "price": null,
  "stock": { "count": 7, "reserved": false }
}

YAML: для тех, кто правит конфиг руками

YAML 1.2 — надстройка над JSON (JSON-файл является валидным YAML), но заточен под чтение человеком: отступы вместо скобок, комментарии #, короткие формы.

# docker-compose-фрагмент
services:
  app:
    image: php:8.3-fpm
    ports:
      - "9000:9000"
    environment:
      - APP_ENV=production
      - DEBUG=false

Где YAML хорош: конфиги и пайплайны, которые читает инженер. Короткий, с комментариями, красиво вложенный.

Где YAML подлый (и почему его боятся):

• Отступы = синтаксис. Одна потерянная/лишняя пробел-строка меняет смысл или ломает разбор.
• «Эффект Норвегии»: значение NO (нет) в старом YAML парсилось как логический false — в Норвегии это «нет», а не «нет». on/off/yes/no/y/n трактовались как bool. Аналогично номера телефонов, ведущие нули (007 → число 7) теряются. В YAML 1.2 с этим аккуратнее, но старые парсеры живы.
• Табы вместо пробелов — файл не распарсится вообще.
• Альтернативная запись дерева через ?/: (complex keys) — мало кто читает.

Поэтому правило: для машин отдавайте JSON, для человека оставляйте YAML — и не путайте их в одном месте.

CSV: не «текст с запятыми», а стандарт

CSV (RFC 4180) — плоская таблица: строки разделителей, поля через запятую. Звучит просто, но именно здесь чаще всего портятся данные.

Правила, о которых забывают:

• Поле с запятой, кавычкой или переводом строки обязано быть в двойных кавычках, а внутренняя кавычка удваивается: "Добровольский, А." → корректно; Добровольский, А. → разъедется на два поля.
• Разделитель — не всегда запятая. В русской локали Excel это ;. Файл с ; внутри «англо-настроенного» Excel встанет в одну колонку.
• Разделитель тысяч и ведущие нули теряются, если число записать без кавычек (007 → 7).
• Кодировка. UTF-8 без BOM открывается в Excel Windows кракозябрами; с BOM — нормально. Это не баг данных, а баг «договорились о кодировке».
• Нет вложенности. Массив ["winter","sale"] в CSV — это уже проблема сериализации.

CSV не передаёт типы и структуру. Это формат «разгладить таблицу и показать человеку», не формат «сохранить дерево».

PHP-массив: данные дома

Внутри WordPress и PHP-приложений «формат данных» — это массив языка:

$cfg = [
  'id'    => 42,
  'tags'  => [ 'winter', 'sale' ],
  'price' => null,
  'stock' => [ 'count' => 7, 'reserved' => false ],
];

Синтаксис короткий ([]), ключи могут быть строками и числами, значения — любые, включая объекты и замыкания. Именно поэтому PHP-массив нельзя полноценно превратить в JSON/YAML/CSV: в JSON нет объектов-ресурсов и функций, в CSV нет вложенности. Конвертировать туда-сюда честно имеет смысл только для чистых данных (скаляры, массивы, вложенные массивы).

Когда что и во что конвертировать

Из таблицы видно главное: конвертация безопасна между JSON и YAML (общая модель дерева), а к CSV и PHP-массиву — с потерями или с оговорками. Именно эти оговорки и портят данные, если делать конвертацию «на глаз» или регулярками.

На что обратить внимание, чтобы не потерять данные

1. Типы. CSV не хранит типы — true/false/null превратятся в строки. Заранее решите, как маппить.
2. Вложенность. CSV её не принимает. Либо массивы становятся JSON-строкой в ячейке, либо таблица «разворачивается» (denormalization).
3. null vs "" vs отсутствие поля. Три разных состояния, а формат часто оставляет одно.
4. Кодировка и спецсимволы. UTF-8, кавычки, переводы строк внутри поля.
5. Разделители. Запятая/точка с запятой/табуляция; десятичная запятая в числах.
6. Ведущие нули и большие числа (штрих-коды, телефон) — теряются, если поле не строка.