日本語

開発者ツール · 構文コンバーター

CSV に欠けている標準: RFC 4180 がカバーする内容と未解決のままにする内容

· 背景

csv json データ形式

JSON 行から出力されたコンマ、二重引用符、および CRLF レコードを含む CSV フィールド
オリジナル ToolAcre ベクトル イラスト

CSV はどの仕様よりも前のものであり、それを説明する 1 つの RFC は情報提供であり、意図的に範囲を狭めています。この投稿では、RFC 4180 が何を定義しているのか、何についても何も述べていないのか、そしてなぜ CSV の変換が常にネゴシエーションになるのかについて説明します。

誰の CSV が正しいですか? — 同じテーブルの 2 つのエクスポート。1 つはセミコロンを使用し、もう 1 つはカンマを使用します。両方とも CSV と呼ばれます。

ToolAcre は、コンマ、セミコロン、またはタブで区切られた出力を JSON から出力できます。 2 つの競合する CSV エクスポートを読み取ったり、どちらかが正しいと宣言したりすることはありません。ここでは CSV は書き込み専用であるため、区切り文字の選択は検出アルゴリズムではなく明示的な出力オプションになります。

この区別により、よくある事実の誤りを防ぐことができます。セミコロンを書き込むことができるインターフェイスは、未知のファイル内のセミコロンを識別したり、ロケールの小数を処理したり、ヘッダーを解釈したりできることを証明していません。これらは、意図的に除外された個別の入力責任です。

2 つの区切り文字の選択肢は出力オプションであり、このパネルがいずれかのファイルを読み取るという証拠ではありません

このリポジトリには初期のスプレッドシートやデータベースの歴史のソースが含まれていないため、この記事は年表を作成したものではありません。それは現在のライターとそのテスト (レコード、フィールド、区切り文字、CRLF 終了、引用符エスケープ) から始まります。

歴史的背景は、レビューされたソースを使用して後で追加できます。コンバータの実装は、その製品が今日何を書いているかを示す証拠であり、規則が最初に登場した時期やベンダーが分岐した理由を示すものではありません。

RFC 4180 より前の CSV 履歴はリポジトリの証拠の外にあります

区切り文字、二重引用符、復帰または改行を含むフィールドは二重引用符で囲まれ、埋め込まれた各引用符は二重になります。一般的なスプレッドシートのトリミングを防ぐために、先頭または末尾の空白も引用符で囲まれます。レコードは CRLF で終わり、ファイルは終了します。

これらの動作は、リポジトリでテストされた RFC 4180 スタイルのルールに従います。この記事では、代替区切り文字もサポートし、狭い文法外のセキュリティ処理を追加しているため、普遍的な準拠を主張することを避けています。

作者は完全な標準準拠を主張せずに、RFC 4180 スタイルの引用符と CRLF を使用しています。

CSV セルは JSON 型を保持しません。 Null と空の文字列は両方とも空のセルになり、ブール値と数値はテキスト表現になります。 UTF-8 コンテンツはパススルーされ、必要な消費者のためにオプションの BOM をプレフィックスとして付けることができます。

ロケール解釈は埋め込まれていません。セミコロン区切り文字は小数点のコンマと共存できますが、ライターはロケールごとに数値を再フォーマットしたり、日付型をエンコードしたりしません。各フィールドをどのように解釈するかは受信側アプリケーションが決定します。

このライターでは、エンコーディング、タイプ、およびロケールの境界が明示的に維持されます。

実装されているバリエーションは、カンマ、セミコロン、タブに加えて、オプションの BOM です。 `=`、`+`、`-`、`@`、タブまたはキャリッジ リターンで始まる数式のようなテキストには、デフォルトで接頭辞としてアポストロフィが付けられるため、スプレッドシートではテキストとして扱われます。ユーザーはその保護を無効にして警告を受け取ることができます。

このライターには `sep=` ヒントやバックスラッシュ エスケープ モードはありません。これらを出荷オプションとして記載するのは誤りです。埋め込まれた引用符は、テストで主張されているとおりに 2 倍を使用します。

観察されたスプレッドシートのバリエーションは、ここで実装されたオプションと保護に限定されています

このルートのすべての仮定は、解析された JSON から始まります。つまり、どの値が行を提供するか、ネストがどのように点線の列に平坦化されるか、どのキーがヘッダーになるかなどです。受信 CSV は拒否されるため、受信 CSV 方言については想定されません。

この修正により、ワークブックの要求された方向が逆になります。 CSV ~ JSON ワークフローでは、区切り文字、引用符、ヘッダー、およびセルの種類を別のツールで選択する必要があります。 ToolAcre のエラーは、黙って推測するのではなく、その拒否を説明しています。

CSV 入力が拒否された場合にのみ、変換の前提条件が JSON ~ CSV に適用されます。

不正な形式の CSV の修復は範囲外です。壊れた引用符、混合エンコーディング、偶発的な区切り文字には、CSV Cleaner または明示的な診断機能を備えた別のパーサーが必要です。構文コンバータは、破損した CSV テキストではなく、厳密な JSON を受け取ります。

ネストされたツリーがあいまいな点線の列を作成する場合、または 2,000 列を超える場合、出力は依然としてターゲットに適さない可能性があります。警告とキャップは、ダウンロード前にこれらのテーブル形状の失敗を明らかにします。

要点: CSV は形式ではなく規約です。また、構文コンバーター パネルが整形式ファイルを検査できる JSON に変換する方法についても説明します。

CSV は、その選択肢が表示される必要がある規則として扱います。 ToolAcre は出力の選択肢を文書化し、指定されていない逆は拒否します。これは、根本的に異なる 2 つのジョブに 1 つのボタンを使用するよりも信頼性が高くなります。

受信側システムに対してデリミタ、引用符、CRLF、BOM、および数式エスケープを検査します。入力解析が必要な場合は、作成者の規約を未知のファイルに転送するのではなく、質問するツールを使用してください。

実際の受け入れチェックでは、生成されたファイルを対象のコンシューマで開き、生のバイトまたはテキストも検査します。コンシューマ ビューは、表示およびインポートの問題を検出します。生のビューでは、スプレッドシートを再解釈することなく、区切り文字、二重引用符、CRLF、およびオプションの BOM を確認できます。数式のような文字列を不活性テキストとしてテストし、負の数値を数値としてテストします。これらのペアのチェックは、すべてのプログラムが CSV 規則を同一に実装していると主張することなく、作成者の実際の契約を検証します。