CSVはXMLとJSONの優れた代替手段ですか？[閉まっている]

されたCSVはに対して良いオプションと考えXMLとJSONをプログラミング言語のために？

通常、フラットファイルストレージとしてXMLとJSON（またはプレーンテキストファイル）を使用します。しかし、最近、PHPの CSV実装に出会いました。ただし、Excelファイルの入力にCSVが使用されていることは一般的に見ていますが、プログラミングでは使用していません。XMLやJSONよりも優れているでしょうか？

答えは、それは依存します。

CSVは特定のユースケースに適しています。たとえば、大規模なデータセットの「ストリーミング」フォーマットとして、XML / JSONよりもストリーミングが簡単であり、CSVファイルの保存スペースははるかに少なくなります。私はこれを使用して、他の形式が実用的でないギガバイト範囲のデータセットをストリーミングします。

また、特定の業界では、レガシーシステムとワークフローを扱う際に非常に一般的です。JSONをMS Excelにインポートしてみてください。

ODIは最近、CSVについてコメントし、2014年を「 CSVの年」と呼びました

「適切な」CSV形式の場合、HTTP応答でCSV MIMEタイプを使用することを検討してください。

確かにそうではありません。

CSVは、データセットまたはその他の表形式のデータに非常によく対応するテーブル形式です。ただし、すべてのデータが表形式ではありません！最も一般的には、オブジェクトグラフをシリアル化します。これは、次の場合に困難になる可能性があります。

• 循環参照
• 共有サブグラフ（たとえば、両方が同じオブジェクトをメンバーとして含む2つのオブジェクト）
• 同じドキュメントにシリアル化される異なるタイプのオブジェクト

さらに、ストレージ形式からオブジェクトを確実にデシリアライズできるようにしたいと考えています。

XML

主に拡張可能なマークアップ言語です。一般的なデータ構造を格納するために、靴のように角張っていることもあります。IDの言語サポートにより、複雑なグラフを作成できますが、ツリーに最適です。ドキュメントは、仕様に対する正確性についてテストできます。この形式には、極端な冗長性など、実用的ではないさまざまな問題があります。

JSON

主にシンプルなオブジェクトツリーを保存する方法です。一般的なグラフはサポートされていません。JSONには、プリミティブ、string、integer、float、boolean、null、およびコレクション型の配列とオブジェクトを超える型の概念はありません。

YAML

JSONの拡張として最も簡単に理解できます。任意の複雑さのオブジェクトグラフを作成できるエイリアスの概念があります。適切な入力に使用できるタグのようなメタデータの概念があります。

CSV

単一のテーブルを除いて、何もありません。オブジェクトグラフを保存する場合は、次のようなスキーマを使用する必要があります。

#ID,Type,Field1,Field2,...,FieldN

1,String,foo
2,String,bar
3,Array<String>,1,2

区切り文字、行末記号、引用符、エスケープ文字、および一般（バイナリ）データに適さないその他の多くの問題で意見が一致しないCSVの方言が多数あります。これらはすべて、CSVデータの処理をかなり困難にします。

したがって、基本的に、CSVを一般的なシリアル化形式として使用する場合、CSVでは簡単なことは困難または不可能です。

この批判は、タイムシートや一連の測定値などの真の表形式データを保存するために使用する場合には適用されません。ここで、CSV（多くの場合、タブ区切り値のバリアント）は、他のデータ形式よりもコンパクトで使いやすいです。

また、あなたが達成しようとしているものに依存していることを言わなければなりません。多くの問題では、問題が十分に小さく、選択が既存のシステムに適合する場合、何を選択するかは重要ではありません。

レガシーシステムを使用して、新しいフォーマットで試聴しようとすると、より複雑になり、デバッグするための新しい入力システムがあるため、問題になることがあります。新しい人々が存在するものとは異なるものを好むとき、または新しいフォーマットが現れて、それを試してみたいとき、私はこれをよく見ました。これは良いアイデアかもしれませんが、状況によって異なります。

数年前、私はさまざまな形式のCSVファイルに依存する研究グラフデータベースシステムに取り組んでいました。CSVファイルインポーターはグラフを作成し、コードのデバッグと最適化のために長年の作業を行いました。高速で柔軟性があり、大規模な研究プロジェクトのブートストラップに喜んで使用していました。シーンにXMLが登場したとき、XMLインポーターを追加しましたが、速度や複雑さの表現の点で必ずしも改善されたわけではなく、確かにXMLはCSVよりグラフ構造の表現が優れていませんでした。JSONはXMLよりもはるかに優れています（そしてより簡潔です）が、多くの点で類似しているため、そのシステムで新しいインポーターを作成するときに同様の結果が期待されます。

ある時点で、顧客に「cobol」形式の大量のデータを持ち込んでもらいました。これは、その行に続くバイトの解釈方法を示すマーカーを含む可変長の行を持つファイルです。ストレージが高価であったため、コンパクトさが必要でした。そのデータをその場でCSV形式に変換し、CSVインポーターにフィードしてインポートしました。これは簡単で、デバッグとメンテナンスの量を最小限に抑えることができました。これは良いことです。この種のデータを常にインポートする必要がある場合は、パフォーマンスと効率の向上を得るためにシステムに直接組み込みます。

したがって、それはあなたが何をしているか、そして基礎となるシステムが何をしているかに依存します。私の例では、CSVインポーターはしっかりと設計されており、信頼できます。私が構築している他のレイヤーで何が起こっているのか理解せずに、1つのフォーマットが良いか悪いかを言うのをためらうでしょう。私はJSONが好きで、それを好みますが、特定の複雑なデータ構造と十分な大きさのデータセットを考えると、CSVファイルも非常にうまく機能することができます。

いや

CSVは実際には単一の形式ではありません。エスケープ、セパレーター、およびその他の書式設定の問題には、野生の多くのCSVファイルにあるさまざまなスタイルがあります。

これをフラットファイルストレージとして使用する場合は、JSONを使用するとはるかに役立ちます。JSONは、CSVを使用するよりもはるかに簡単にオブジェクトとの間でマッピングを行います。

私はそれに対して強く助言します。ある時点でCSVを出力してもかまいません（ユーザーが要求した場合）。ただし、ストレージ/インポートの目的には適していません。これは主に、「CSV」が非常に不明確であるという事実によるものです。「C」は「カンマ」または「文字」で区切られていますか？「」などのエスケープ文字を含むテキスト文字列をどのように処理しますか。すべてのひどいCSV実装は、エスケープ文字などを異なる方法で処理します。

Excelは優れたデモンストレーションです。英語版では、セパレータとして「、」を使用します。ドイツでは、「;」を使用します。そのため、ドイツ語版は英語のCSVファイルで停止し、逆もまた同様です。

主な強みは人間の可読性であり、これは軽視すべきではありません。しかし、ストレージ形式としてこれに依存することはありません。そのためには脆すぎます。人間用にファイルをエクスポートする必要がある場合は、CSVを使用することもありますが、それでもxlsxファイルに書き込むライブラリを使用しようとします（これらは自由に利用できます）。

一般的に どうして？JSONとXMLは基本的に、恐ろしいCSVを取り除くためのものです。これらは、CSVで長い間非構造化されてきたものの構造化されたアプローチです。はい、CSVがまだ好まれるいくつかのユースケースがありますが、一般的には10ケース中9ケースでCSVを使用しないほうが良いでしょう。