第4回・CSVファイル｜CSV、XML、JSON…データフォーマットの変遷について考える

1 フォーマット解説の第二弾はおなじみCSVフォーマットです
- 1.1 CSVファイルはデータが区切られている

フォーマット解説の第二弾はおなじみCSVフォーマットです

前回(第3回)は、各フォーマットを説明していく第一弾として「フラットフォーマット」について説明しました。今回は第二弾としてCSVフォーマットについて説明します。これまでの記事と同様に、本連載で取り上げているフォーマットの一覧を再掲します。

フラットフォーマット(固定長フォーマット)
Character-Separated Valuesフォーマット(CSV,TSV,SSVなど)　←今回
XMLフォーマット
JSONフォーマット

また、これまで例題としてきたサンプルデータも再掲します。

順位	氏名	本数
1	王貞治	868
2	野村克也	657
3	門田博光	567
4	山本浩二	536
5	清原和博	525

※出展:日本プロ野球機構オフィシャルサイト・歴代最高記録本塁打【通算記録】より

CSVファイルはデータが区切られている

連載第1回でも申し上げましたが、上記サンプルデータをCSVフォーマットで表すと以下のようになります。

1,王貞治,868

2,野村克也,657

3,門田博光,567

4,山本浩二,536

5,清原和博,525

各データが区切り文字(デリミタ)で区切られています。本データにおいては、各レコード(王さん、野村さん…)のデータが改行文字で区切られており、また各項目(順位、氏名、ホームラン数)が、カンマ文字で区切られています。この「区切られている」という記述ルールがCSVの最大の特徴です。

その前にここでちょっと脱線です。みなさんに覚えておいていただきたい豆知識があります。それは「実は、これがCSVファイルである！という明確なルールは存在しない」という事です。CSVは「方言(細かなルールの違い)がある。その違いをプログラム側で把握した上で処理を行わなければいけない。」というフォーマットなのです。一例としては「文字列データを”AAA”のようにダブルクォートで囲むか否か？」というものが有名な方言です。今回はこれらの方言についてはあえて触れません。この方言について述べるとかなり長くなってしまいますので、別の連載に機会を移したいと考えています。

この方言については世界的標準策定の視点からも見て取れるものです。たとえば、今日我々は多くのコンピュータ資産とふれあいながら生活していますがそのコンピュータがやりとりをする為の多くのルールがRFC(Request for Comments)という公開形式にもとづいた仕様に則っています。いちばん身近な例としては、みなさんはインターネット上のサイトにアクセスする際「http://～」という文字列を見たことはありませんか?これはhttp(Hypertext Transfer Protocol)というインターネット上で情報をやりとりするための会話処理手順であり、これはRFC 2616という管理番号で公開されています。httpはこの中でもDRAFT STANDARDという段階にあり、これはこの技術が安定的に確立された仕様であることを意味します。これは言い換えれば、あるプログラムがhttpの処理手順を自分の機能として持つ場合、それがRFC2616の内容を満たさないものであるならば、それば「プログラムにバグがある、もしくはhttpを処理するプログラムではない。」と言えるほどの強制力のある仕様です。これに対してCSVは、RFC 4180で公開こそされていますが公開段階はINFORMATIONALです。これは標準化への成熟段階へ至らない情報提供という扱いなのです。さきほどの「文字列データをダブルクォートで囲む」という規約に関してもRFC4180内では囲んでも囲まなくてもよい(may or may not be enclosed)という表現になっています。RFC4180がINFORMATIONALにすぎない上に、RFC4180内の記述内容も「囲んでも囲まなくてもよい」という表現なのですから、この方言がいかにあいまいなものかがお分かりいただけると思います。

大脱線してしまいました。ではこんなCSVフォーマットについて前回と同様に「第2回で説明した6つの共通的な取り決め」に照らし合わせて特徴を掘り下げていきましょう。

①　データ構造

前々回、前回と私は、

1人目のデータを格納しているのはどの場所か。2人目のデータを格納しているのはどの場所か。
1人分のデータの中で、順位を格納しているのはどの部分か。同様に氏名は。ホームラン数は？それぞれどの場所に格納されているか。

これらに関する取り決めを定めている(＝持っている)のは誰でしょうか？入力データでしょうか？プログラムでしょうか？という質問をしました。

CSVの場合、この答えは「基本的にはデータとプログラムで、以下のように仕様を分担している」です。

[データが決める構造の仕様]

一人目の項目は何文字目から何文字目までか？二人目の項目は何文字目から何文字目までか？三人…
1番目の項目は何文字目から何文字目までか？2番目の項目は何文字目から何文字目までか？3番目の項目は何文字目から何文字目までか？

[プログラムが決める処理の仕様]

何番目の場所の項目は何か？(この場合の例：1番目の項目は順位、2番目の項目は氏名、3番目の項目は本塁打数)
ヘッダ行のあり・なし
その他の方言に関する処理

上記のIとIIに関しては、第三者(このデータのデータ仕様を策定した人以外)もデータを見ただけでこのデータの構造がわかります。逆に上記a.b.cの仕様については、第三者はこのファイルだけを渡されてもデータの構造に関する仕様を知ることができません。

前回と同様、例えばこのデータをAさん(Aさんのプログラム)が作って、そのデータをAさん→Bさん→Cさん→Dさんが利用していく場合、B・C・DさんはAさんから「上記a.b.cに関してはプログラムが処理するデータ仕様(ファイルレイアウト)」が提供されないと処理ができないのです。本サンプルデータのデータ仕様の例を以下に示します。

データ仕様
データ名	歴代ホームラン数の順位
ヘッダー行	なし
文字コード	Shift_JIS
項目№	項目名
1	順位
2	氏名
3	本塁打数

前回も説明させていただきましたが、上記のデータ仕様もAさん→Bさん→Cさん→Dさんとデータが手渡されていく際に上記のデータ仕様も一緒に手渡されていかなければなりません。この前回私はこの面倒くさい状態を「データの再利用性が低い」と説明しましたが、CSVフォーマットも再現性の低さをもっています。しかしここで、このCSVのデータ仕様と前回のフラットフォーマットデータ仕様を見比べてみてください。データ仕様の記述量が前回と比べて減っていることにお気づきいただけるかと思います。すなわち「面倒くささが減っている」わけです。この点において「CSVファイルは固定長フォーマットにくらべて再利用性の高いデータフォーマットである」と言えるわけです。

②　項目の最大データサイズ

このルールを持っているのはデータです。項目データは「カンマとカンマの間のデータ」というルールなので、項目の長さをプログラムで決める必要がないのです。フラットフォーマットのようにまた「一度決定した項目の最大データサイズを後から変更する場合、それまでに作成したプログラムを修正しなければならない。」ということはありません。また「データの長さが項目長に満たなかった場合、右側をスペースで埋める」という必要もありません。

この観点において、「CSVフォーマットは自由度の高いデータフォーマットである」と言えるわけです。

③　レコードの最大データサイズ

この取り決めに関してはフラットフォーマットと同様に取り決めを定めているのはデータになります。本サンプルは歴代1位の王さんから歴代5位清原さんまで掲載していますが、このデータに6位のかたが加わったとしても、プログラムの処理に変更はありません(しつこいようですが6位は落合さん)。データレコードの最大データサイズ(レコードの件数)はに関しては、「固定長フォーマットは再利用性・自由度ともに高いデータフォーマットである」と言えます。

④　文字コード

この取り決めを定めているのはプログラムです。この文字コードにする取り決めはフラットフォーマットと完全に同じです。データの中に構造を定める要素はなにもありません。このホームラン順位のデータを処理するプログラムだけが(もしくはそのプログラムの作成に関わった人だけが)このデータの文字コードを知っている事になります。それ以外の第三者は、このファイルを渡されてもデータがどのように格納されているかを知ることができません。したがって文字コードに関してはデータの再利用性に関しても高いとはいえません。

⑤　エスケープ文字

このエスケープ文字に関する取り決めは、さきほど脱線した「CSVの方言」に関連して少々複雑です。まず取り決めを定めているのはデータです。しかし方言の解釈はプログラムで処理しなければならないのでプログラム側での取り決めも存在します。プログラム側での取り決めが軽微であるという意味で「CSVフォーマットは再利用性・自由度ともに高いデータフォーマットである」ということができます。ここでCSVファイルを扱う上で、このエスケープ文字の処理の取り決めは注意を要するので少し触れておきます。まず代表的な事例が「CSVデータの中でカンマ文字や改行文字を表現したい場合どうするのか？」ということです。これに関してもっとも簡単な解決方法は「データの中にそれらの文字が入らないような制限を処理仕様として定める」事です。この場合エスケープ文字については考慮の必要がなくなるので、処理は単純になります。実際この解決方法を採っているシステムも数多く存在します。対してこのような制限を仕様として許容できない場合、

項目データをダブルクォートで囲む
ダブルクォートで囲まれた文字列が一つの項目データなので、この中にはカンマ文字や改行文字を記述できる。
すると、「じゃあ、そのデータの中でダブルクォート文字が入っていたらどうなるんだ？」という問題が浮き上がる。
ここでエスケープ文字の登場！ダブルクォート文字1つ「”」をダブルクォート文字2つ「””」でエスケープする。

という処理の仕様になります。このようなCSVをよく「Excelで使うCSV」という言い方をします。ちなみにダブルクォート文字2つ「””」の文字列をエスケープするにはダブルクォート文字4つ「””””」という取り決めになります。ただ、このようなCSVはテキストエディタなどでデータを参照した場合の読みやすさや、データを人間が手動で編集した場合間違えてデータを壊しやすいなどの短所を持っています。

⑥　処理速度

前回も申し上げましたが、CSVファイルの処理速度は固定長フォーマットに劣ります。CSVファイルは改行文字(CR,LF)をデータ1レコード分の区切り文字としたルールを持っていますが、これを処理するプログラムはCSVファイルのデータ1バイトずつを順番に見ていってそれが改行文字であるかを判断しているためです。しかしながらXMLやJSONなどのフォーマットと比べると遥かに高速にデータを処理することが可能です。XMLやJSONのほうが記述ルールおよびファイル構造が複雑である事がその理由なのですが、どのように複雑であるかは次回以降に説明をします。

以上、各フォーマット説明の第二弾としてCSVフォーマットについて説明しました。ここで多少の私見をまじえて今回のまとめを述べます。

CSVフォーマットはフラットフォーマットの自由度の低さを補うために考え出されたということが言えます。特にフラットフォーマットの宿命である「項目データの長さに制限がある」「項目データの長さに変更があった場合、影響範囲が大きい」という制限は、一つのデータファイルが単独で複数の人の手やプログラムを渡り歩く現在のシステムにとってはあまりにも不親切なフォーマットであると言わざるをえません。CSVフォーマットはデータの構造や項目データサイズにおいてより高い再利用性や自由度を獲得しています。しかし代替として「文字のエスケープ」というデータ処理において注意が必要な「面倒くささ」を押しつけられました。このようにデータフォーマットの変遷は「たくさんの便利な事」と「ちょっとの面倒くささ」を交換しながら変遷していくものだと私は思っています。次回以降もこの交換ストーリーを書いていきたいと考えています。また実はここまでの記事では私的にはまだCSVについての特徴を述べきっていません。このまとめの続きは残りのXML、JSONについての説明が終わった後に本連載4フォーマットの全体をまとめる記事で述べさせてください。

次回フォーマット説明の第三弾は、XMLファイルについての説明をさせていただきます。

本連載について

第4回・CSVファイル｜CSV、XML、JSON…データフォーマットの変遷について考える