JSON ↔ CSV 変換
JSONをCSVに、CSVをJSONに、ブラウザ内でそのまま変換できます。オブジェクトの配列を貼り付ければスプレッドシートにすぐ使える表になり、CSVを貼り付ければ構造化されたJSONが得られます。区切り文字やヘッダー行も思いどおりに設定できます。
区切り文字
上にデータを入力すると、変換結果がここに表示されます。
JSON ↔ CSV 変換 の使い方
- 1
変換の方向を選ぶ
トグルで「JSONをCSVに」か「CSVをJSONに」を選びます。入れ替えボタンを押すと結果が入力欄に移り、逆方向に再変換できます。
- 2
データを貼り付ける
オブジェクトのJSON配列、またはCSVテキストを入力欄に貼り付けます。入力すると同時に変換が自動で実行されます。
- 3
オプションを設定する
データに合う区切り文字を選び、CSVを読み込むときは先頭行をヘッダーにするか、数値と真偽値を解析するかを決めます。
- 4
結果をコピーする
変換結果を確認してクリップボードにコピーすれば、スプレッドシートやデータベース、コードにそのまま貼り付けられます。
JSONの配列を表計算ですぐ使えるCSVに変える
中心となる対応: オブジェクトは行に、キーは列に
CSVは行と列からなる平らな2次元の格子で、一方JSONは木構造です。したがって、理にかなった変換は特定のものになります。トップレベルのオブジェクトの配列で、各オブジェクトが1つのレコードであるものです。各オブジェクトは1つのデータ行になり、すべてのオブジェクトにわたるキーの和集合がヘッダー行になります。name と role のフィールドを持つ3人分のレコードの配列を貼り付けると、name と role のヘッダー行に続いて3行が得られます。
最初のオブジェクトだけでなく、すべてのオブジェクトにわたってキーを集めることが、ふぞろいなデータを整列させ続ける鍵です。もし最初のレコードに name と email があり、2つ目が phone フィールドを加えるなら、変換器はそれでも phone 列を出力し、単に最初の行の phone のセルを空のままにします。順序は最初に現れた順に取られるので、列は予測可能で安定した並びで読めます。
なぜオブジェクトの配列が正しい入力の形なのか
単一の数値や裸の文字列の配列には自然な表の形がないので、その曖昧さを取り除くためにオブジェクトの配列という慣習が存在します。各要素は行になり、各フィールド名は列になります。単独のオブジェクトは、単に1行の場合にすぎません。このツールは単一のオブジェクトを、そのキーをヘッダーとする1行の表に包みます。しかしこの慣習が本当に輝くのはリストに対してで、それこそが、ほとんどのRESTのエンドポイントがリスト型のリソースに対して返す形です。ユーザーのエンドポイント、注文のエンドポイント、検索結果のエンドポイントなどです。だからこそ、APIのレスポンスを表計算にエクスポートすることが、人々がこの変換に手を伸ばす最もよくある理由なのです。
もし本当のデータが1段深く包まれている場合、たとえば results フィールドがあなたの欲しい配列を保持しているオブジェクトのような場合は、まずその内側の配列を取り出して、それだけで貼り付けてください。配列を直接変換器に与えることが、混乱を招く1行ではなく、きれいな表を生み出します。
入れ子のオブジェクトや配列はどう扱われるか
CSVには深さという概念がないので、それ自体がオブジェクトや配列である値は、平坦化の仕組みを考え出さない限り、より多くの列に展開できません。このツールは予測可能で可逆な道を取ります。入れ子の値は、1つのセルの中にコンパクトなJSONテキストとしてシリアライズされます。street と city を保持する address フィールドは、その小さなオブジェクトをJSON文字列として含む1つのセルになり、内部のコンマが行を壊さないように引用符で囲まれます。
これはデータをそのまま保ち往復可能にしますが、表計算で読むのは快適ではありません。レコードが本当に階層的なとき、つまり深く入れ子になった設定、木構造、配列の配列を持つ何かのときは、CSVは誤った行き先であり、JSONやYAMLの表現のほうがはるかに役立ちます。CSVは平らでレコード状のデータで輝きます。
引用とエスケープ、ひそかにファイルを壊す部分
素朴な文字列の連結が壊れたCSVを生む理由は、区切り文字がデータの中に現れうるからです。"Portland, Oregon" という city の値はコンマを含んでおり、そのまま生で書くと2つのセルに分かれ、その後のすべての列をずらしてしまいます。変換器は一般的な RFC 4180 の慣習に従います。区切り文字、二重引用符、改行のいずれかを含むフィールドはすべて二重引用符で囲まれ、値の中にすでにある二重引用符は二重にされます。
そのため、she said "hi" という単語を含む値は、周りを引用符で囲まれ内部の引用符が二重にされて出力され、埋め込まれた改行を持つ値は、その改行が新しい行を始めるのではなく1つのセルの中にとどまるように包まれます。これはまさに表計算が読み込み時に期待するエンコードであり、これが、正しく引用符で囲まれたファイルがきれいに開く一方で、自前で作ったファイルがデータを格子じゅうに散らばらせる理由です。
区切り文字を選ぶ
コンマは既定であり、CSVの C ですが、データがコンマだらけのときや、表計算のロケールがコンマを小数の区切りとして使うときには相性が悪くなります。そのため、ヨーロッパの多くがセミコロンを既定とし、アナリストはしばしばタブ文字を好みます。タブは本物のフィールドの値の中にはほとんど現れないので、引用のほとんどを回避できるからです。
区切り文字をファイルの行き先に合わせてください。同僚の表計算がすべての行を A 列に詰め込み続けるなら、いつもの原因は区切り文字の不一致です。彼らのマシンで列が正しく分かれるまで、コンマ、セミコロン、タブを切り替えてください。
JSONへの往復変換
この変換は両方向に動きます。CSVからJSONに切り替えると、ヘッダー行がキーに名前を付け、続く各行がオブジェクトになります。これは、開発者でない人が表計算を渡してきて、APIやインポートスクリプトのために構造化されたデータが必要なときに便利です。1つの注意点が往復を特徴づけます。CSVのセルは型のないテキストなので、CSVから読み戻した 42 は、型付きのパースを有効にしない限り、数値ではなく文字列の 42 です。
数値と真偽値をパースするオプションを有効にすると、戻り道でプレーンな数値テキストと true/false のテキストを本物のJSONの値に変換します。それでも、往復は本質的に損失があるものと考えてください。引用は正規化し、型の情報は経験則で再構築され、セルの中の入れ子のJSONはどれも手作業でもう一度パースしなければなりません。構造化されたデータの忠実なコピーのためには、最後までJSONのままにしてください。
これが実際のワークフローのどこに当てはまるか
日常的な用途は、エンジニアリングとビジネスの他の部門との橋渡しです。APIのリストをCSVにエクスポートして、表計算で開けるようにしたり、BIダッシュボードに取り込んだり、一括インポートのテンプレートに供給したりします。アナリストはピボットしたりグラフ化したりできる格子を手に入れ、あなたは使い捨てのエクスポートスクリプトを書かずに済みます。変換のすべてがブラウザの中で起こるので、注文履歴、ユーザーリスト、内部のメトリクスといった本番のデータでも、そのどれも第三者のサーバーに送らずにこれができます。
きれいなエクスポートのための実用的なヒント。変換する前にレコードを正規化してください。すべてのオブジェクトが同じフィールド名を使っていることを確認し、配列を包んでいるオブジェクトから取り出し、入れ子のフィールドをコードの中で平坦化すべきか、セルの中のJSONのまま残すべきかを前もって決めておきましょう。数分かけてJSONを整えれば、インポート後の後片付けが不要なCSVが得られます。
よくある質問
JSONをCSVに変換するにはどうすればよいですか?
このコンバーターはどのCSV形式を使いますか?
CSVをJSONに逆変換することもできますか?
ネストされたオブジェクトはどのように扱われますか?
入力したデータはサーバーに送信されますか?
関連ツール
こちらの便利なツールもどうぞ