CSV ↔ JSON コンバーター

CSV と JSON を双方向に変換。RFC 4180 準拠で引用符・改行を含むフィールドにも対応。区切り文字とヘッダー行のオプションを切替可能。

Loading…

すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。

使い方

方向(CSV → JSON または JSON → CSV)を選び、左側にデータを貼り付けると、右側に変換結果が表示されます。区切り文字はカンマ・タブ・セミコロン・パイプから選べます。セミコロンは欧州の Excel エクスポート、タブはスプレッドシートのコピー&ペースト、パイプは旧型メインフレームのダンプで使われます。Has-header チェックボックスは、最初の行が列名かどうかをパーサに伝えます。ヘッダなしのデータでは外してください。CSV → JSON にはさらに「As objects」トグルがあります。オンなら `[{"col": "val"}]` を、オフなら `[["val", ...]]`(生の行マトリックス)を出力します。

好みのフォーマットが違うツール間でデータを往復させるときに使ってください。DB クエリ結果を CSV で書き出したものの API 呼び出しに JSON が必要、共有された表計算シートをスクリプトに渡したい、JSON のログダンプを Excel 用に整形したい、といった場面です。パーサは RFC 4180 を素直に実装しているため、引用符付きフィールドにはカンマ、二重引用符のエスケープ、さらには改行を含めることができます。処理はすべてブラウザ内で完結し、顧客リストや社内データもマシン外には出ません。

引用符内にカンマを含む CSV → JSON

入力
name,age,city
Alice,30,Seoul
Bob,25,"Tokyo, Shibuya"
Carol,35,New York
出力
[
  { "name": "Alice", "age": "30", "city": "Seoul" },
  { "name": "Bob", "age": "25", "city": "Tokyo, Shibuya" },
  { "name": "Carol", "age": "35", "city": "New York" }
]

`"Tokyo, Shibuya"` 内のカンマは引用符付きフィールドのため保持されます。`age` は `"30"`(文字列)になっている点に注意してください。CSV には型システムがないため、JSON 出力ではすべてのセルが文字列です。数値が必要な場合は、各セルを `JSON.parse` で後処理するか、結果を型付け工程に通してください。

オブジェクト配列の JSON → CSV(キー和集合)

入力
[
  {"name":"Alice","age":30,"city":"Seoul"},
  {"name":"Bob","age":25,"country":"JP"},
  {"name":"Carol","city":"NYC","country":"US"}
]
出力
name,age,city,country
Alice,30,Seoul,
Bob,25,,JP
Carol,,NYC,US

ヘッダは全行から見たキーの和集合で、最初に登場した順に並びます。1 行目から `name`・`age`・`city`、2 行目で `country` が登場したらそこで末尾に追加されます。値が欠落しているセルは空になります。行ごとに形が揃わない JSON(よくある API エクスポートのパターン)で重要な挙動です。

改行を含むセル(RFC 4180)

入力
id,note
1,"Line one
Line two"
2,"Single line"
出力
[
  { "id": "1", "note": "Line one\nLine two" },
  { "id": "2", "note": "Single line" }
]

ダブルクォート内の改行はセルの一部であり、行区切りではありません — RFC 4180 §2.6 が定義しています。多くの表計算ソフトはセルに複数行のテキストが含まれるときにこの形式で出力します。手書きの CSV パーサは `\n` をすべて行区切りとみなしてデータを静かに壊しがちですが、本ツールの RFC 4180 パーサは構造を保ったまま処理します。

よくある質問

CSV の数値が JSON で文字列になってしまうのはなぜですか?

CSV は型を持ちません。各セルは区切り文字の間にあるバイト列であり、数値・真偽値・null の区別がありません。パース時の自動型付けはヒューリスティクスが正当な文字列を誤分類するため危険です。`"01234"` は米国の郵便番号で、数値とみなすと先頭の 0 が消えます。`"NaN"` は国略号で、特殊値になってしまいます。`"007"` はユーザー名で、数値の 7 になってしまいます。本コンバータは静かな破損を避けるためすべてを文字列のままにします。消費側のコードで明示的にキャストしてください。

なぜ Excel は UTF-8 CSV を壊しますか?

Windows 版 Excel は CSV をシステムコードページ(通常は Windows-1252 や Shift_JIS)として読み込みます。BOM(`EF BB BF`)で始まらない UTF-8 ファイルは、日本語や韓国語が文字化けします。回避策は 3 つあります。BOM 付きで保存する、Data → From Text / CSV から開いて文字コードを指定する、ファイル名を `.txt` に変えて取り込みウィザードを通す、です。Mac 版 Excel は 2016 年以降 UTF-8 を直接扱えます。本コンバータは既定で BOM なしの UTF-8 を出力します。Excel が消費側ならコピー後に BOM を先頭に付け足してください。

CSV にカンマではなくセミコロンが使われているのはなぜですか?

欧州ロケール(ドイツ語・フランス語・イタリア語・スペイン語など)は小数点にカンマを使うため、表計算ソフトは `1,5` のような数値との衝突を避けてセミコロンで区切ります。区切り文字を `;` に切り替えれば同じように扱われます。タブもよく使われます。Excel や Google Sheets からコピー&ペーストすると、メニューが "CSV" でもタブ区切りのデータになることがよくあります。Excel の CSV エクスポートは、地域設定の「リスト区切り文字」に従います。

JSON → CSV でネストされたオブジェクトはどうなりますか?

CSV はフラットで、すべてのセルは文字列です。ネストされたオブジェクトや配列は、セル内で JSON にシリアライズされます。例えば `{"a": 1}` はその列に `{"a":1}` というリテラルテキストとして入ります。往復は成立しますが、表計算ユーザーが期待する形ではありません。ネストデータを実際の列に展開する必要がある場合は、`jq 'paths(scalars)'` や `flat` のようなライブラリで JSON を先にフラット化(例: `address.city` を `address_city` 列にする)してください。

CSV → JSON で、行を配列として取得することはできますか?

はい。「As objects」のチェックを外してください。出力は `[[ "Alice", "30", "Seoul" ], ...]` という文字列のマトリックスになり、元の列順を保持し、ヘッダ名を必要としません。下流コードがキーではなく位置(`row[0]`・`row[1]`)で処理する場合や、ヘッダ行が一切ない CSV の場合に向きます。

行数の制限はありますか?

厳密な上限はありませんが、パースはブラウザ内で同期的に行われます。数十万行を超えるファイルでは変換中にページが一時的に応答しなくなります。それより大きいデータセットには `xsv`・`miller` のような CLI ツールや `pandas.read_csv` のスクリプトを使ってください。それらはストリーミング処理と適切なメモリレイアウトを提供します。100 万行の CSV はブラウザ専用ツールの設計範囲を完全に超えています。

関連する概念

CSV(Comma-Separated Values)は今も大量に使われている最古のデータフォーマットの 1 つで、1970 年代に非公式に標準化が始まり、2005 年に RFC 4180 として正式化されました。仕様は短いです。行は改行区切り、フィールドはカンマ区切り、フィールド内のカンマ・改行・引用符はダブルクォートで囲んで内側の `"` は `""` でエスケープします。「Comma」と名乗っていても、実環境の CSV ファイルは生成側ロケールが自然と感じる区切り文字を使います。欧州の多くではセミコロン、表計算のコピー&ペーストではタブ、旧型メインフレームの出力ではパイプといった具合で、相互運用を壊す細かい挙動が無数にあります。

意味論上の最大の差は **型** です。CSV には数値・真偽値・null の概念がなく、すべてのセルがバイトです。`0123` は文字列のコードかもしれないし整数の一部かもしれません。`true` は文字列かもしれないし真偽値かもしれません。消費側ごとに推測が異なります。Excel は積極的に自動型付けして静かにデータを壊し、Python の `pandas` は列ごとに dtype を推定し、本コンバータはすべてを文字列のまま保ちます。JSON は逆の性質を持ち、すべての値が明示的な型を持ちます。JSON → CSV では型情報が捨てられ、CSV → JSON では推測するか型付け問題を消費側に押し付けるかの選択になります。

隣接する 3 フォーマットがスペクトラム上の異なる位置を占めます。**TSV(Tab-Separated Values)** は固定された区切り文字の CSV で、表計算のコピー&ペーストの事実上の形式です。実テキストにタブはほとんど出てこないため、引用問題が少なくなります。**JSON Lines(NDJSON)** は 1 行に 1 つの JSON オブジェクトを書く形式で、JSON の型付けと CSV のストリーミング可能な行指向構造を組み合わせます。ログ転送、機械学習データセット、`jq -c` 出力で人気です。**Parquet** は本当の大規模(数百万行以上)向けの列指向バイナリ形式で、型を保持し、スキーマ進化をサポートし、ストレージと読み込み速度で CSV を 10 倍以上引き離します。CSV が今も生き延びているのは普遍的な互換性のためであり、フォーマット自体の優劣ではありません。

関連記事

関連ツール