データ形式・構造化データ
JSONをCSVにして表で確認したい
使うツール
変換ボタンを押してファイルができると、『中身はそのままで形式だけ変わった』と考えがちです。しかし、表形式と階層構造、文字列と数値、値とコメントでは、持てる情報が違います。エラーなく変換できたことは、元の意味がすべて残ったことを保証しません。変換先を選ぶ前に、何を残したいのかを決めましょう。
このガイドでは、JSONとCSVの小さな往復を中心に、YAMLのコメントとTOMLのnullも確認します。実際の業務データを丸ごと試す前に、先頭ゼロ、空文字、欠落、ネストを含む数行の例で確かめると、変換条件を説明しやすくなります。
001を残せても、数値の型まで戻るとは限らない
[{"id":"001","quantity":2,"active":true}]CSVへ変換するとid、quantity、activeの列ができます。そのCSVをもう一度JSONへ変換すると、セルの値は文字列として戻ります。idの001は守られますが、quantityの2やactiveのtrueも文字列です。このツールは見た目だけで型を推測していないため、元のJSONと型まで一致する往復ではありません。
[{"id":"001","quantity":"2","active":"true"}]逆に、数値らしいセルをすべて自動変換すれば、IDの001が1になって困る場合があります。型を復元するには、列ごとの約束が必要です。idは文字列、quantityは整数、activeは特定の表記だけを真偽値とする、といった契約を受け取り側と合わせます。CSVだけから元の型を必ず復元できるとは考えないでください。
null、空文字、項目なしが、同じ空欄になる
[
{"id":"a","note":null},
{"id":"b","note":""},
{"id":"c"}
]この例をCSVへ出すと、note列はどの行も空欄になります。JSONへ戻しても、どれがnullでどれが欠落だったかは分かりません。元の三状態を区別したいなら、状態を表す別列などの明示的な受け渡し方法が必要です。空欄を全部nullへ置き換えるだけでは、元の空文字と項目なしも別の意味に変えてしまいます。
データベースの更新では、項目がないことを『変更しない』、nullを『値を消す』と扱う設計もあります。元の仕様がそうなら、この違いを失う変換は重大です。使っているAPIや取り込み処理が実際にどう解釈するかを確認し、CSV化してよい項目を選びます。便利さのために三つの状態を同じにする判断を、変換ボタンへ任せないでください。
入れ子を一つのセルへ入れるか、列へ広げるか
[{"id":"a","profile":{"city":"Tokyo"}}]初期のネスト拒否では、この入力はCSVにできないと通知されます。文字列化を選ぶと、profileの中身をJSON文字列として一つのセルへ入れます。フラット化を選ぶとprofile.cityのような列へ展開します。いずれも入れ子の構造をそのまま表の型として保つものではなく、表へ載せるための別表現です。
CSVからJSONへ戻しても、文字列化したセルを再びオブジェクトへ解析したり、profile.cityを自動でprofile配下へ組み直したりはしません。元々ドットを含むキーとの区別も、別途規則がなければ曖昧です。どちらの方式を使うかは、受け取り側がどの形を期待するかで決めます。往復できそうな見た目だけを理由に選ばないようにします。
カンマと改行は、セルの中にも入る
id,note
001,"red, blue"
002,"first line
second line"このCSVはヘッダーを除いて二件のレコードです。カンマや改行で単純に文字列を分割すると、noteの中身まで列や行として切ってしまいます。CSV確認・編集の表プレビューで、red, blueが一つのセル、first lineとsecond lineが一つのセルとして読めることを確かめます。見た目の行数とレコード数は同じとは限りません。
表計算向けの式注入対策を使う場合は、対象セルへ先頭のアポストロフィを加えるため、文字列自体が変わります。安全に表示する目的の出力と、元の値を完全に保持する交換データを区別します。保護を選んだかどうかを受け取り側へ伝えずに渡すと、先頭記号をデータの一部として取り込む可能性があります。
YAMLのコメントは、JSONの値にはならない
# Retry only temporary failures
retries: 3
enabled: trueJSONへ変換するとretriesとenabledの値は残りますが、コメントの説明は残りません。JSONへ戻せることだけを基準に設定ファイルを往復させると、運用上大切な理由や注意書きが消える場合があります。コメントも管理対象なら、元のYAMLを正本として保持するなど、値の変換とは別の方針が必要です。
変換できないと止まる方が、正しい場合もある
JSONのnullには、TOMLでそのまま対応する値がありません。このツールはnullを含むJSONからTOMLへの変換を拒否します。空文字へ置き換えたり項目を削ったりすれば出力は作れるかもしれませんが、それは意味を変える判断です。失敗を回避するためだけに、自動で別の値へ置き換えないことが重要です。
大きな整数や日時も、変換先の型と実装の対応範囲を確認する必要があります。現在のJSON→TOML変換は、正確に扱える範囲を超える整数を拒否します。日時の型を持つ形式からJSONへ移す場合は、文字列になった後も時刻・タイムゾーンの意味が伝わるかを確認します。形式の名称だけで完全な相互変換を約束しないでください。
往復テストは、違いを見つけるために使う
最後に元のJSONと戻したJSONを構造比較します。キーの並びではなく、型、null、欠落、ネストがどう変わったかを読みます。一致しないこと自体が失敗とは限りません。目的の受け渡しで許容する変換なら、変わる内容を仕様として残せます。許容できない違いなら、別の形式や補助情報を選ぶ判断ができます。
列選択、ネストの方式、式注入対策、文字コードなどの設定も一緒に記録します。結果だけを渡して『JSONから変換したから同じ』と説明するより、どの情報を保持し、どれを変えたかを示す方が安全です。変換は終点ではなく、次の処理が同じ意味で読めるかを確かめる受け渡しの一工程です。
変換前に、受け取り側と空欄の意味を決める
CSVを受け取る側が空欄を『変更しない』と扱い、送る側が『値を削除する』つもりで出していたら、文字化けも構文エラーもなく処理が食い違います。型やnullを持たない表形式へ移す前に、空文字、値なし、未指定をどう区別するかを決める必要があります。列を追加して状態を明示する、別の形式を選ぶなどの設計は、変換の後ではなく受け渡しの条件として考えます。ツールがファイルを作れたことと、受け手が同じ意味で読めることは別の確認です。