Как уплощить вложенный JSON в CSV: 5 стратегий и матрица решений

Геометрическая задача

Каждый раз одна и та же стена. API возвращает вложенный JSON, а аналитик в Slack хочет просто таблицу. mongoexport выдаёт обёртки $oid и три уровня метаданных, а BigQuery ждёт плоскую таблицу. Уплощение вложенного JSON в CSV — задача не синтаксиса, а геометрии. JSON — дерево, CSV — сетка, и нельзя перенести дерево в сетку, не выбрав, как именно сложатся ветви.

Стратегий схлопывания ровно пять. Выберете не ту, и отправите аналитику в Excel 200 столбцов, потеряете точность на ID из Twitter или сломаете тот обратный обход, на котором держится pipeline. Выберете правильную, и конвертация умещается в одну строку.

Стратегия	Однострочник	Подходит для
Точечная нотация	`customer.address.city`	Анализа в Excel / Sheets
Подчёркивания	`customer_address_city`	SQL-совместимых столбцов
Индексные массивы	`items.0.sku, items.1.sku`	Массивов фиксированной длины
Разворот строк	Повторять родителя для каждого потомка	Аналитики в Pandas / BigQuery
Stringify	`"{\"city\":\"Seattle\"}"` в одной ячейке	Обратного обхода без потерь

Дальше идёт разбор каждой стратегии, матрица решений по конечному потребителю (Excel, Pandas, BigQuery, Postgres) и четыре реальных payload, где правильная стратегия неочевидна. Если нужен общий обзор обоих направлений (библиотеки разбора, потоковая обработка, ловушки кодировок), смотрите руководство по конвертации CSV ↔ JSON.

Почему вложенный JSON не помещается в CSV

JSON несёт три вида структуры, которых нет в CSV. Иерархия: объект внутри объекта. Последовательность: массив. Смешанная форма складывается из них: массивы объектов, объекты с массивами, массивы массивов. Типичный заказ в e-commerce объединяет все три сразу.

У CSV ровно два измерения: строки и столбцы. Нет третьей оси для «этот столбец содержит трёх потомков». Когда от дерева требуют сетку, чем-то приходится жертвовать. Либо разнести потомков по дополнительным столбцам (и смириться с именами вроде items.0.options.0.value), либо разнести их по дополнительным строкам (повторяя родительские поля), либо запихнуть их в одну ячейку как текст и перестать обращаться с ними как со структурой.

Каждая стратегия ниже отвечает на этот вопрос по-своему. Одни сохраняют читаемость и теряют безопасность обратного обхода, другие наоборот. Универсальной стратегии не существует. Ответ выбирают под того, кто будет читать файл следующим.

Сравнение 5 стратегий уплощения

Стратегия 1. Точечная нотация (`customer.address.city`)

Точечная нотация идёт от корня к листу и склеивает ключи через .. Каждый вложенный объект превращается в один столбец на лист, а путь закодирован в имени столбца.

{ "customer": { "address": { "city": "Seattle" } }, "email": "alice@example.com" }

превращается в

customer.address.city,email
Seattle,alice@example.com

В Pandas достаточно одной строки:

import pandas as pd

data = [{"customer": {"address": {"city": "Seattle"}}, "email": "alice@example.com"}]
df = pd.json_normalize(data, sep='.')
df.to_csv("out.csv", index=False)

В JavaScript хватает небольшой рекурсивной функции:

function flattenDot(obj, prefix = '', acc = {}) {
  for (const [k, v] of Object.entries(obj)) {
    const key = prefix ? `${prefix}.${k}` : k;
    if (v && typeof v === 'object' && !Array.isArray(v)) {
      flattenDot(v, key, acc);
    } else {
      acc[key] = v;
    }
  }
  return acc;
}

Плюсы: читается человеком, дефолт в Pandas, сохраняет исходный путь. Минусы: имена столбцов выходят длинными (спецификации Kubernetes порождают имена вида spec.template.spec.containers.0.resources.limits.memory), а точка становится неоднозначной, если настоящий ключ сам содержит . (так бывает у параметров событий Google Analytics 4).

Стратегия 2. Нотация с подчёркиваниями (`customer_address_city`)

Идея та же, разделитель другой. Замените . на _, и результат безопасен для SQL: SELECT customer_address_city FROM events работает без кавычек вокруг идентификатора. BigQuery, Snowflake и Postgres предпочитают именно это.

import pandas as pd
df = pd.json_normalize(data, sep='_')

Выбор между точкой и подчёркиванием сводится к целевому инструменту. Аналитикам в Excel точка читается естественнее; SQL-движки безропотно принимают подчёркивание. Переключение сводится к замене одного аргумента.

Плюсы: SQL-безопасные имена столбцов, идентификаторы совместимы с BigQuery, кавычки не нужны. Минусы: неоднозначность остаётся, если ключ содержит _ (реже, чем ., но всё же возможно).

Стратегия 3. Индексные массивы (`items.0.sku`, `items.1.sku`)

Объекты уплощаются чисто: ключи уникальны. С массивами так не выходит, потому что длина не ограничена. Индексная стратегия рассматривает позиции в массиве как сегменты пути: items[0] становится items.0.

{ "id": "ord-001", "items": [{"sku": "A"}, {"sku": "B"}] }

превращается в

id,items.0.sku,items.1.sku
ord-001,A,B

Это поведение Flatten по умолчанию в нашем конвертере JSON в CSV. Каждый лист получает собственный столбец; позиция фиксируется в имени.

Плюсы: каждое значение в своей ячейке, позиция сохранена, дублирования строк нет. Минусы: число столбцов взрывается (100 элементов = 100 столбцов); строки с массивами разной длины дают «рваные» таблицы; ломается агрегация ниже по pipeline (нет SUM(items.*.qty)).

Стратегия 4. Разворот строк (массив в несколько строк)

Вместо того чтобы расширять таблицу под массив, удлиняйте её. Повторите родительские поля по разу на каждый элемент массива, а сам элемент пусть станет отдельной строкой данных.

{ "order_id": "ord-001", "customer": "Alice", "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}] }

превращается в

order_id,customer,items.sku,items.qty
ord-001,Alice,A,2
ord-001,Alice,B,1

В Pandas одна строка делает и разворот, и нормализацию:

import pandas as pd

orders = [{"order_id": "ord-001", "customer": "Alice",
           "items": [{"sku": "A", "qty": 2}, {"sku": "B", "qty": 1}]}]
df = pd.json_normalize(orders, record_path='items', meta=['order_id', 'customer'])
df.to_csv("orders.csv", index=False)

В SQL то же самое делает UNNEST:

SELECT order_id, item.sku, item.qty FROM orders, UNNEST(items) AS item;

Плюсы: Pandas и BigQuery работают с такой формой нативно, агрегации работают (GROUP BY order_id), схема остаётся узкой. Минусы: родительские поля дублируются в каждой дочерней строке (раздутие хранилища), граница «один ко многим» неявная (нужен order_id), а два массива на одном уровне дают декартово произведение, если не сделать UNNEST аккуратно.

Стратегия 5. Stringify (JSON-в-ячейке)

Радикальный вариант: не уплощать вовсе. Сериализуйте всё вложенное значение как JSON-строку и положите в одну ячейку. Внешняя таблица остаётся плоской, а структура сохранена дословно внутри.

{ "id": "ord-001", "items": [{"sku": "A"}, {"sku": "B"}] }

превращается в

id,items
ord-001,"[{""sku"":""A""},{""sku"":""B""}]"

Это режим Stringify в нашем конвертере JSON в CSV. Число столбцов никогда не взрывается, исходная форма сохраняется байт в байт, а обратный путь восстанавливает вход в точности.

Плюсы: 100% без потерь, предсказуемое число столбцов, безопасный обратный обход в паре с Infer types на обратном направлении. Минусы: пользователи Excel видят экранированные кавычки, SQL-движкам нужны JSON-функции, чтобы запрашивать значение внутри (JSON_EXTRACT_SCALAR в BigQuery, ->>'key' в Postgres), а формулы в электронных таблицах не дотянутся внутрь ячейки.

5 стратегий бок о бок

Один и тот же вход на все пять: {"id":"ord-001","customer":{"name":"Alice"},"items":[{"sku":"A","qty":2},{"sku":"B","qty":1}]}.

Стратегия	Столбцы	Обратный обход безопасен	Лучший потребитель
Точечная нотация	растёт с массивом	Нет	Аналитик в Excel
Подчёркивания	растёт с массивом	Нет	SQL-хранилище
Индексные массивы	2 на слот массива	Нет (неоднозначно на обратном)	Массивы фиксированной длины
Разворот строк	узкая, 1 строка на потомка	Частично (нужен ключ)	Pandas / BigQuery
Stringify	фиксированное	Да	Обратный обход pipeline

Матрица решений: какая стратегия для какого потребителя

Найдите потребителя в первой колонке, во второй прочитайте рекомендованную стратегию.

Потребитель	Рекомендуемая стратегия	Почему
Excel / Sheets (аналитик)	Точка + Stringify для больших массивов	Читаемые имена столбцов; большие массивы не раздувают лист
Excel-EU (DE/FR/IT/ES)	Точка + разделитель `;` + UTF-8 BOM	Точка с запятой обязательна; BOM не даёт кодировке поплыть
Pandas (`json_normalize` + `explode`)	Подчёркивания + разворот строк	SQL-совместимые столбцы; explode хорошо ложится на `groupby`
BigQuery / Snowflake	TSV + Stringify или разворот	Табуляция обходит ловушки с кавычками; `JSON_EXTRACT` запрашивает значение в ячейке
PostgreSQL `COPY`	RFC 4180 + подчёркивания + плоско	SQL-безопасные столбцы; строгое RFC-кавычение
MongoDB → BigQuery ETL	Загружать NDJSON напрямую, минуя CSV	BigQuery грузит NDJSON нативно; CSV даёт лишний крюк

Excel / Google Sheets: ловушка локали

У имён столбцов Excel нет практического лимита по длине. Реальных ловушек три.

Первая ловушка, расщепление по локали. Европейский Excel (Германия, Франция, Италия, Испания) ждёт ; в качестве разделителя, потому что , уходит под десятичный разделитель. CSV с запятой открывается так, что каждая строка схлопывается в столбец A. Пресет Excel в нашем инструменте json-to-csv одним кликом переключает на ; + CRLF + UTF-8 BOM.

Вторая ловушка, научная нотация. Excel видит 9007199254740993 и отрисовывает 9.00719925474E+15. Храните большие целые как строки в исходном JSON и включите BOM, чтобы Excel оставлял ячейку как текст. Наш конвертер обнаруживает большие целые автоматически.

Третья ловушка, практический лимит столбцов. Excel теоретически поддерживает 16 384 столбца, но всё, что выше примерно 500, становится неуправляемым. Сделайте Stringify для тяжёлых поддеревьев или предварительно спроецируйте через jq перед конвертацией.

Pandas: `json_normalize` + `explode`

Стандартный шаблон для вложенных массивов: record_path + meta за один проход.

import pandas as pd

orders = [{
    "order_id": "ord-001",
    "customer": {"name": "Alice", "city": "Seattle"},
    "items": [{"sku": "SKU-100", "qty": 2}, {"sku": "SKU-205", "qty": 1}]
}]

df = pd.json_normalize(orders, record_path='items',
    meta=['order_id', ['customer', 'name'], ['customer', 'city']], sep='_')
df.to_csv("orders.csv", index=False)

На выходе будет одна строка на элемент с повторяющимися order_id, customer_name и customer_city. Этот способ выигрывает у варианта «сначала explode, потом json_normalize»: record_path пропускает промежуточный столбец-объект, а meta позволяет управлять тем, какие родительские поля распространяются. Если элементы массива содержат вложенные объекты, ограничьте глубину через max_level=.

BigQuery / Snowflake: TSV + JSON-в-ячейке

LOAD DATA в BigQuery строг к кавычкам в CSV и часто неправильно разбирает файлы, где запятые встречаются внутри текста в кавычках. TSV безопаснее, потому что табуляция почти не встречается внутри текстовых полей:

bq load --source_format=CSV --field_delimiter='\t' \
  dataset.orders gs://bucket/orders.tsv \
  order_id:STRING,customer:STRING,items:STRING

Когда вложенные данные загружены как Stringify JSON в один столбец, BigQuery всё равно запрашивает их через JSON_EXTRACT_SCALAR:

SELECT order_id, JSON_EXTRACT_SCALAR(items, '$[0].sku') AS first_sku
FROM dataset.orders;

Snowflake даёт ту же возможность через VARIANT с path-запросами вида items:0.sku::STRING. В обоих движках Stringify + JSON path-запросы выигрывают у полного уплощения, когда вложенные массивы большие или переменной длины.

PostgreSQL `COPY`: строгий RFC 4180

COPY ... FROM ... WITH (FORMAT csv, HEADER true) — самый строгий ридер RFC 4180, который обычно встречается. Два поведения сбивают с толку.

Во-первых, COPY не принимает UTF-8 BOM. Метка порядка байтов становится буквальным префиксом первого имени столбца (id вместо id), и каждый запрос к id молча падает. Для Postgres выключайте BOM.

Во-вторых, COPY не умеет нативно разбирать вложенные данные. Либо разверните массивы в несколько строк перед загрузкой, либо опишите целевое поле как jsonb и сделайте Stringify вложенного значения:

CREATE TABLE orders (order_id text PRIMARY KEY, customer text, items jsonb);
COPY orders FROM '/tmp/orders.csv' WITH (FORMAT csv, HEADER true);
SELECT order_id, items->0->>'sku' AS first_sku FROM orders;

Для pipeline, говорящего на JSON из конца в конец, обойдите CSV и используйте COPY ... FROM ... WITH (FORMAT text) со входом в виде JSON-строк.

Разбор реальных payload

Разбор 1. Заказы e-commerce (customer + массив items)

Типичный заказ объединяет вложенные данные о клиенте и массив items переменной длины:

[{ "id": "ord-001",
   "customer": { "name": "Alice", "address": {"city": "Seattle", "country": "US"} },
   "items": [{"sku": "SKU-100", "qty": 2}, {"sku": "SKU-205", "qty": 1}] }]

Правильная стратегия зависит от того, кто читает файл. Финансам нужна одна строка на элемент, чтобы посчитать выручку по SKU; это стратегия explode, которая даёт две строки с повторяющимися id и customer.name. Операционке нужна одна строка на заказ для дашбордов фулфилмента; это точечная нотация со Stringify для items, чтобы массив не раздул число столбцов. Один вход, два выхода, оба правильные для своего потребителя.

Попробуйте напрямую: вставьте payload в наш конвертер JSON в CSV и переключите Flatten / Stringify на опции Nested. Пример «Nested E-commerce Orders» загружает ту же форму.

Разбор 2. GitHub Issues API (массив labels + объект user)

Endpoint /repos/{owner}/{repo}/issues возвращает смешанную вложенную форму:

[{ "id": 1001, "title": "Bug: login 404", "state": "open",
   "labels": ["bug", "priority:high"], "user": {"login": "alice"} }]

У user одно полезное поле, у labels строковый массив неограниченной длины. Прагматичный flatten гибридный: точечная нотация для user (нужен только user.login), а labels встроенно склеить в одну ячейку через ;.

id,title,state,labels,user.login
1001,Bug: login 404,open,bug;priority:high,alice

В одной стратегии не получится одновременно и «склеить массивы в ячейку», и «уплощать объекты через точки». Уплощение объектов наш конвертер делает автоматически; labels препроцессируйте через jq (map(.labels = (.labels | join(";")))) или соглашайтесь на дефолтное поведение со Stringify массивов.

Разбор 3. MongoDB `mongoexport` ($oid + метаданные)

mongoexport --jsonArray выдаёт обёртки Extended JSON:

[{ "_id": {"$oid": "6634a1b2c3d4e5f600000001"},
   "email": "alice@example.com",
   "metadata": { "signupDate": "2026-01-15T10:30:00Z",
                 "preferences": {"newsletter": true, "theme": "dark"} } }]

Обёртка $oid даёт столбец с буквальным именем _id.$oid, который большинство SQL-движков отвергает. Препроцессируйте через jq, чтобы её снять:

mongoexport --collection=users --jsonArray | jq 'map(._id = ._id."$oid")' > users.json

Для глубоко вложенного блока metadata.preferences выбор зависит от потребителя. Аналитический экспорт: уплощайте всё через точку, metadata.preferences.theme читается нормально. Обратный обход pipeline: сделайте Stringify для metadata, чтобы структура осталась целой. Полные шаблоны jq для CSV-pipeline смотрите в нашей шпаргалке по jq.

Разбор 4. Спецификация Kubernetes Pod (глубоко вложенная)

Ответ kubectl get pod -o json представляет худший случай для плоских стратегий. Структура регулярно уходит на шесть уровней вглубь (spec.template.spec.containers.0.resources.limits.memory). Наивное точечное уплощение даёт имена столбцов длиннее 70 символов и 200+ столбцов на выходе. Работают два подхода.

Предварительная проекция через kubectl jsonpath. Берите только те поля, которые действительно нужны:

kubectl get pods -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.spec.containers[0].image}{"\t"}{.status.phase}{"\n"}{end}' > pods.tsv

Stringify для spec, уплощение для metadata. Оставьте metadata (name, namespace, labels) плоской, а spec загоните в одну ячейку.

kubectl get pods -o json | jq 'map({name: .metadata.name, namespace: .metadata.namespace, spec: (.spec | tostring)})'

Затем вставьте в конвертер в режиме Flatten. Столбец spec становится одной JSON-ячейкой; столбцы metadata остаются читаемыми. Избегайте антипаттерна kubectl get pod -o json | json-to-csv flatten без предварительной проекции. Число столбцов получится неподъёмным.

Безопасность обратного обхода: уплощение с потерями, Stringify без потерь

Теорема, которую конкурирующие гайды обходят стороной: точечная нотация, нотация с подчёркиваниями, индексные массивы и разворот строк работают как односторонние проекции. Уплотнив любым из этих способов, исходный JSON уже нельзя идеально восстановить из одного только CSV.

Контрпримеры строятся легко. Столбец с именем customer.address.city неоднозначен между {"customer": {"address": {"city": "..."}}} и {"customer": {"address.city": "..."}}. Индексные массивы выглядят обратимыми, но CSV не может сказать, должен ли items.0.sku восстанавливаться как массив или как объект с числовым ключом. Разворот строк требует ключа группировки; без order_id нельзя сказать, какие строки относились к одному родителю.

Только Stringify выживает в обратном обходе. Вложенное значение сохраняется дословно как JSON-строка, поэтому обратный конвертер читает ячейку, разбирает её и вставляет оригинал нетронутым. Сделайте конвертацию через Stringify, сохраните CSV, вставьте в наш конвертер CSV в JSON, включите Infer types, и получите байты, идентичные входу.

Практическое правило: обратный обход pipeline → Stringify. Разовый анализ или отчёт → точка, подчёркивание или разворот, в зависимости от потребителя.

Как это сделать в нашем браузерном инструменте

Конвертер JSON в CSV напрямую предоставляет две из пяти стратегий: Flatten (объединение точечной нотации и индексных массивов) и Stringify (сохранение структуры внутри ячейки). До остальных трёх (подчёркивание, разворот строк, пресеты под SQL) хватает одного шага препроцессинга.

Типичный сеанс укладывается в пять кликов.

Проверьте вход в нашем форматировщике JSON, чтобы синтаксические ошибки не превратились в молчаливые сбои конвертации.
Вставьте JSON в конвертер JSON в CSV. Конвертация запускается мгновенно.
Поставьте Nested в Flatten для точечных и индексных ключей или в Stringify, чтобы массивы и объекты остались в одиночных ячейках.
Выберите пресет: RFC 4180 для pipeline, Excel для европейских таблиц, TSV для хранилищ, Pipe для текста с большим количеством запятых.
Нажмите Swap direction и проверьте обратный обход через Stringify в конвертере CSV в JSON с включённым Infer types.

Всё работает в браузере. Персональные данные, внутренние выгрузки и production-секреты никуда не уходят со страницы; сетевых запросов после загрузки страницы не отправляется. Безопасно для чувствительных данных, когда выгружать на сторонний сайт нельзя.

Частые ловушки

Шесть режимов отказа встречаются снова и снова.

Взрыв имён столбцов. Спецификации Kubernetes и треды ревью PR на GitHub порождают сотни путей-листов. Что делать: предварительно проецируйте через jq или kubectl jsonpath либо делайте Stringify тяжёлых поддеревьев при уплощении метаданных.
Несовпадение длин массивов. Строка 1 имеет 3 элемента, строка 2 — 5. Индексные массивы дают пустые ячейки в items.3.sku и items.4.sku для строки 1. Что делать: переключайтесь на разворот строк.
Индексные ключи становятся строками при обратном обходе. Когда CSV-to-JSON видит items.0.sku, 0 технически является строковым ключом. Некоторые обратные конвертеры восстанавливают {"0": {"sku": "A"}} вместо [{"sku": "A"}]. Что делать: для обратного обхода используйте Stringify.
Ключи, уже содержащие разделитель. У событий GA4 есть ключи вида event_params.key с буквальной точкой; уплощение через . даёт неоднозначные пути. Что делать: используйте подчёркивание или переименуйте проблемные ключи. Контекст по форматам JSON с расширенной поддержкой ключей собран в нашем руководстве по JSON5 и JSONC.
Смешанные типы на одном уровне. В одних строках address — объект, в других null. Уплощение даёт пустые ячейки там, где объект был null. Предупреждение о schema notes в нашем конвертере подсветит это, чтобы вы могли проверить, как себя поведёт потребитель ниже.
Большие целые, обрезанные Excel. $oid Long, snowflake ID из Twitter или K8s resourceVersion превышают безопасный диапазон JavaScript (2^53 − 1) и молча округляются. Excel затем отрисовывает их как 9.00719925474E+15. Что делать: храните ID как строки в исходном JSON, включайте BOM и используйте пресет Excel.

FAQ

Какой лучший способ уплощить вложенный JSON в CSV?

Лучший способ уплощить вложенный JSON в CSV зависит от потребителя ниже по pipeline. Используйте точечную нотацию для Excel или Google Sheets. Используйте разворот строк, когда Pandas или BigQuery будут агрегировать данные. Используйте Stringify, когда CSV должен без потерь вернуться обратно в JSON. Стратегию подбирайте под следующего читателя.

Как преобразовать массив JSON в несколько строк CSV?

Преобразуйте массив JSON в несколько строк CSV через стратегию explode: продублируйте родительские поля по разу на каждый элемент массива, чтобы каждый стал собственной строкой данных. В Pandas это делается одним вызовом: pd.json_normalize(data, record_path='items', meta=['order_id']). В SQL такую же форму даёт UNNEST(items). Родительские ключи повторяются по всем развёрнутым строкам.

Можно ли вернуть CSV обратно в исходный вложенный JSON?

Возврат CSV обратно в исходный вложенный JSON работает только в режиме Stringify. Точечная нотация, подчёркивания, индексные массивы и разворот строк — односторонние проекции с потерями; обратный конвертер не может идеально восстановить дерево. Stringify сохраняет массивы и объекты как JSON внутри одной ячейки, поэтому полный обратный обход побайтово идентичен входу, когда включён Infer types.

Почему Excel показывает мой уплощённый JSON в один длинный столбец?

Excel показывает уплощённый JSON в один длинный столбец, когда вы находитесь в европейской локали (Германия, Франция, Италия, Испания), где запятая зарезервирована для дробной части, а Excel ждёт точку с запятой в качестве разделителя. Пресет Excel в json-to-csv одним кликом переключает на ; + CRLF + UTF-8 BOM.

Что выбрать для имён столбцов: точечную нотацию или подчёркивания?

Используйте точечную нотацию, когда цель Excel, Google Sheets или Pandas; точки идут как дефолт json_normalize и читаются естественно. Используйте подчёркивания, когда цель SQL: Postgres, BigQuery и Snowflake требуют кавычек вокруг идентификаторов с точкой, а подчёркивания принимаются без кавычек везде.

Как pandas json_normalize работает с массивами объектов?

Pandas json_normalize работает с массивами объектов через аргументы record_path и meta. pd.json_normalize(data, record_path='items', meta=['order_id']) разворачивает items в одну строку на элемент с повторяющимся order_id. Для вложенных объектов без массивов более простой pd.json_normalize(data, sep='_') даёт имена столбцов через подчёркивание, например customer_address_city. Для глубоких деревьев ограничивайте глубину через max_level=.

Каков лимит столбцов при уплощении глубоко вложенного JSON?

Лимит столбцов при уплощении глубоко вложенного JSON составляет 16 384 в Excel и практически не ограничен в самом CSV, но после 500 столбцов вывод становится неуправляемым. Спецификации Kubernetes Pod или ответы GraphQL легко это превышают. Сделайте Stringify для тяжёлых поддеревьев в конвертере JSON в CSV или предварительно спроецируйте через jq либо kubectl jsonpath.

Подходит ли jq для уплощения JSON перед конвертацией в CSV?

Да, jq подходит как инструмент для уплощения JSON перед конвертацией в CSV. Он берёт на себя предварительную проекцию (map({id, name})), предварительный разворот (.[] | {id, item: .items[]}) и нормализацию формы в одну строку. Конвейер jq идёт перед шагом CSV и точно контролирует, какие поля доходят до конвертера. Шаблоны смотрите в нашей шпаргалке по jq.

Заключение

Пять выводов:

JSON-to-CSV — задача геометрии, а не синтаксиса. Дерево не помещается в сетку, пока не выбрано, как сложатся ветви.
Пять стратегий покрывают практическую вселенную (точка, подчёркивание, индексные массивы, разворот строк, Stringify). Выбирайте по потребителю.
Stringify остаётся единственным путём без потерь. Используйте его для обратного обхода pipeline.
У Excel-EU и BigQuery пресеты не просто так. Пользуйтесь ими.
Реальные payload (mongoexport, спецификации Kubernetes, ответы GitHub) почти всегда требуют сначала шага предварительной проекции через jq или kubectl jsonpath.

Попробуйте свой payload в конвертере JSON в CSV. Работает локально, поддерживает все пять стратегий, делает обратный обход без потерь со Stringify. Без загрузки, без регистрации, ничего не уходит со страницы.

Уплощение вложенного JSON в CSV: 5 стратегий и матрица решений

Как уплощить вложенный JSON в CSV: 5 стратегий и матрица решений

Геометрическая задача

Почему вложенный JSON не помещается в CSV

Сравнение 5 стратегий уплощения

Стратегия 1. Точечная нотация (`customer.address.city`)

Стратегия 2. Нотация с подчёркиваниями (`customer_address_city`)

Стратегия 3. Индексные массивы (`items.0.sku`, `items.1.sku`)

Стратегия 4. Разворот строк (массив в несколько строк)

Стратегия 5. Stringify (JSON-в-ячейке)

5 стратегий бок о бок

Матрица решений: какая стратегия для какого потребителя

Excel / Google Sheets: ловушка локали

Pandas: `json_normalize` + `explode`

BigQuery / Snowflake: TSV + JSON-в-ячейке

PostgreSQL `COPY`: строгий RFC 4180

Разбор реальных payload

Разбор 1. Заказы e-commerce (customer + массив items)

Разбор 2. GitHub Issues API (массив labels + объект user)

Разбор 3. MongoDB `mongoexport` ($oid + метаданные)

Разбор 4. Спецификация Kubernetes Pod (глубоко вложенная)

Безопасность обратного обхода: уплощение с потерями, Stringify без потерь

Как это сделать в нашем браузерном инструменте

Частые ловушки

FAQ

Какой лучший способ уплощить вложенный JSON в CSV?

Как преобразовать массив JSON в несколько строк CSV?

Можно ли вернуть CSV обратно в исходный вложенный JSON?

Почему Excel показывает мой уплощённый JSON в один длинный столбец?

Что выбрать для имён столбцов: точечную нотацию или подчёркивания?

Как pandas json_normalize работает с массивами объектов?

Каков лимит столбцов при уплощении глубоко вложенного JSON?

Подходит ли jq для уплощения JSON перед конвертацией в CSV?

Заключение

Похожие статьи

Шпаргалка Regex: метасимволы, группы и lookaround

HTTP-коды состояния: шпаргалка (1xx-5xx) с примерами

Валидация JSON Schema в 2026: гид по Ajv, Python и браузеру

Как уплощить вложенный JSON в CSV: 5 стратегий и матрица решений

Геометрическая задача

Почему вложенный JSON не помещается в CSV

Сравнение 5 стратегий уплощения

Стратегия 1. Точечная нотация (customer.address.city)

Стратегия 2. Нотация с подчёркиваниями (customer_address_city)

Стратегия 3. Индексные массивы (items.0.sku, items.1.sku)

Стратегия 4. Разворот строк (массив в несколько строк)

Стратегия 5. Stringify (JSON-в-ячейке)

5 стратегий бок о бок

Матрица решений: какая стратегия для какого потребителя

Excel / Google Sheets: ловушка локали

Pandas: json_normalize + explode

BigQuery / Snowflake: TSV + JSON-в-ячейке

PostgreSQL COPY: строгий RFC 4180

Разбор реальных payload

Разбор 1. Заказы e-commerce (customer + массив items)

Разбор 2. GitHub Issues API (массив labels + объект user)

Разбор 3. MongoDB mongoexport ($oid + метаданные)

Разбор 4. Спецификация Kubernetes Pod (глубоко вложенная)

Безопасность обратного обхода: уплощение с потерями, Stringify без потерь

Как это сделать в нашем браузерном инструменте

Частые ловушки

FAQ

Какой лучший способ уплощить вложенный JSON в CSV?

Как преобразовать массив JSON в несколько строк CSV?

Можно ли вернуть CSV обратно в исходный вложенный JSON?

Почему Excel показывает мой уплощённый JSON в один длинный столбец?

Что выбрать для имён столбцов: точечную нотацию или подчёркивания?

Как pandas json_normalize работает с массивами объектов?

Каков лимит столбцов при уплощении глубоко вложенного JSON?

Подходит ли jq для уплощения JSON перед конвертацией в CSV?

Заключение

Похожие статьи

Шпаргалка Regex: метасимволы, группы и lookaround

HTTP-коды состояния: шпаргалка (1xx-5xx) с примерами

Валидация JSON Schema в 2026: гид по Ajv, Python и браузеру

Стратегия 1. Точечная нотация (`customer.address.city`)

Стратегия 2. Нотация с подчёркиваниями (`customer_address_city`)

Стратегия 3. Индексные массивы (`items.0.sku`, `items.1.sku`)

Pandas: `json_normalize` + `explode`

PostgreSQL `COPY`: строгий RFC 4180

Разбор 3. MongoDB `mongoexport` ($oid + метаданные)