Comma-Separated Values
 |
| 拡張子 | .csv |
|---|---|
| MIMEタイプ | text/csv |
| タイプコード | 'TEXT' |
| 国際標準 | RFC 4180 |
comma-separated values（略称：CSV）は、テキストデータをいくつかのフィールド（項目）に分け、区切り文字であるカンマ「,」で区切ったデータ形式。拡張子は .csv、MIMEタイプは text/csv。
「comma-separated variables」とも言う。日本語では広く普及した訳語はないが、「カンマ区切り」「コンマ区切り」などとも呼ばれる。Microsoft Excelの日本語版では「CSV (カンマ区切り)」としている。
概要
データ交換用のデファクトスタンダードとして、古くから多くの表計算ソフトやデータベースソフトで使われている。CSV形式の細部の実装はソフトウェアによって異なるため（例えば項目を単一引用符「'」や二重引用符「"」で括ったり、ファイルの一行目をヘッダとして予約したりなど）、他のソフトウェアで表（テーブル）として読み込む際に互換性で問題が出る場合があるものの、CSVの実質はプレーンテキストであり、CSVファイル（カンマ区切りファイル）の実質はテキストファイルであるため、出力プログラムの記述が極めて容易であり、プログラミング言語を問わない点や、汎用的なテキストエディタでも読み書きできる点が、互換性の面で大きな利点となっている。また、新しいレコードの追記が単純な末尾追加だけで済むため、ソフトウェアの簡易的なログに使用されることもある。
類似したフォーマットとして、タブで区切られた tab-separated values (TSV) や、欧文間隔 (いわゆる半角スペース) で区切られた space-separated values (SSV) などがあり、これらをまとめて character-separated values (CSV)[1] や delimiter-separated values (DSV) などと呼ぶことも多い。実際に、カンマ以外の文字で区切ったデータを「CSVファイル」として保存するソフトウェアもある。例えばフランス・ドイツ・イタリアなどのヨーロッパ諸国では、区切り文字にカンマではなくセミコロン（;）を使う慣習がある。これは小数点記号にピリオドではなくカンマを用いる文化であることも関与している。
2005年10月、それまでの各ソフトウェアにおけるCSVの実装を追認する形で、RFC 4180 で Informational（IESGの外部で決定された有用な情報の提供）として仕様が成文化された。しかし実際のソフトウェア側の実装はRFCに準拠していないことが多い。
仕様
RFC 4180に述べられた仕様について述べる。
ファイルは1つ以上のレコードからなる。レコードは改行（
レコードは1つ以上の同じ個数のフィールドからなる。フィールドはコンマ「,」(U+002C) で区切られる。最後のフィールドの後にはコンマは付けない。
日本国, 東京都, 127767944␍ ␊ アメリカ合衆国, ワシントン特別区, 300007997␍ ␊
なお、最後のフィールドの後にはコンマはないので、もしレコードがコンマで終わっているように見えれば、実際はその後に空文字列（長さ0の文字列）からなるフィールドがある。次のレコードは、「日本国」「東京都」「」（長さ0の文字列）の3つのフィールドからなる。
日本国, 東京都, ␍ ␊
ファイルの先頭には、オプションとして、通常のレコードと同一の書式の「ヘッダ行」があってもいい。ヘッダ行は、他のレコードと同じ個数のフィールドを持ち、フィールドの名称が書かれている。
国, 政治的な中心がある地域, 人口(2006)␍ ␊ 日本国, 東京都, 127767944␍ ␊ アメリカ合衆国, ワシントン特別区, 300007997␍ ␊
フィールドは、ダブルクォート「"」(U+0022) で囲んでも囲まなくてもよい。次の3つのレコードは、（CSVの文字列としては）同じ内容である。（ただし、RFCはフィールドの解釈までは規定していない。一部のソフトウェアはダブルクォートで囲まれているかどうかで解釈を変える）
日本国, 東京都, 127767944␍ ␊ " 日本国" , " 東京都" , " 127767944" ␍ ␊ " 日本国" , " 東京都" , 127767944␍ ␊
フィールドがコンマ、ダブルクォート、改行を含む場合は、かならずダブルクォートで囲む。また、フィールドに含まれるダブルクォートは2つ並べてエスケープする。次のレコードの内容は、「日本」「127,767,944」である。なお、ここでいう「コンマ」「ダブルクォート」はU+002CとU+0022のことで、他のもの（たとえば全角コンマ）は関係ない。
" 日本␍ ␊ 国" , " " " 東京都" " " , " 127, 767, 944" ␍ ␊
背景
コンピュータ内部において、データベース内のテーブルや表計算ソフトの表の内容は、それぞれのソフトウェアが処理可能な独自のファイルフォーマットで保存されていることがあり、そのような場合は別のソフトウェアへデータを移そうにも基本的には互換性はないため読み込むことはできない。
カンマ区切りテキストは、テキスト形式で保存されるので、テキストエディタでも閲覧や編集ができる。さらに、使用するソフトウェアが、カンマ区切りテキストの出力 (エクスポート) と、読み込みから表への生成 (インポート) に対応していれば、別製品のデータベースソフトや表計算ソフトからのデータ交換が可能となる。
しかし、「テキスト形式」や「日付形式」といった各項目に設定している属性は出力されないので、インポートする側のソフトウエアがインポートする際に設定しなくてはいけない。
Microsoft Excelに代表されるパソコンの表計算ソフトが流行して以降、非常によく利用されるようになった。大型コンピュータとのデータのやりとりでは固定長データフォーマットがよく利用される。現在では、XMLを使おうという動きもあるが、XMLの仕様は膨大であり、読み書き処理のオーバーヘッドが大きく、主流にはなっていない。
問題点と回避策
フィールドにコンマやダブルクォートが含まれている場合、エスケープされている場合でも、ソフトウェアによって解釈が異なり、区切り方が変わることがある。その結果、データが破壊されることや、データ修正の手間が生じることがある。
フィールドにコンマやダブルクォートが含まれていることは頻繁にありうるが、フィールドにタブのような制御文字が含まれていることは少ない。従って、区切り文字にコンマを使うCSV形式の代わりに、区切り文字にタブを使うTSV形式を使うことで問題を避けられることがある。
XMLのようにエンコード方式（文字セット）を指定・宣言する仕様が規定されていないため、エンコードは決め打ちまたはバイト順マークなどを利用した推定に頼ることになる。
実装
|
CSVの実装には、各方言独自の拡張や制約がある。ただし、歴史的に見れば、これらの実装のほうがRFC 4180以前から存在している。
- レコード区切り文字列
- CR LF を区切り文字列として扱わない処理系がある。
- フィールド区切り文字
- 全角コンマ「，」を区切りとみなす処理系がある。
- ダブルクォート文字の表現
- ダブルクォート文字を表現する方法として「ダブルクォートを重ねる」処理系と、「バックスラッシュを前につける」処理系が存在する。
- ダブルクォート文字の有無
- 多くのソフトウェアは、必要なときのみフィールドをダブルクォートで囲む。ただし、そうでないファイルも読み取れる。
- フィールド数
- 読み取りファイルのフィールド数が一定でない場合、ほとんどのソフトウェアは、空文字列（長さ0の文字列）からなるフィールドを適宜追加して数をそろえる。
- 空行、フィールド数が0個のレコード
- 空行を全てのフィールドが空文字列であるとして処理する処理系と、空行を無視する処理系がある。
- 注釈
- 特定の書式の文字列を注釈行として扱う処理系がある。
character-separated values
コンマの代わりに別の文字を区切りに使ったフォーマットもあり、まとめて character-separated values、delimiter-separated values と呼ぶ。
代表的なものに以下のようなものがある。
- タブ - tab-separated values (TSV) - MIME type は
text/tab-separated-values - スペース - space-separated values (SSV)
- セミコロン - semicolon-separated values (SSV)
脚注
関連項目
外部リンク
- RFC4180 - Common Format and MIME Type for Comma-Separated Values (CSV) Files
- RFC4180・日本語訳
 | この項目は、コンピュータに関連した書きかけの項目です。この項目を加筆・訂正などしてくださる協力者を求めています（PJ:コンピュータ/P:コンピュータ）。 |