開発者ツール · JSON フォーマッタおよびバリデータ
末尾のコンマが JSON を区切る理由とバリデーターが指す場所
· 仕組み
json 開発者ワークフロー 検証
末尾のコンマは、JSON の最も一般的な間違いであり、コンマ自体にエラーが発生することはありません。文法がカンマの後に何を期待しているのか、そして報告された位置を読み取る方法を学びましょう。
見つけるのに 10 分かかる 1 文字のバグ
発見するのに 10 分かかる 1 文字のバグ — 手動で編集された構成、最後のプロパティの後にカンマが残っている、ビルドが失敗する。厳密なパーサーは、ドキュメント内に実際に存在するトークン シーケンスに従います。 `'enabled': true,` で終わるオブジェクトと `'blue',` で終わる配列を考えてみましょう。次のトークンがコンテナーを閉じたとしても、両方のセパレーターは別の項目を約束します。
ToolAcre はブラウザ エンジン メッセージから位置を取得しません。 JSON.parse は最初に有効性を決定します。失敗した場合にのみ、リポジトリ スキャナはテキストを探索し、最初の許容できない文字を報告します。末尾のコンマの場合、その文字は閉じ中括弧または括弧であり、その理由には「末尾のカンマ」と明示的に示されています。オブジェクト内で、引用符で囲まれた別のメンバー名が欠落しています。配列内で別の完全な値が欠落しています。
JSON 文法でカンマの後に表示される内容
JSON 文法でコンマの後に記述される内容 — RFC 8259 は、配列内の値とオブジェクト内のメンバーを区切るためにコンマを使用します。したがって、セパレータには両側に有効な項目が必要です。オブジェクトのカンマの後に、パーサーは二重引用符で囲まれた名前、コロン、および値を期待します。配列のカンマの後には、有効な JSON 値が必要です。終了デリミタはどちらのプロダクションも満たしません。
区切り文字は 2 つのメンバーまたは要素の間に属し、最後の要素の後には配置されません。最後のカンマを削除しても、値や順序は変わりません。最終値の直後にコンテナを閉じる文法を復元します。これは、コンマが以前のすべての項目の後に問題なく表示される理由でもあります。これらの各コンマの後には、それが約束する次の項目が続きます。
閉じ括弧でエラーが発生する理由
エラーが閉じ括弧で発生する理由 — コンマはコンテナの途中で使用できるため、パーサーは見た目だけでコンマを拒否することはできません。区切り文字を消費し、別の名前または値を期待するように状態を変更します。代わりに `}` または `]` が到着した場合にのみ矛盾が確実になります。この区切り文字は、たとえ先行するコンマが状態遷移を引き起こしたとしても、約束された項目が存在しないことが判明する場所です。
したがって、報告された区切り文字はパーサーの状態に関する証拠であり、中かっこを削除するという提案ではありません。左側のトークンを 1 つ読み取ります。そのトークンがコンマで、区切り文字が同じコンテナを閉じる場合は、コンマを削除して閉じを保持します。 ToolAcre のスキャナーは、末尾のカンマ条件に名前を付け、JSON.parse がドキュメントを拒否した後のソース位置を提供します。
JavaScript、Python、最新のリンターでは許可されますが、JSON では許可されません
JavaScript、Python、最新のリンターでは許可されていますが、JSON では許可されていません。ソース言語リテラルでは、行の並べ替えや将来の追加を確認しやすくするため、最後の項目の後にカンマを許可することがよくあります。フォーマッタはそのスタイルを挿入または保存することもできます。それらの利便性はそれぞれの言語の文法に属します。 `.js` オブジェクト リテラルまたは Python ディクショナリは有効なソースになりますが、同じ表示句読点は RFC 8259 JSON ドキュメントでは無効のままです。
JavaScript 用に構成されたエディターでは、貼り付けられたフラグメントがカンマで終わる場合に警告が表示されない場合があります。宛先パーサーは引き続き受け入れを制御します。 `.json` テキストに対して JSON 言語モードを使用し、API または構成フィールドに送信される正確なペイロードを検証します。ソース ファイル、リンター、または JSON5 パーサーの寛大さは、厳密な JSON コンシューマーに関する譲渡可能な証拠ではありません。
有効な例: 1 つのファイル内の 3 つの末尾のカンマ
うまくいった例: 1 つのファイル内の 3 つの末尾のカンマ — `features` が `"beta",` で終わり、そのオブジェクトを含むオブジェクトが `"enabled": true,` で終わり、2 番目のルート メンバーにも同じ間違いがあるとします。最初の検証は、`beta` の後の閉じ括弧で停止します。このコンマを削除すると、`true` の後の右中括弧まで解析を続行できるようになり、2 番目の場所を修復すると、残っているルートレベルのオブジェクト エラーが明らかになります。
パーサーは通常、以降のすべての欠陥ではなく、継続が不可能な最初のポイントを報告するため、このシーケンスは予期されています。各行と列を終了区切り文字にマップし、その直前の区切り文字を検査し、意図的な変更を 1 つ加えて、検証を再度実行します。すべてのカンマを一括削除しないでください。実際に隣接するものの間には区切り文字が必要です。検証を繰り返すと、同じ文書全体で 3 つの無効な末尾のカンマと有効なカンマが区別されます。
同じエラーを生成するバリアント
関連する区切り文字エラーを引き起こすバリアント (先頭のコンマ、連続する 2 つのコンマ、およびルート値の後のコンマ) はすべて同じ文字を誤って使用していますが、異なるパーサー状態に違反しています。先頭のコンマの左側には完了した項目がありません。連続するカンマは区切り文字の間に項目を提供しません。完全なルート値の後のカンマは、JSON テキストがすでに有効な終わりに達した後に表示されます。
これらのケースには、自動的に末尾のカンマのラベルが付けられるべきではありません。正確な理由は、位置とコンテナの状態によって異なります。 `{"a":1,,"b":2}` 内で、引用符で囲まれたメンバー名が開始されるべき 2 番目のコンマが予期されていません。 `[ ,1]` では、値が必要な場所に最初のカンマが表示されます。終了区切り文字パターンの外側で普遍的な「前のコンマを削除する」ルールを適用するのではなく、診断トークンと周囲のトークンを検査します。
これでカバーされない内容
この内容の対象外 — JSON5 および一部の JSON-with-comments ワークフローでは、末尾のカンマを意図的に許可しています。これらの文法のいずれか用に書かれたファイルは、その宣言されたパーサー、拡張機能、およびツールを使用する必要があります。これを厳密な JSON として扱うと、必ずしも作成ミスではなく、形式の不一致を反映するエラーが生成されます。逆に、寛容なパーサーでそれを受け入れても、ソースを厳密な JSON エンドポイントに安全に送信できるわけではありません。
この診断を黙らせるためだけにパーサーを変更すると、受け入れられる言語が変更され、最終的なコンシューマーとの非互換性が隠蔽される可能性があります。拡張形式では、コメント、引用符で囲まれていない名前、および一重引用符で囲まれた文字列の末尾にコンマが伴う場合があり、テキストが境界を越えるときに追加のエラーが発生することがあります。まずは宛先の契約内容を確認してください。 JSON と表示されている場合は、拡張構文を削除します。 JSON5 または JSONC と表示されている場合は、その正確な形式を実装するツールで検証してください。
要点: 報告された位置の 1 トークン左側を見てください。
要点: 報告された位置の 1 トークン左側に注目してください。キャレットが `}` または `]` の下にある場合、先行するコンマは到着しなかったメンバーまたは要素を約束している可能性があります。構造上必要な終了デリミタを保持し、その終端セパレータのみを削除します。その後、文書全体を再度検証します。これは、最初に修復された場所で、後のコンテナーに別の末尾のカンマが見つかる可能性があるためです。
ToolAcre は責任を限定的に保ちます。JSON.parse はドキュメントが無効であると判断し、ローカル スキャナーは安定した構造上の理由と失敗後の行と列を提供します。その座標を使用して、強調表示された文字を単独で非難するのではなく、パーサーのコンテキストを検査します。末尾のカンマは 1 文字の編集ですが、次の区切り文字にエラーが表示される理由を理解すると、オブジェクト、配列、および深くネストされた構成にわたって同じ診断の信頼性が高まります。