JSONからCSVへ

JSONは任意にネストされたツリー形式のデータを表現するために構築されています — オブジェクトの中のオブジェクト、オブジェクトの中の配列、まったく異なる型の値が並んでいることなどです。一方CSVは平坦で均一なテーブルしか表現できません: 行と列、各行が同じ列セットを持ち、各セルが単一の平坦な値です。前者から後者に変換するということは、自然に行と列に収まらないものをどう平坦化するかについて必然的に決断を下すことを意味し、この種の変換の実際の複雑さの大部分はまさにそこにあります — JSON構文自体を読むことにではなく（それは直接的です）、そもそもテーブル形式ではなかったデータにとってスプレッドシートの行が何を意味すべきかを決めることにです。

`{"user": {"name": "Ada", "id": 42}}`のようなネストされたオブジェクトには、平坦なテーブルの中で変換すべき単一の明白な列がないため、`user.name`と`user.id`という2つの別々の列に平坦化され、ドット表記が元の構造の中で各値がどこから来たかを正確に保持します。これは特に可逆であるために広く認識された慣習です: `user.name`という名前の列は、ネストされた構造への経路を曖昧さなく記述しており、そのCSVが後でJSONに戻す必要がある、あるいはドット区切りの経路をネストされたフィールドとして理解するシステムにインポートされる必要がある場合に重要です。

ネストされた配列は異なる方法で、意図的に処理されます: 配列を追加の行に展開する — レコード内にネストされた要素がいくつあるかによってテーブルの行数が変わってしまう、本当に驚くべき、しばしば望まれない副作用 — 代わりに、配列の値は単一セルの中にJSONテキストとしてシリアライズされます。行数は予測可能なままで、入力レコードの数と正確に一致します。これはほぼ常に、スプレッドシートに変換する誰かが本当に望むものです。代償として、そのセルの内容が個別に必要な場合はさらに解析が必要になります。

実際のAPIレスポンスや手作りのJSONは、すべてのオブジェクトが同一のキーを持つわけではないレコードを頻繁に含みます — 一部のレコードにだけ存在するオプションフィールド、あるいは時間とともに進化したスキーマにより古いレコードと新しいレコードがわずかに異なる場合などです。CSVはその変動を直接表現できません。各行が同じ固定の列セットに揃う必要があるためです。CSVファイルを読むプログラムには、各行に明示的にそのセルがない限り、ある行に列が「欠けている」ことを知る方法がありません。解決策は、各レコードで見つかったすべてのキーの和集合を、各キーが最初に見つかった順序で計算し、特定のフィールドが欠けているどのレコードにも空のセルを埋めることです — そうすることで、どのレコードの列も黙って破棄したり、値を間違った列にずらしたりすることなく、ファイル全体で形が一貫したままになります。