table_view CSV ↔ JSON 変換ツール star

変換が実際にどのように機能するか

CSVとJSONはデータのモデル化の仕方が異なり、どちらの方向に変換するかによって、どれだけ推測が必要になるかが変わります。CSV → JSONはほぼ機械的です: ヘッダー行がキーの集合になり、以降の各行がそれらのキーを持つ1つのオブジェクトになります — name,ageの下にAda,36があれば[{"name":"Ada","age":"36"}]になります。カンマを含む引用符付きフィールド、エスケープされた引用符("")、複数行セルはRFC 4180に従って解析され、区切り文字(カンマ、セミコロン、タブ)は最初の行から自動的に検出されます。

本当の難しさがあるのはJSON → CSVです。CSVは厳密にフラットです — 1行が1レコード、1セルが1値 — 一方JSONは本来的にネストをサポートしています: あるオブジェクトのフィールドの値として、別のオブジェクトや配列を含めることができ、それを単一のCSVセルに詰め込む普遍的に合意された方法は存在しません。{"name":"Ada","address":{"city":"London"}}を例にとると — 列名はaddress.cityにすべきか(ドット記法で、ネストされたオブジェクトを追加の列に平坦化する)、それともaddressの値全体を{"city":"London"}のように生のJSON文字列として1つのセルに埋め込むべきか? どちらの方法も実際に使われており、どちらも「唯一の」標準ではありません。このツールは1階層のネストにはドット記法を採用し、配列やそれより深い構造については埋め込みJSONテキストにフォールバックします。これにより、単純なオブジェクトは真にスプレッドシートに適した形を保ちつつ、複雑なオブジェクトでデータが黙って失われることもありません。

理解しておく価値があるのは: これはツールの欠陥ではなく、データモデルそのものにある溝だということです。試すどのCSV↔JSON変換ツールも — このツールを含めて — 平坦化についての編集上の判断を下さなければなりません。なぜなら、この2つの形式は完全に相互変換可能であるようには決して設計されていないからです。CSVは表形式の台帳のために作られ、JSONは任意の形状の文書のために作られました。これをあらかじめ知っておくと、複雑なJSONファイルをCSV経由で往復させても元の構造がそのまま再現されることがめったにない理由や、深くネストされたデータをJSON形式のまま保持することが、回避すべき制約ではなく、しばしば単純に正しい選択である理由がわかります。

知っておく価値のあること

• CSVにはデータ型がありません。数値変換を有効にしない限り、すべての値はテキストとして往復します。有効にすると、数値らしき文字列は本物のJSON数値に変換されます(「007」のようにゼロ埋めされたIDは、変換すると壊れてしまうため文字列のまま残されます)。
• 区切り文字は前提とされるのではなく、自動検出されます。多くのヨーロッパやトルコの地域設定では、カンマがすでに小数点記号として使われているため、Excelはセミコロンで書き出します — パーサーは正しいものを選ぶためにヘッダー行を確認します。
• JSON → CSVはすべてのオブジェクトのキーを統合します。一部のレコードにだけ存在するフィールドがある場合、ヘッダーには配列内のどこかで見つかったすべてのキーが含まれ、存在しないものはその行で空欄になります。
• 何もブラウザの外に出ません。解析と変換はどちらもローカルのJavaScriptで行われるため、機密性の高いデータを貼り付けても、どこにも送信されません。
• 行の順序はどちらの方向でも保持されます。どちらの方向に変換しても、最初のデータ行は変換後も最初のままです。これは、スプレッドシートや後続のスクリプトが明示的なソートキーではなく位置的な順序に依存している場合に重要です。