無効な JSON を修正する方法: すべてのパーサーを破壊する 7 つのエラー

JSON 解析は、デプロイの 5 分前に 1 人の迷子文字によってビルドが破壊されるまでは、些細なことのように思えます。 JSON は意図的に厳密であり、JavaScript よりも厳密です。まさにこれが、JS から来た開発者が常に摘発され続ける理由です。幸いなことに、ほぼすべての「無効な JSON」エラーは、7 つのよくある間違いのうちの 1 つであるということです。それらを認識できるようになれば、ほとんどの壊れた JSON は 1 文字で有効になります。

1. 末尾のカンマ (最大の原因)

これは最も一般的な JSON エラーです。 JavaScript では、オブジェクトまたは配列内の最後の項目の後にカンマを残すことができます。 JSON は、RFC 8259 仕様に従って、そうではありません。したがって、{"name": "Alice", "age": 30,} は 30 の後のカンマのため無効であり、["a", "b",] も同じ理由で無効です。修正方法は、最後のプロパティまたは配列要素の後のカンマを削除するだけです。これは、構成ファイルを手動で編集するジュニアから JavaScript のスニペットを貼り付けるシニアまで、すべての人に刺さります。

2. 二重引用符の代わりに一重引用符を使用する

JSON では、キーと文字列値の両方を二重引用符で囲む必要があります。一重引用符は JavaScript と Python では有効ですが、JSON では有効ではありません。したがって、{'name': 'Alice'} は無効です。 {"name": "Alice"} である必要があります。これは通常、ペイロードが JavaScript console.log または Python の str() 出力から取得された場合に発生します。一重引用符から二重引用符への検索と置換は多くの場合機能しますが、文字列内のアポストロフィに注意してください。「it's」が壊れる可能性があるため、パーサー対応の修正の方が安全です。

3. 引用符で囲まれていないキー

JavaScript では、引用符なしでオブジェクト キーを記述することができます: {name: "Alice"}。 JSON ではこれは許可されておらず、すべてのキーは二重引用符で囲まれた文字列である必要があります。したがって、{name: "Alice"} は {"name": "Alice"} になる必要があります。これは、JavaScript オブジェクト リテラルを JSON コンテキストに直接コピーした場合のもう 1 つの症状です。

4. 括弧の欠落または不一致

すべての左中括弧には右中括弧が必要であり、すべての左角括弧にはそのペアが必要です。一致しない場合、恐ろしい「JSON 入力の予期しない終了」が発生します。これらは、大きなファイルでは目で見つけるのが難しいため、括弧の一致をきれいに印刷して強調表示するフォーマッタが有効であり、構造がインデントされた瞬間に不一致の括弧が飛び出します。

5. コメント

JSON にはコメントがありません。 // 行コメントやブロック コメントではありません。フィールドを説明するコメントを追加した場合、パーサーはファイル全体を拒否します。 VS Code の設定では、コメントを許可する JSONC と呼ばれるバリアントが使用されており、コメント、一重引用符、末尾のカンマを許可する JSON5 と呼ばれるスーパーセットもありますが、JSON.parse などの標準パーサー、Python の json モジュール、およびほとんどのサーバー ライブラリは厳密な JSON のみを受け入れます。コメントが必要な構成ファイルの場合は、JSON を曲げるよりも YAML または JSONC を選択することをお勧めします。

6. 有効な JSON ではない JavaScript 値

JavaScript には存在しますが、JSON には存在しない値が 3 つあります (unknown、NaN、Infinity)。データ ソースがこれらのいずれかを生成した場合、失敗した数値変換を含むオブジェクトをシリアル化する場合によくあることですが、結果は無効な JSON になります。修正するには、それらを null (「値なし」に相当する JSON) または適切なデフォルトに置き換えることです。バグは通常、JSON 自体ではなく、データが生成された時点で上流にあります。

7. 文字列内のエスケープされていない文字

JSON 文字列内では、特定の文字をバックスラッシュでエスケープする必要があります。生の改行、タブ、またはリテラルのバックスラッシュは解析エラーの原因となります。したがって、「C:\Users\Alice」のような Windows パスは無効であり、バックスラッシュを 2 つ付けて「C:\\Users\\Alice」にする必要があり、文字列内の実際の改行は \n として記述する必要があります。これらは多くのエディタでは表示されないため、探すのにイライラさせられます。

最速のデバッグ ワークフロー

最悪の JSON エラー メッセージは、場所のない単に「無効な json」です。優れたバリデーターは 3 つのことを行います。何が間違っているかを通知し、どこ (行と列) を通知し、周囲のコンテキストを表示します。最も速いワークフローは、ファイルをバリデーターに貼り付け、そのファイルが指す行を読み取り、その上の行をチェックすることです。これは、パーサーが次のトークンに到達したときにのみ何かが間違っていることに気づくことが多いため、4 行目のコンマの欠落は 5 行目のエラーとして表示されます。エラーが位置 0 を指している場合は、開始括弧の前にバイト オーダー マークまたは浮遊テキストがないか確認してください。

無効な JSON の防止

3 つの習慣により、ほとんどの JSON の問題を回避できます。文法を尊重するツールを使用せずに、大きな JSON ファイルを手動で編集しないでください。インデントされた JSON では構造エラーが明らかであり、コンパクトな 1 行に隠されているため、保存時にきれいに印刷されます。また、コミットする前に検証します。CI パイプラインの簡単なチェックにより、構文エラーが環境に到達する前に検出されます。壊れた JSON のほとんどは有効なものから 1 文字です。秘訣はそのキャラクターを早く捕まえることです。