開発者ツール · JSON フォーマッタおよびバリデータ
JSON 行ファイルが 2 行、1 列で検証に失敗する理由
· 仕組み
json 開発者ワークフロー 検証
.jsonl ファイルは 1 つではなく、多数の JSON ドキュメントであるため、厳密なバリデーターは 2 番目のバリデーターが始まる時点で正確に停止します。この投稿では、JSON 行と NDJSON 規則、およびそれらを一度に 1 レコードずつ検証する方法について説明します。
すべての行で有効、ファイルとしては無効
すべての行で有効ですが、ファイルとしては無効です。エクスポートは、すべてのダウンストリーム ツールが問題なく読み取りますが、バリデーターは 2 行目で拒否します。ログ シッパーは各改行をレコード境界として使用できますが、厳密な JSON パーサーはファイル全体を 1 つの入力として認識します。最初のオブジェクトは完成しました JSON;次の左中括弧は不正な 2 番目のルート値です。
ToolAcre は、JSON 行ではなく、1 つの JSON テキストを検証します。スキャナーが最初のルート値を完了すると、JSON 値の終了後に以降の空白以外の文字は予期しないものとして報告されます。非表示のフォールバックとして、行ごとの NDJSON 検証や変換は提供されません。この区別により、緑色の結果が行指向ストリーム内のすべてのレコードがチェックされたことを意味することを防ぎます。
1 つのテキスト、1 つの値 — RFC 8259 が JSON テキストとして定義している内容と、トップレベルの値が 2 つ連続するのが文法エラーである理由
1 つのテキスト、1 つの値 — RFC 8259 が JSON テキストとして定義している内容と、トップレベルの値が 2 つ連続することが文法エラーである理由。 JSON テキストはシリアル化された値であるため、オブジェクト、配列、文字列、数値、ブール値、または null をルートに置くことができます。その値を空白で囲むことはできますが、複数のルートをより大きな有効な文書に分割することはできません。
例: `{"ok":true} {"ok":false}` contains two individually valid objects but is not one JSON text. Parsing the first object consumes a complete value; parsing the entire string must then reject the second `{`。両方の値を通常の JSON で表すには、それらを配列内に配置し、配列要素の間に必要なコンマを追加します。
JSON 行と NDJSON
JSON 行と NDJSON — 改行区切りの規則、それらがストリーミングとログに存在する理由、および JSON 配列との違い。各物理行には 1 つの完全な JSON 値 (通常はオブジェクト) が含まれ、改行は JSON 文法の外側のフレームとして機能します。プロデューサーはレコードを追加でき、コンシューマーは完全なコレクションをロードせずにレコードを段階的に処理できます。
配列には、代わりに 1 つの開始括弧、カンマ区切りの要素、および 1 つの終了括弧があり、ファイル全体が単一の JSON 値になります。これは、制限されたコレクションを返す API には便利ですが、無限に増大するイベント ストリームには扱いにくいです。切り詰められた JSON 行ファイルには、以前の完全なレコードがすべて保存される場合があります。切り捨てられた配列では、通常、それを囲んでいる値が未完成のままになります。
行 2、列 1 でエラーが常に発生する理由
行 2、列 1 でエラーが常に発生する理由 — パーサーは最初の値を終了し、入力の終わりを予期し、2 番目のレコードの最初の文字に到達します。改行自体は正当な末尾の空白であるため、失敗は引き起こされません。次のレコードの開始中括弧は、完成した文書の状態と矛盾する最初のトークンです。
その場所は、2 番目のオブジェクトが不正な形式であるという主張ではなく、診断の証拠です。レポートが常に有効なルートの後の最初の非空白文字を指している場合は、句読点を編集する前にファイルの形状を検査してください。中括弧を削除するとレコードが破損します。行認識リーダーを選択するか、レコードを配列に変換することで、実際のフレーミングの不一致に対処します。
作業例: 3 つのログ レコードの検証
有効な例: 3 つのログ レコードを検証します。各行を単独でチェックするのではなく、各行をコンマで配列してラップします。行に `{"level":"info"}`、`{"level":"warn"}`、および `{"level":"error"}` が含まれているとします。行指向のバリデーターは 3 つの個別の入力を解析し、引用符または末尾のカンマが欠落しているレコードを正確に識別できます。
文書全体を厳密にチェックするには、サンプルを `[{"level":"info"},{"level":"warn"},{"level":"error"}]` に変換します。括弧は 1 つのルートを確立し、カンマはその要素を区切ります。単に改行をカンマに置き換えないでください。周囲の配列が追加されない限り、句読点で区切られた 3 つのルートが生成され、ソース規約で禁止または無視される空行が誤って処理される可能性があります。
2 つの形状間の変換
2 つの形状間の変換 — ラッピング配列が適切な場合と、行区切りの出力ポイントを無効にする場合。 API リクエスト、エディター、または厳密なバリデーターを対象とした有限エクスポートは、多くの場合、配列になることがあります。テキスト連結では埋め込まれたエスケープ文字や無効な行を安全に考慮できないため、変換では最初にすべてのレコードを解析する必要があります。
レコードが継続的に到着する場合、ファイルが追加される場合、またはコンシューマが制限されたメモリとレコード レベルのリカバリを必要とする場合は、JSON 行を保持します。マルチギガバイトのイベント ストリームを 1 つの配列に変換するには、コンテナーの状態を保持する必要があり、閉じ括弧が到着するまで完全な解析が遅れます。逆の方向では、各配列要素を 1 行にコンパクトにシリアル化し、空行または最後の改行を許可するかどうかを定義します。
これでカバーされない内容
これでカバーされないもの — 専用のパーサーを必要とする、改行とレコード区切りフレーム (RFC 7464) を含まない連結された JSON。直接一緒に配置された値は、特にルートが数値または文字列である場合、単純な行演算では安全に分割できません。 RFC 7464 は、表示される改行のみに依存するのではなく、ASCII レコード区切り文字を使用して JSON テキスト シーケンスを構成します。
また、レコードによって共有されるアプリケーション ルールも検証されません。すべての行を解析しても、タイムスタンプが順序付けされていること、識別子が一意であること、またはすべてのオブジェクトが同じスキーマを使用していることを証明することはできません。これらのチェックは、レコードのフレーム化と構文解析の後に行われます。同様に、文字列内にエスケープ シーケンス ` ` として埋め込まれた改行は物理的な境界ではなくデータであり、準拠した行リーダーはその区別を保持する必要があります。
要点: 自分がどの形状を持っているかを知る
要点: どの図形を保持しているのか、そしてバリデーターの位置によってファイルが行区切りであることがどのように瞬時にわかるのかを理解してください。完全な行 1 の値の後の行 2 の最初のトークンでの失敗は、最初のレコードの構文が壊れているのではなく、複数のフレーム化されたレコードを強く示しています。データを変更する前に、拡張機能、プロデューサのドキュメント、および予想されるコンシューマを確認してください。
JSON 行または NDJSON パーサーを使用して、改行が意図的である場合にレコードを個別に検証します。宛先に 1 つの完全な JSON コレクションが必要な場合は、配列を使用します。 ToolAcre は、そのコントラクトが厳格な単一テキスト検証であるため、マルチルート ファイルを正しく拒否します。拒否は、改行で区切られた JSON が本質的に欠陥があることを示すのではなく、そのコントラクトを保護します。バリデーターをフレーム形式と一致させます。