JSONフォーマッター

JSONはJavaScriptのオブジェクトリテラルが許可するものの厳格なサブセットであり、この2つの差こそがほとんどの「無効なJSON」エラーの出どころです。配列やオブジェクトの最後の要素の後の末尾カンマは、最新のJavaScriptでは合法ですがJSONでは構文エラーです。単一引用符の文字列はJavaScriptではうまく動きますが、二重引用符を要求するJSONでは直接拒否されます。引用符なしのオブジェクトキー — `{"name": "value"}`ではなく`{name: "value"}`と書くこと — は有効なJavaScriptの省略形であり、JSONでは無効です。これらはどれも珍しいエッジケースではありません — JavaScriptを書く際に身についた習慣が、JSONに見えて実はそうではない文書を黙って生み出す、まさにその原因です。

コメントはもう1つのよくある混乱の原因です。JSONに見えるかなりの数の設定ファイル形式 — そして意図的に使われるJSON派生形式のいくつかでさえ — は`//`や`/* */`コメントを許可しますが、JSON仕様自体にはコメント構文がまったくありません。実際にはコメントを含む「JSON」設定ファイルを厳格なパーサーにコピーすると即座に失敗し、修正はコメントを削除するか、そのファイルがそもそも標準JSONを使っていなかったと認識するかのどちらかです。

どこかを示さず「無効なJSON」とだけ報告するパーサーは、文書全体を目で見て1つの欠けたカンマやエスケープされていない引用符を探すことになり、これは数十行を超えると本当に面倒になります。最初の問題の正確な行と列を報告することで、その探索が直接的な位置特定に変わります — エラーは漠然とした一般的な失敗ではなく、特定の文字を記述します — これが大きなAPIレスポンスを数秒で修正するか、手動で数分間走査するかの違いです。

エラーは常にパーサーが遭遇した*最初の*問題を示すのであり、必ずしも文書中のすべての問題ではないことに注意する価値があります: 2つの構文エラーがある文書は最初のものだけを報告し、それを修正することで2つ目が次の試行で初めて明らかになることがあります。すでに構造の理解に失敗したパーサーは、最初に混乱した地点を超えて他の問題を確実に探し続けることができないためです。

一貫したインデントと改行を持つ整形されたJSONは、それを読む人のために存在します — APIレスポンスをデバッグしたり、設定ファイルをレビューしたり、データ構造を一目で理解したりする人です。同じJSONを解析するプログラムにとって、その構造は何の意味も持ちません。だからこそ圧縮された出力は、純粋に人間の可読性のために存在する文字 — インデント、改行、トークン間の分離に必要ない空白 — をすべて削除します。表現されるデータはどちらの形式でも同一であり、伝送や保存に必要なバイト数だけが異なります。深くネストされた構造ではしばしば大幅に。

実用的なルールは単純です: 作業している間 — 読んでいる、デバッグしている、手で編集している間 — はJSONを整形しておき、HTTPリクエストの本文、URLのクエリパラメータ、長さ制限のある環境変数に格納する値など、そのサイズに対して代償を払う場所に行く前に圧縮してください。