データとスプレッドシート · CSV クリーナー
CSV と JSON の間の変換: 形状、タイプ、および失われるもの
· 仕組み
csv json データ形式
CSV はフラット テキスト、JSON はネストされた型付きデータであるため、それらの間の変換には決定が必要です。この投稿では、表形式データの一般的な JSON 形状、型がどのように推論されるか、ラウンド トリップで生き残れないものについて説明します。
API は JSON を必要とし、エクスポートは CSV で、すべての数値は文字列として到着します。なぜ 2 つの形式が型に関して一致しないのか
スプレッドシートのエクスポートでは、それらの文字がカウント、製品コード、または識別子を意味するかどうかを示すことなく、42 を表示できます。 JSON は数値と文字列を区別できますが、CSV ソースはその区別を提供できません。したがって、ToolAcre は保守的な表現を選択します。すべてのセルは、数字、正確に見える単語、空のセルを含む JSON 文字列になります。
この決定により、0012 などのテキストがそのまま維持され、API 統合での変換が予測可能になります。これは、ダウンストリーム コードが算術演算を実行する前に、独自のスキーマでフィールドをキャストする必要があることも意味します。生成されたファイルをすでに型付けされているものとして扱うことは、コンバーターからの前提を、目立たないアプリケーション コードに移すだけです。
通常のターゲット形状 — ヘッダーによってキー設定されたオブジェクトの配列、およびヘッダーがクリーンで一意である必要がある理由
ルートは、データ行ごとに 1 つのオブジェクトを含む最上位の配列を生成します。ヘッダー セルはオブジェクト キーになり、値は同じ列位置から取得されます。空白の 3 番目のヘッダーは column_3 になり、id という名前の 2 番目のヘッダーは最初の id フィールドを上書きする代わりに id_2 になります。
クリーンで一意の名前は便利ですが、コンバーターはスペースを小文字にしたり、音訳したり、置換したりしません。キーの計算中にのみヘッダーをトリミングし、必要に応じて位置名または数値接尾辞を作成します。 API で Customer Email ではなく customer_email が必要な場合は、出力コントラクトに依存する前に、その列の名前を慎重に変更してください。
代替形状 — 配列の配列と列指向のオブジェクト、およびそれぞれがより適切な場合
アウトラインでは、配列の配列と列指向のオブジェクトを選択可能なターゲットとして提案しました。これらは合理的なデータ設計ですが、このインターフェイスはそれらを提供しません。その出力は常に、最初の CSV 行をキーとするフラット レコードの JSON 配列で、読みやすいように 2 つのスペースでインデントされています。
この狭い選択肢により、列名がどこに存在するかについての曖昧さがなくなり、すべてのレコードが同じ形状に保たれます。別のコンシューマが配列を予期している場合は、ダウンロードされた JSON をそのコンシューマのスキーマで変換します。 ToolAcre が複数のレイアウトの中から選択すると主張すると、構成またはパネル コードには存在しないコントロールや分岐が記述されることになります。
このコンバーターは 1 つの形状、つまりフラット オブジェクトの最上位配列を出力します。
型の推測は行われません。 CSV テキスト 42 は "42" になり、false は "false" になり、空白は null ではなく "" になります。これはツールのレコードと実装で明示されており、セルを文字列プロパティに直接マップします。ルートは列を検査せず、空でないすべての値が数値であると判断します。
文字列を保持することにより、この記事は、先頭のゼロ、日付、および長い識別子を変更するスプレッドシート アプリケーションに関する公開された議論から切り離されます。ここで重要なのは、コンバーターの実際の契約です。コンバーターは、その種の強制を回避します。消費者は、既知の数量を解析し、識別子をそのままにしておく責任を負います。
タイプはテキストとして保存されます。 ToolAcre は推論を実行しません
逆方向では、ToolAcre は項目がオブジェクトである最上位の JSON 配列を受け入れます。すべてのオブジェクトのキーの結合から最初に見つかった順序で列を構築するため、後のレコードによって導入されたフィールドが失われることはありません。欠落している、null および未定義のプロパティは空の CSV セルになります。
プロパティ内に格納されているオブジェクトまたは配列は、その 1 つのセル内で JSON テキストとしてシリアル化されます。これにより、テキスト表現が保持されますが、ネストされた構造が追加の列または行に変換されるわけではありません。非配列ルートとプリミティブ値を含む配列は、どちらもこのルートがサポートするテーブル モデルに一致しないため、拒否されます。
JSON-to-CSV はオブジェクトの配列を受け入れ、ネストされた値を JSON テキストとして書き込みます
name,active,count の後に Ada,true,007 が続くことを考えてください。 JSON の結果は、名前が「Ada」、アクティブが「true」、カウントが「007」のオブジェクトを含む配列です。そのフラット オブジェクト配列を逆変換すると、同じ 3 つのテキスト セルが生成されます。これは、型推論によってゼロが削除されなかったり、ブール型に見える単語が変換されなかったためです。
次に、別の値の前に空のヘッダーを追加します。 JSON キーは column_4 になるため、ソース名が欠落していても、データは引き続きアクセス可能です。ただし、ヘッダーの幅を超える余分なセルを追加すると、ローダーは不規則な行について警告を出します。その余剰セルにはキーがなく、JSON には存在しません。
これでカバーされないもの — 深くネストされた JSON、スキーマ検証、および非常に大きな JSON ドキュメントのストリーミング
ルートはスキーマ検証ツール、再帰的フラット化ツール、またはストリーミング JSON プロセッサではありません。文書化された 1 つの形状を受け入れ、無効な JSON またはサポートされていないルートを特定のエラーとともに報告します。深くネストされたレコードには、キー内の句読点によって構造が作成されるという自動的な約束ではなく、そのドメインに基づいて設計されたマッピングが必要です。
入力ファイルのチェックでは、構成された 50 MB までのファイルが許可され、CSV の解析がワーカーで行われます。これらの事実はストリーミングを確立しません。ファイル テキストと完了した行は変換のために実体化されます。非常に大規模な JSON ワークフローの場合は、ここで推論するのではなく、インクリメンタル解析を明示的に文書化する実装を備えたシステムを使用してください。
スキーマ検証、プリミティブ配列および非配列ルートが許容された形式の範囲外です
変換は、目に見える選択肢のセットです。キーとしての最初の行、レコードとしてのフラット オブジェクト、値としての文字列です。 ToolAcre は、サンプルから推測するのではなく、これらの選択を安定させます。空白のヘッダーと繰り返しヘッダーは決定論的なキーを受け取りますが、名前のない剰余値が気づかれずに消える前に不規則な入力が表面化します。
プレビューを使用して区切り文字と行の形状を確認し、警告を解決してから、JSON をダウンロードまたはコピーします。結果として得られるファイルは、独自のスキーマを認識しているコードに適しています。これは意図的にそのスキーマの代替ではなく、その制約によって形式変更中にテキスト ID が保護されます。