データ構造に合わせて形式を選ぶ
JSON は配列、オブジェクト、文字列、数値、真偽値、null を明示的に表します。プログラムが読む入れ子構造の API データや設定の受け渡しに向いています。CSV は表形式で、各レコードのフィールドが共通の列順に並びます。単純な行や表計算ソフトへの取り込みには便利ですが、CSV のセルだけでは 0012 が識別子、数値、文字列のどれかは分かりません。YAML はマッピング、配列、読みやすいインデントを使えるため、人が編集する設定ファイルによく選ばれますが、解析規則には注意が必要です。JSON Lines は1行に完全な JSON 値を1つ格納し、レコードの追加や個別処理を容易にします。なじみのある拡張子ではなく、受け手のソフトウェアが期待するデータ構造を選んでください。
同じレコードを四つの形式で表す
JSON 配列 [{"id":1,"city":"Paris"},{"id":2,"city":"Lima"}] を考えます。単純に CSV に書き出すと、見出し id,city の後に 1,Paris と 2,Lima の行が続きます。YAML では id と city を持つ2つのマッピングの配列として表せます。JSON Lines では、1行目が {"id":1,"city":"Paris"}、2行目が {"id":2,"city":"Lima"} となり、外側の配列はありません。リンク先の変換ツールでこれらの表現を直接確認できます。都市名にカンマ、引用符、改行が含まれる場合を考えてみてください。そのとき CSV には、読み手が想定する方言に従った引用とエスケープが必要です。この短い例にはその複雑さが現れないので、大きなデータセットを書き出す前に実際にあり得る値で試しましょう。
- JSON：型を持つオブジェクトの配列
- CSV：見出しと平坦な行／YAML：インデント付きのマッピング
- JSON Lines：一行に一つの JSON オブジェクト
型と入れ子構造が変わらないか確認する
JSON のオブジェクトには、別のオブジェクトや配列を含められます。通常の平坦な CSV の行では、別列に分ける、セル内に JSON として記録する、複数の表に分けるなど、対応方法を決めなければその構造を表せません。変換ツールは何らかの方針を選ぶため、情報が失われていないと決めつけずに出力を確認してください。数値や真偽値は CSV ではセルの文字列になり、読み戻す際には型の明示的な変換が必要な場合があります。口座番号などの先頭のゼロは、表計算ソフトが数値として扱いたがっても重要です。YAML は JSON とおおむね同じデータモデルを表せますが、別のパーサーが読む場合は引用符なしの値とインデントを確認しましょう。JSON Lines は各レコード内で JSON の型を保ちますが、物理的な各行には有効な JSON 値を1つだけ入れる必要があります。
代表的なレコードで往復変換を試す
ファイル全体を変換する前に、通常の行、空欄、引用符で囲まれたフィールド、カンマ、ASCII 以外の文字、そしてデータに存在するなら入れ子の値を含む試料を作ります。変換後、逆変換ツールがあれば戻してみてください。見た目のテキストだけでなく、構造と型を比較します。列名、レコード数、順序、null と空文字列の違いを確かめましょう。JSON Lines では各レコードが改行で区切られていること、整形されて複数行になった1つのオブジェクトを複数レコードと取り違えていないことを確認します。下の JSON→CSV 変換ツールには、まず単純な2レコードが入っています。値を変えて出力を観察し、YAML と行区切り形式はほかのリンク先ツールで試してください。
取り込み先の要件と安全性を確認する
同じ列を持つ平坦なレコードの表なら、CSV が実用的な場合が多いでしょう。取り込み側が期待する区切り文字、文字コード、列の型を記録しておきます。信頼できない相手からの値を含む場合、表計算ソフトは数式記号で始まるセルを数式として解釈することがあるため、表計算ソフト向けの書き出しには別途安全対策の方針が必要です。人が維持する設定には YAML が読みやすい場合がありますが、実際の対象パーサーで結果を検証してください。API や構造化文書には通常 JSON のほうが型と入れ子を明確に示せます。イベントを1件ずつ処理するログやデータパイプラインでは、巨大な配列を一度に読み込まずに済む JSON Lines が役立ちます。構文上の変換成功は最初の確認にすぎず、受け手のプログラムがどう解釈するかが決め手です。