İç içe JSON’u CSV’ye nasıl düzleştirirsiniz: 5 strateji ve karar matrisi

Geometri sorunu

Her seferinde aynı duvara çarparsınız. Bir API iç içe JSON döndürür ve Slack’teki analist sadece bir hesap tablosu ister. mongoexport $oid sarmalayıcılar ve üç katman üst veri üretir, BigQuery ise düz bir tablo bekler. İç içe JSON’u CSV’ye düzleştirmek sözdizimi değil geometri problemidir. JSON bir ağaçtır, CSV bir ızgaradır ve dalların nasıl çökeceğini seçmeden ağacı ızgaraya taşıyamazsınız.

Tam olarak beş çökertme stratejisi vardır. Yanlışını seçerseniz Excel’e 200 sütun gönderirsiniz, bir Twitter ID’sinde hassasiyet kaybedersiniz veya hattınızın bağımlı olduğu gidiş-dönüşü bozarsınız. Doğrusunu seçerseniz dönüşüm tek satırlık bir iştir.

Strateji	Tek satır	En uygun
Nokta notasyonu	customer.address.city	Excel/Sheets analizi
Alt çizgi	customer_address_city	SQL dostu sütunlar
Dizinli diziler	items.0.sku, items.1.sku	Sabit boyutlu diziler
Satır patlatma	Her çocuk için ebeveyni tekrarla	Pandas/BigQuery analitiği
Stringify	Tek hücrede "{\"city\":\"Seattle\"}"	Kayıpsız gidiş-dönüş

Bu rehber her stratejiyi adım adım anlatır, tüketici (Excel, Pandas, BigQuery, Postgres) bazlı bir karar matrisi sunar ve doğru stratejinin göründüğü kadar net olmadığı dört gerçek payload gösterir. Genel çift yönlü genel bakış (çözümleyici kütüphaneleri, akış, kodlama tuzakları) için CSV’den JSON’a Dönüştürme rehberine bakın.

İç içe JSON neden CSV’ye sığmaz

JSON, CSV’de bulunmayan üç tür yapı taşır. Hiyerarşi bir nesne içindeki nesnedir. Sıra bir dizidir. Karışık ise kombinasyondur: nesne dizileri, dizili nesneler, dizi dizileri. Tipik bir e-ticaret siparişi aynı anda her üçüdür.

CSV’nin tam olarak iki boyutu vardır: satırlar ve sütunlar. “Bu sütun üç çocuk tutuyor” için üçüncü bir eksen yoktur. Bir ağaçtan ızgara talep ettiğinizde bir şey verir. Ya çocukları daha fazla sütuna yayarsınız (ve items.0.options.0.value gibi adlarla yaşarsınız), ya daha fazla satıra yayarsınız (ebeveyn alanlar tekrar eder), ya da onları metin olarak tek hücreye sıkıştırıp yapı olarak ele almayı bırakırsınız.

Aşağıdaki her strateji bu soruyu farklı yanıtlar. Bazıları okunabilirliği korur ve gidiş-dönüş güvenliğini kaybeder. Diğerleri tam tersini yapar. Hiçbiri evrensel değildir. Yanıtı dosyayı bir sonra kimin okuyacağına eşleyin.

Karşılaştırmalı 5 düzleştirme stratejisi

Strateji 1: nokta notasyonu (customer.address.city)

Nokta notasyonu kökten yaprağa yürür ve anahtarları birleştirmek için . kullanır. Her iç içe nesne, her yaprak için bir sütun olur ve yol sütun adında kodlanır.

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

şuna dönüşür

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

Pandas’ta tek satır yeterlidir:

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’te küçük bir özyinelemeli işlev yeter:

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;
}

Artıları: insan tarafından okunabilir, Pandas varsayılanı, orijinal yolu korur. Eksileri: sütun adları uzayabilir (Kubernetes spec’leri spec.template.spec.containers.0.resources.limits.memory gibi adlar üretir) ve gerçek bir anahtar . içeriyorsa nokta belirsizleşir (Google Analytics 4 olay parametreleri içerir).

Strateji 2: alt çizgi notasyonu (customer_address_city)

Aynı fikir, farklı ayraç. . yerine _ koyun ve sonuç SQL güvenli olur: SELECT customer_address_city FROM events tanımlayıcıyı tırnak içine almadan çalışır. BigQuery, Snowflake ve Postgres bunu tercih eder.

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

Nokta ile alt çizgi arasındaki karar yalnızca alt katman aracıyla ilgilidir. Excel analistleri noktayı daha doğal okur; SQL motorları alt çizgiyi şikayetsiz kabul eder. Tek argümanı değiştirerek geçiş yapın.

Artıları: SQL güvenli sütun adları, BigQuery uyumlu tanımlayıcılar, tırnak gerekmez. Eksileri: bir anahtar _ içeriyorsa belirsizlik kalır (.’dan daha az yaygın ama yine de mümkün).

Strateji 3: dizinli diziler (items.0.sku, items.1.sku)

Nesneler temiz düzleşir çünkü anahtarlar benzersizdir. Diziler düzleşmez çünkü uzunluk sınırsızdır. Dizinli strateji dizi konumlarını yol bölümü olarak ele alır: items[0] items.0 olur.

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

şuna dönüşür

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

Bu, JSON’dan CSV’ye Dönüştürücü aracımızdaki varsayılan Düzleştir davranışıdır. Her yaprak kendi sütununu alır; konum adda kaydedilir.

Artıları: her değer kendi hücresini alır, konum korunur, satır çoğaltılmaz. Eksileri: sütun sayısı patlar (100 öğe = 100 sütun); farklı dizi uzunluklarına sahip satırlar düzensiz tablolar üretir; alt katman toplama bozulur (yok SUM(items.*.qty)).

Strateji 4: satır patlatma (dizi birden çok satıra)

Tabloyu diziye uydurmak için genişletmek yerine uzatın. Ebeveyn alanlarını her dizi öğesi için bir kez tekrarlayın ve her öğenin kendi satırı olmasına izin verin.

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

şuna dönüşür

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

Pandas’ta tek satır hem patlatmayı hem de normalleştirmeyi yapar:

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’de UNNEST aynı işi yapar:

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

Artıları: Pandas ve BigQuery bu şekli yerel olarak işler, toplamalar çalışır (GROUP BY order_id), şema dar kalır. Eksileri: ebeveyn alanlar her çocuk satırda çoğalır (depolama şişmesi), 1-çok sınırı örtüktür (bir order_id’ye ihtiyacınız vardır) ve aynı düzeydeki iki dizi, dikkatli UNNEST etmediğiniz sürece Kartezyen çarpım üretir.

Strateji 5: stringify (hücrede JSON)

Beşinci yaklaşım: hiç düzleştirmeyin. Tüm iç içe değeri bir JSON karakter dizisi olarak serileştirin ve tek bir hücreye koyun. Dış tablo düz kalır; yapı içeride aynen korunur.

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

şuna dönüşür

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

Bu, JSON’dan CSV’ye Dönüştürücü aracımızdaki Stringify modudur. Sütun sayısı asla patlamaz, orijinal şekil bayt bayt korunur ve ters yolculuk girişi tam olarak yeniden oluşturur.

Artıları: %100 kayıpsız, öngörülebilir sütun sayısı, tersine çevrildiğinde Infer types ile eşleştirildiğinde gidiş-dönüş güvenli. Eksileri: Excel kullanıcıları kaçışlı tırnak görür, SQL motorlarının değere sorgu yapmak için JSON işlevlerine ihtiyacı vardır (BigQuery’de JSON_EXTRACT_SCALAR, Postgres’te ->>'key') ve hesap tablosu formülleri hücreye ulaşamaz.

5 strateji yan yana

Beşinin de aynı girişi: {"id":"ord-001","customer":{"name":"Alice"},"items":[{"sku":"A","qty":2},{"sku":"B","qty":1}]}.

Strateji	Sütunlar	Gidiş-dönüş güvenli	En iyi tüketici
Nokta notasyonu	dizi ile büyür	Hayır	Excel analisti
Alt çizgi	dizi ile büyür	Hayır	SQL ambarı
Dizinli diziler	dizi yuvası başına 2	Hayır (tersine belirsiz)	Sabit boyutlu diziler
Satır patlatma	dar, çocuk başına 1 satır	Kısmi (anahtar gerekir)	Pandas / BigQuery
Stringify	sabit	Evet	Hat gidiş-dönüşü

Karar matrisi: hangi tüketici için hangi strateji

Önce tüketiciyi bulun, sonra önerilen stratejiyi okuyun.

Tüketici	Önerilen strateji	Neden
Excel / Sheets (analist)	Nokta + büyük diziler için Stringify	Okunabilir sütun adları; büyük diziler sayfayı patlatmaz
Excel-EU (DE/FR/IT/ES)	Nokta + ; sınırlayıcı + UTF-8 BOM	Noktalı virgül gerekli; BOM kodlama bozukluğunu önler
Pandas (json_normalize + explode)	Alt çizgi + Satır patlatma	SQL dostu sütunlar; patlatma groupby ile iyi çalışır
BigQuery / Snowflake	TSV + Stringify veya Patlatma	Sekme tırnak tuzaklarını önler; JSON_EXTRACT hücreye sorgu yapar
PostgreSQL COPY	RFC 4180 + Alt çizgi + düz	SQL güvenli sütunlar; katı RFC tırnaklama
MongoDB → BigQuery ETL	NDJSON’u doğrudan yükle, CSV’yi atla	BigQuery NDJSON’u yerel olarak yükler; CSV bir sapmadır

Excel / Google Sheets: yerel ayar tuzağı

Excel sütun adlarının pratik bir uzunluk sınırı yoktur. Gerçek tuzaklar üç tanedir.

İlki, yerel ayar bölünmesi. Avrupa Excel’i (Almanya, Fransa, İtalya, İspanya) sınırlayıcı olarak ; bekler çünkü , ondalık ayırıcıdır. Virgülle sınırlandırılmış bir CSV her satır A sütununda çökmüş olarak açılır. json-to-csv aracımızdaki Excel ön ayarı tek tıklamayla ; + CRLF + UTF-8 BOM’a geçer.

İkincisi, bilimsel gösterim. Excel 9007199254740993 görür ve 9.00719925474E+15 olarak render eder. Büyük tam sayıları kaynak JSON’da karakter dizisi olarak saklayın ve Excel’in hücreyi metin olarak tutması için BOM’u açın. Dönüştürücümüz büyük tam sayıları otomatik algılar.

Üçüncüsü, pratik sütun limiti. Excel teorik olarak 16.384 sütun destekler ancak ~500’ün üzerinde her şey yönetilemez hale gelir. Ağır alt ağaçları stringify edin veya dönüştürmeden önce jq ile ön-projeksiyon yapın.

Pandas: json_normalize + explode

İç içe diziler için standart desen tek geçişte record_path + meta’dır:

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)

Çıktı, order_id, customer_name ve customer_city tekrarlanmış olarak öğe başına bir satırdır. Bu, önce explode çalıştırmaktan ve sonra json_normalize yapmaktan daha iyidir: record_path ara nesne sütununu atlar ve meta hangi ebeveyn alanların yayılacağını kontrol etmenizi sağlar. Dizi öğelerinin iç içe nesneler içerdiği girişlerde derinliği sınırlamak için max_level= ayarlayın.

BigQuery / Snowflake: TSV + hücrede JSON

BigQuery’nin LOAD DATA’sı CSV tırnaklaması konusunda katıdır ve genellikle tırnak içindeki metnin içinde virgül olan dosyaları yanlış çözümler. TSV daha güvenlidir çünkü sekmeler neredeyse hiç metin alanlarının içinde görünmez:

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

İç içe veriyi tek bir sütunda Stringified JSON olarak yüklediğinizde, BigQuery yine JSON_EXTRACT_SCALAR ile içine sorgu yapar:

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

Snowflake aynı yeteneği VARIANT üzerinden sağlar, items:0.sku::STRING gibi yol sorgularıyla. Her iki motorda da iç içe diziler büyük veya değişken uzunlukta olduğunda Stringify + JSON yol sorguları tam düzleştirmeyi yener.

PostgreSQL COPY: katı RFC 4180

COPY ... FROM ... WITH (FORMAT csv, HEADER true) yaygın olarak karşılaşacağınız en katı RFC 4180 okuyucusudur. İki davranış insanları tökezletir.

İlki, COPY bir UTF-8 BOM kabul etmez. Bayt sırası işareti ilk sütun adına gerçek bir önek olur (id yerine id) ve id’ye atıfta bulunan her sorgu sessizce başarısız olur. Postgres hedefleri için BOM’u kapatın.

İkincisi, COPY iç içe veriyi yerel olarak çözümleyemez. Ya yüklemeden önce dizileri birden çok satıra patlatın ya da hedefi jsonb olarak tanımlayın ve iç içe değeri stringify edin:

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;

Uçtan uca JSON konuşan hatlar için CSV’yi atlayın ve COPY ... FROM ... WITH (FORMAT text)’i JSON satır girişiyle kullanın.

Gerçek dünya payload incelemeleri

İnceleme 1: e-ticaret siparişleri (müşteri + öğeler dizisi)

Tipik bir sipariş iç içe müşteri bilgilerini değişken uzunluklu bir öğeler dizisiyle birleştirir:

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

Doğru strateji dosyayı kimin okuyacağına bağlıdır. Finans SKU başına gelir hesaplamak için öğe başına bir satır ister; bu, id ve customer.name tekrarlanmış iki satır üreten patlatma stratejisidir. Operasyonlar yerine getirme panoları için sipariş başına bir satır ister; bu, dizinin sütun sayısını patlatmaması için Stringified items ile nokta notasyonudur. Aynı giriş, iki çıkış, her ikisi de tüketicileri için doğru.

Doğrudan deneyin: payload’u JSON’dan CSV’ye Dönüştürücü aracımıza yapıştırın ve Nested seçeneğinde Düzleştir ile Stringify arasında geçiş yapın. “Nested E-commerce Orders” örneği aynı şekli yükler.

İnceleme 2: GitHub Issues API (etiketler dizisi + kullanıcı nesnesi)

/repos/{owner}/{repo}/issues endpoint’i karışık bir iç içe şekil döndürür:

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

user tek faydalı alanı olan bir nesnedir; labels sınırsız uzunlukta bir karakter dizisi dizisidir. Pragmatik düzleştirme hibrittir: user üzerinde nokta notasyonu (yalnızca user.login ile ilgileniyorsunuz) ve labels’i ; ile ayrılmış tek bir hücreye satır içi-birleştirme:

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

Tek bir stratejide hem “dizileri bir hücreye birleştir” hem de “nesneleri noktalarla düzleştir” yakalayamazsınız. Dönüştürücümüz nesne-düzleştirmeyi otomatik halleder; etiketleri jq ile ön işleyin (map(.labels = (.labels | join(";")))) veya varsayılan dizi-stringify davranışını kabul edin.

İnceleme 3: MongoDB mongoexport ($oid + üst veri)

mongoexport --jsonArray Extended JSON sarmalayıcıları üretir:

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

$oid sarmalayıcısı tam olarak _id.$oid adında bir sütun üretir ve çoğu SQL motoru bunu reddeder. Sarmalamayı açmak için jq ile ön işleyin:

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

Derin iç içe metadata.preferences bloğu için tüketiciye göre seçin. Analist dışa aktarımı: her şeyi nokta-düzleştirin; metadata.preferences.theme iyi okunur. Hat gidiş-dönüşü: yapıyı sağlam tutmak için metadata’yı stringify edin. CSV hatlarıyla eşleşen tam jq desenleri için jq Hile Sayfası rehberimize bakın.

İnceleme 4: Kubernetes Pod Spec (derin iç içe)

Bir kubectl get pod -o json yanıtı düz stratejiler için en kötü durumdur. Yapı rutin olarak altı seviye derine iner (spec.template.spec.containers.0.resources.limits.memory). Saf nokta-düzleştirme 70 karakteri aşan sütun adları ve 200+ sütun çıktı üretir. İki strateji çalışır.

kubectl jsonpath ile ön-projeksiyon. Yalnızca gerçekten ihtiyacınız olan alanları seçin:

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

Spec’i stringify edin, metadata’yı düzleştirin. metadata’yı (ad, ad alanı, etiketler) düz tutun ve spec’i tek bir hücreye stringify edin:

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

Ardından dönüştürücüye Düzleştir modunda yapıştırın. spec sütunu tek bir JSON hücresi olur; metadata sütunları okunabilir kalır. Ön-projeksiyon olmaksızın kubectl get pod -o json | json-to-csv flatten anti-deseninden kaçının. Sütun sayısı kullanılamaz olacaktır.

Gidiş-dönüş güvenliği: düzleştirme kayıplı, stringify kayıpsızdır

Çoğu rehberin atladığı nokta şu. Nokta notasyonu, alt çizgi notasyonu, dizinli diziler ve satır patlatma hepsi tek yönlü projeksiyonlardır. Herhangi biriyle düzleştirdikten sonra, orijinal JSON yalnızca CSV’den mükemmel şekilde yeniden oluşturulamaz.

Karşı örnekler inşa etmek kolaydır. customer.address.city adlı bir sütun, {"customer": {"address": {"city": "..."}}} ile {"customer": {"address.city": "..."}} arasında belirsizdir. Dizinli diziler tersine çevrilebilir görünür, ancak CSV items.0.sku’nun bir diziye mi yoksa sayısal anahtarlı bir nesneye mi yeniden oluşturulacağını söyleyemez. Satır patlatma bir group-by anahtarı gerektirir; order_id olmadan hangi satırların aynı ebeveyne ait olduğunu söyleyemezsiniz.

Yalnızca Stringify gidiş-dönüşten sağ çıkar. İç içe değer bir JSON karakter dizisi olarak aynen korunur, böylece ters dönüştürücü hücreyi okur, çözümler ve orijinali sağlam olarak yeniden ekler. Stringify ile dönüştürün, CSV’yi kaydedin, CSV’den JSON’a Dönüştürücü aracımıza yapıştırın, Infer types’ı açın ve girdiyle bayt bayt aynı sonucu alın.

Pratik kural: hat gidiş-dönüşü → Stringify. Tek seferlik analiz veya raporlama → tüketiciye göre nokta, alt çizgi veya patlatma.

Tarayıcı aracımızda yapma

JSON’dan CSV’ye Dönüştürücü beş stratejinin ikisini doğrudan açığa çıkarır: Düzleştir (nokta notasyonu ve dizinli dizileri birleştirir) ve Stringify (yapıyı hücre içinde korur). Diğer üçü (alt çizgi, satır patlatma, SQL hedefli ön ayarlar) bir ön işleme adımı uzaktadır.

Tipik bir oturum beş tıklama alır:

1. Sözdizimi hatalarının sessiz dönüşüm başarısızlıklarına dönüşmemesi için girişi JSON Biçimlendirici aracımızla doğrulayın.
2. JSON’u JSON’dan CSV’ye Dönüştürücü aracına yapıştırın. Dönüşüm anında çalışır.
3. Nested’i noktalı ve dizinli anahtarlar için Düzleştir’e veya dizileri ve nesneleri tek hücrelerde tutmak için Stringify’a ayarlayın.
4. Bir ön ayar seçin: hatlar için RFC 4180, AB hesap tabloları için Excel, ambarlar için TSV, virgül ağırlıklı metin için Pipe.
5. Yön değiştir’e tıklayın ve Stringify gidiş-dönüşünü doğrulamak için Infer types açık CSV’den JSON’a Dönüştürücü aracını kullanın.

Her şey tarayıcınızda çalışır. PII, dahili dışa aktarımlar ve üretim sırları sayfayı asla terk etmez; sayfa yüklendikten sonra sıfır ağ isteği vardır. Bu, üçüncü taraf siteye yüklemenin seçenek olmadığı hassas veriler için uygun bir çözümdür.

Sık karşılaşılan tuzaklar

Altı başarısızlık modu defalarca ortaya çıkar.

1. Sütun adı patlaması. Kubernetes spec’leri ve GitHub PR inceleme dizileri yüzlerce yaprak yolu üretir. Düzeltme: jq veya kubectl jsonpath ile ön-projeksiyon yapın veya metadata’yı düzleştirirken ağır alt ağaçları stringify edin.
2. Dizi uzunluğu uyumsuzluğu. Satır 1’de 3 öğe, satır 2’de 5 öğe var. Dizinli diziler satır 1 için items.3.sku ve items.4.sku’da boş hücreler üretir. Düzeltme: satır patlatmaya geçin.
3. Tersine çevirmede karakter dizisi olarak ele alınan dizin anahtarları. CSV’den JSON’a items.0.sku gördüğünde, 0 teknik olarak bir karakter dizisi anahtarıdır. Bazı ters dönüştürücüler [{"sku": "A"}] yerine {"0": {"sku": "A"}} yeniden oluşturur. Düzeltme: gidiş-dönüşler için Stringify kullanın.
4. Zaten ayırıcıyı içeren anahtarlar. GA4 olaylarının event_params.key gibi gerçek nokta içeren anahtarları vardır; . ile düzleştirme belirsiz yollar üretir. Düzeltme: alt çizgi kullanın veya rahatsız edici anahtarları yeniden adlandırın. Genişletilmiş anahtar desteğine sahip JSON biçimleri hakkında arka plan için JSON5 ve JSONC rehberimize bakın.
5. Karışık seviyeli türler. Bazı satırlarda address bir nesnedir, diğerlerinde null. Düzleştirme nesnenin null olduğu yerlerde boş hücreler üretir. Dönüştürücümüzdeki şema notları uyarısı bunu işaretler, böylece alt katman tüketicisini doğrulayabilirsiniz.
6. Excel tarafından kesilen büyük tam sayılar. Bir $oid Long, bir Twitter snowflake ID’si veya bir K8s resourceVersion, JavaScript’in güvenli aralığını (2^53 - 1) aşar ve sessizce yuvarlanır. Excel sonra bunları 9.00719925474E+15 olarak render eder. Düzeltme: ID’leri kaynak JSON’da karakter dizisi olarak saklayın, BOM’u etkinleştirin ve Excel ön ayarını kullanın.

SSS

İç içe JSON’u CSV’ye düzleştirmenin en iyi yolu nedir?

İç içe JSON’u CSV’ye düzleştirmenin en iyi yolu alt katman tüketicisine bağlıdır. Excel veya Google Sheets için nokta notasyonu kullanın. Pandas veya BigQuery veriyi toplayacaksa satır patlatma kullanın. CSV, veri kaybı olmadan JSON’a geri dönmeli olduğunda Stringify kullanın. Stratejiyi bir sonraki okuyucuya eşleyin.

Bir JSON dizisini birden çok CSV satırına nasıl dönüştürürüm?

Bir JSON dizisini birden çok CSV satırına patlatma stratejisini kullanarak dönüştürün: ebeveyn alanları her dizi öğesi için bir kez çoğaltın, böylece her biri kendi satırı olur. Pandas’ta pd.json_normalize(data, record_path='items', meta=['order_id']) bunu tek bir çağrıda yapar. SQL’de UNNEST(items) aynı şekli üretir. Ebeveyn anahtarlar patlatılmış satırlar arasında tekrarlanır.

CSV’yi orijinal iç içe JSON’a geri döndürebilir miyim?

CSV’yi orijinal iç içe JSON’a geri döndürmek yalnızca Stringify modunda çalışır. Nokta notasyonu, alt çizgi, dizinli diziler ve satır patlatma kayıplı tek yönlü projeksiyonlardır; ters dönüştürücü ağacı mükemmel şekilde yeniden oluşturamaz. Stringify dizileri ve nesneleri tek bir hücrenin içinde JSON olarak korur, böylece Infer types açık olduğunda tam gidiş-dönüş bayt bayt aynıdır.

Excel düzleştirilmiş JSON’umu neden tek uzun bir sütun olarak gösteriyor?

Excel düzleştirilmiş JSON’unuzu, virgülün ondalık sayılar için ayrıldığı ve Excel’in sınırlayıcı olarak noktalı virgül beklediği bir Avrupa yerel ayarındaysanız (Almanya, Fransa, İtalya, İspanya) tek uzun bir sütun olarak gösterir. json-to-csv aracındaki Excel ön ayarı tek tıklamayla ; + CRLF + UTF-8 BOM’a geçer.

Sütun adları için nokta notasyonu mu yoksa alt çizgi mi kullanmalıyım?

Hedef Excel, Google Sheets veya Pandas olduğunda nokta notasyonu kullanın; noktalar json_normalize varsayılanıdır ve doğal okunur. Hedef SQL olduğunda alt çizgi kullanın: Postgres, BigQuery ve Snowflake nokta içeren tanımlayıcıların etrafında tırnak gerektirirken, alt çizgiler her yerde tırnaksız kabul edilir.

Pandas json_normalize nesne dizilerini nasıl ele alır?

Pandas json_normalize nesne dizilerini record_path ve meta argümanları aracılığıyla ele alır. pd.json_normalize(data, record_path='items', meta=['order_id']) items’i order_id tekrarlanmış olarak öğe başına bir satıra patlatır. Diziler olmadan iç içe nesneler için daha basit pd.json_normalize(data, sep='_') customer_address_city gibi alt çizgiyle ayrılmış sütun adları üretir. Derin ağaçlarda derinliği sınırlamak için max_level= kullanın.

Derin iç içe JSON’u düzleştirirken sütun limiti nedir?

Derin iç içe JSON’u düzleştirirken sütun limiti Excel’de 16.384 ve CSV’nin kendisinde fiilen sınırsızdır, ancak 500 sütunu geçtiğinde çıktı yönetilemez hale gelir. Kubernetes Pod spec’leri veya GraphQL yanıtları bunu kolayca aşar. Ağır alt ağaçları JSON’dan CSV’ye Dönüştürücü ile stringify edin veya jq veya kubectl jsonpath ile ön-projeksiyon yapın.

CSV dönüşümünden önce JSON düzleştirmek için jq iyi bir araç mı?

Evet, jq CSV dönüşümünden önce JSON düzleştirmek için doğru araçtır. Ön-projeksiyonu (map({id, name})), ön-patlatmayı (.[] | {id, item: .items[]}) ve şekil normalleştirmeyi tek satırda halleder. jq hattı CSV adımından önce çalışır ve hangi alanların dönüştürücüye ulaşacağını tam olarak kontrol eder. Desenler için jq Hile Sayfası rehberimize bakın.

Sonuç

Akılda tutulması gerekenler:

1. JSON’dan CSV’ye geçiş sözdizimi değil geometri problemidir. Bir ağaç, dalların nasıl çökeceğini seçmeden bir ızgaraya sığmaz.
2. Beş strateji pratik evreni kapsar (nokta, alt çizgi, dizinli diziler, satır patlatma, Stringify). Tüketiciye göre seçin.
3. Stringify tek kayıpsız yoldur. Hat gidiş-dönüşleri için kullanın.
4. Excel-EU ve BigQuery’nin ön ayarları bir nedenle vardır. Kullanın.
5. Gerçek payload’lar (mongoexport, Kubernetes spec’leri, GitHub yanıtları) genellikle önce bir jq veya kubectl jsonpath ön-projeksiyon adımına ihtiyaç duyar.

Kendi payload’unuzu JSON’dan CSV’ye Dönüştürücü aracında deneyin. Yerel olarak çalışır, beş stratejiyi de işler, Stringify ile kayıpsız gidiş-dönüş yapar. Yükleme yok, kayıt yok, veri sayfayı asla terk etmez.