日本語

データとスプレッドシート · CSV クリーナー

CSV 対 JSON: 2 つのデータ形式とその背後にある構造に関するアイデア

· 背景

csv json データ形式

ネストされた分岐が直接収まらない分岐 JSON オブジェクトの横にあるフラットな行と列のグリッド
オリジナル ToolAcre ベクトル イラスト

CSV はテーブルを説明します。 JSON はツリーを説明します。この投稿では、JSON がどこから来たのか、CSV ができない型とネストを運ぶ理由、および 2 つの間でデータが移動するたびに不一致が何を意味するのかについて説明します。

同じ顧客リストでも、CSV と JSON ではまったく異なって見える — それぞれの形式が異なる構造概念をエンコードする理由

CSV では、各行が 1 つの共有ヘッダーから意味を借用しているため、customer テーブルはコンパクトに見えます。 JSON は、各オブジェクトでプロパティ名を繰り返し、顧客の下にアドレスまたはリストをネストできます。したがって、2 つのファイルは、目に見える事実が重なっている場合でも、異なる構造的機能を表現します。

ToolAcre は共通の交差部分を変換します。フラット ヘッダーとデータ行がフラット オブジェクトの最上位配列になります。ヘッダー内の句読点を分岐に変換したり、繰り返される列から配列を推測したりすることはありません。その境界を理解することで、フラット コンバーターがデータ モデル設計者と間違われるのを防ぐことができます。

CSV グリッドとして - 行と列、位置の意味、テキスト以外の何もなし

この実装内では、CSV は文字列の長方形のテーブルです。最初の行にはヘッダー名が指定され、後続の各セルはその列位置から意味を受け取ります。行の幅がヘッダーと一致する場合にのみ位置が確実に機能するため、短い行は埋め込まれ、長い行は警告されます。

ネイティブの数値、ブール値、オブジェクト、または null セルはありません。引用符は構文を保護しますが、型を割り当てません。数字のシーケンスと true という単語はテキスト値のままであるため、識別子は安定した状態に保たれ、実際に存在するスキーマを適用するよう消費者に求められます。

ToolAcre では、CSV セルは 1 つのヘッダー行の下に位置する文字列です

ワークブックでは JSON の 2000 年代初頭の起源と規格の歴史を求めていますが、このリポジトリはそれらの日付や出版物の情報源ではありません。検証可能な動作は、ブラウザーが `JSON.parse` および `JSON.stringify` を使用し、テーブルに変換するオブジェクトの最上位配列を受け入れることです。

無効な JSON は特定の解析エラーを受け取り、配列以外のルートは拒否され、プリミティブを含む配列はサポートされません。これらの実行時の境界は、引用されていない年表よりも訪問者にとって重要です。歴史的コンテキストは、このタスクのソース セット以外の主要な標準から取得する必要があります。

JSON 標準履歴はリポジトリの証拠の外にあります。サポートされているランタイム形状は検証可能です

JSON オブジェクトは値の横に各キーを保持しますが、CSV セルは同じインデックスのヘッダーに依存します。 ToolAcre は、曖昧さのないキーを 1 回計算してから、すべての行を位置に基づいてマップします。表現されたセルが欠落している場合は空の文字列になるため、オブジェクトは安定したキー セットを共有します。

その自己記述にはサイズと繰り返しコストがありますが、ヘッダーを個別に配置しなくても各 JSON レコードを理解できるようになります。逆に、ヘッダーなしで CSV 列の順序を変更すると、意味が破壊されます。変換では、テーブル全体で名前と位置のペアを維持する必要があります。

ツリーとテーブル — ネスト、配列、オプションのキー、およびそれらが行内に自然な場所がない理由

JSON 値にはオブジェクトと配列を含めることができますが、1 つの CSV セルはネイティブに分岐できません。逆方向では、ToolAcre はネストされた値を `JSON.stringify` でシリアル化し、その JSON テキストを 1 つのセルに配置します。 address_city 列や追加のタグ行は作成されません。

JSON レコード全体のオプションのキーは、最初に見つかった順序で列の結合になり、オブジェクトにキーがない場合は空白になります。これは、まばらなフラット オブジェクトに対する防御可能なフラット化です。任意の木の自然なマッピングは提供されず、ルートは推測ではなくそのように示しています。

うまくいった例 — ネストされたアドレスとタグのリストを含む 1 つのレコード。JSON に示され、その後 CSV 列に強制的に挿入されます。

フラットな CSV 行 `id,name,city` とそれに続く `001,Ada,London` は、3 つの文字列プロパティを持つ 1 つのオブジェクトにきれいに変換されます。代わりに JSON に `address: {city: "London"}` と `tags: ["math","code"]` が含まれている場合、逆変換により、これらのネストされた値が JSON 文字列としてアドレス列とタグ列に書き込まれます。

その CSV を再度ロードすると、再構築されたネストされた値ではなく、JSON 構文を含む文字列が生成されます。後のアプリケーションは独自のスキーマの下でこれらのセルを解析できますが、ToolAcre は解析しません。作業された比較により、テーブル構造がどこで終わり、ツリー構造が始まるのかが正確に特定されます。

有効な例: フラット フィールドは直接変換されますが、ネストされた JSON は逆にセル テキストとしてのみ保持されます。

JSON 行、スキーマ言語、ストリーミング パーサーは実装の範囲外です。出力は 1 つのインデントされた配列で、ファイル入力は変換前にメモリに読み込まれます。解析ワーカーの存在からレコードごとのストリーミングを推測しないでください。

同様に、このツールは必須のプロパティや数値範囲を検証しません。これはオブジェクト キーを空のヘッダーや重複したヘッダーから保護し、行の形状をレポートしますが、セマンティックな正確さは依然として消費者の責任となります。フラット構文は、ビジネス データが間違っていても有効である可能性があります。

どの構造に向かって進んでいるかを知る - ToolAcre CSV Cleaner が CSV と JSON の間でフラットな表形式データをどのように変換するか

宛先がどのような構造を想定しているかを把握します。フラット エクスポートの場合、ToolAcre は透過的なブリッジを提供します。ヘッダーは一意のキーになり、行はオブジェクトになり、値は文字列のままになります。ネストされたアプリケーション モデルの場合は、偶発的な列の命名規則に従って強制的に分岐を行うのではなく、マッピングを定義します。

ダウンロード前にテーブルをプレビューし、不規則な行を解決し、生成された JSON を検査します。このコンバーターは、フォーマットの狭い交差点内で使用すると最も強力になります。概念的な違いが消えるわけではないので、信頼できるワークフローではそれを要求すべきではありません。