CSVからJSONへ

CSVは、各行をカンマで分割し、最初の行をヘッダーとして扱うだけで解析できるほど些細に見えます — 実際のデータの値が独自のカンマを含むまでは。これは実際のスプレッドシートのエクスポートで絶えず起こります: 「123 Main St, Apt 4」のような住所、「Smith, Jones & Co」のような会社名、あるいはリストを含む商品説明などです。RFC 4180として正式化されたCSV仕様は、フィールドを二重引用符で囲むことを許可することでこれに対処します。その中では、カンマ、改行、そしてリテラルの引用符文字（二重にすることでエスケープされる）は、構造ではなく単なるデータになります。引用符を完全に無視して各カンマで愚直に分割するパーサーは、まさにそれらの行を破損させます — 「Smith, Jones & Co」を2つの別々の列に分割してしまいます — そして通常それは黙って行われ、何かがおかしくなったことを示すエラーは一切ありません。これがこのバグを単に厄介というより危険にしている理由です。

正しく引用符を意識した解析は、読み手が現在引用符付きフィールドの中にいるかどうかを追跡し、閉じる引用符に到達するまで区切り文字と改行文字を無視します。これが、そうでなければ構造と誤解されるであろう文字を正当に含むフィールドを正しく再構築する唯一の方法です。

生のCSVファイル内のすべての値はテキストです。CSVには数値、ブール値、nullといったネイティブの概念がまったくないためです — `42`を含むセルと`hello`を含むセルは同一に文字として保存されます。型推論は、どの文字列が「本当に」数値、真偽値、nullを意図していたかを推測し、それに応じて変換するプロセスであり、結果のJSONがすべて文字列として引用符で囲まれるのではなく、本当に型付けされた値を持つようにします。

しかし、この推測は保守的でなければなりません。数値に見えるかなりの数の値が、そもそも数値として扱われることを意図していないためです。先頭のゼロ — `007`、`042` — は通常、先頭のゼロが意味を持つ識別子やパディングされたコードを示しており、数値に変換すると黙って破壊されてしまいます。`7`と`007`は同じ数値ですが、まったく異なる識別子だからです。`+44 20 7946 0958`のような電話番号は部分的に数値に見えますが、算術データではありません。JavaScriptの安全な整数範囲を超える値は、数値に変換すると精度を失います。このツールがそれらすべてを文字列として残すのは、まさにここで推測を間違えることが、はるか後になるまで見過ごされやすい形でデータを黙って破損させることを意味するからです。

JSONオブジェクトは同じ名前の2つのキーを持つことができません — 2番目に見つかったものが最初のものを単に上書きし、どこにもエラーが上がることなく列全体の値を黙って捨ててしまいます。スプレッドシートのエクスポートは、ありそうに見えるより頻繁に重複ヘッダーを生成します: 異なる範囲を持つ2つの「合計」列を持つレポート、あるいは両方が「名前」を使っている2つのソースから結合されたエクスポートなどです。重複を検出して2番目の出現を`name_2`にリネームすることで、行オブジェクトの中でどちらが最初に現れたかにかかわらず、両方の列のデータが保持されます。空白のヘッダーも同じ理由で同じ扱いを受けます。JSONには、単に空文字列であるキーを意味のあるアドレス指定可能なフィールドとして表現する方法がないためです。