JSONをチェック

JSONが実際に禁止しているもの

JSONの文法は意図的にごく小さく作られており、検証エラーのほとんどは、JSONが採用しなかったJavaScriptの書き方を持ち込んだ、ほんの数種類のものです。最後の要素の後の末尾のカンマ。ダブルクォートの代わりのシングルクォート。引用符のないキー。コメント（JSONにはコメントがなく、これまでもありませんでした）。有効なJavaScriptの数値でも有効なJSONではないNaNとInfinity。そして先頭のバイトオーダーマーク（BOM）です。これはどのエディターでも見えず、一部のWindowsツールがUTF-8で保存するときに付加するもので、まったく問題のない文書を最初の1文字目でエラーにしてしまいます。

文法上は許されていても、問題を引き起こすものが2つあります。「有効」が「正しい」と同じではないのはこのためです。重複したキーは仕様で禁止されていません。しかしパーサーごとに解決方法が異なり、ほとんどは最後のものを採用するため、キーが重複した文書はここで有効と判定されても、言語によって意味が変わります。また、JSONでは数値の精度に上限が定められていませんが、ほとんどのパーサーは浮動小数点数として読み込みます。約9千兆を超える整数は気づかないうちに丸められるため、大きなIDは文字列として扱われることが多いのです。

結果として表示されるのは、パースが止まった正確な行、列、文字で、たいていはメッセージそのものより役に立ちます。パーサーが報告するのは、ミスをした箇所ではなく、文書が意味をなさなくなった箇所です。閉じ波括弧が欠けているとファイルの末尾で報告され、カンマが欠けているとその次のトークンで報告されます。報告された位置の少し手前を見る習慣が、最も時間の節約になります。

正しい形式であることと、正しい内容であることは別です。この区別は重要です。ここで確認できるのは構文がパースできることです。APIが求めるフィールドが文書に含まれているか、値が範囲内か、日付が本当に日付か。どれもJSONの問題ではありません。それはスキーマ検証で、スキーマが必要です。ここで完璧な文書でも、送信先のサービスにすぐ拒否されることがあります。

ほかの目的には

文法ではなくスキーマに照らして文書をチェックするなら、JSON Schema が標準で、ajv がその最速の実装です。必須フィールドが欠けている、値が範囲外だといったことを教えてくれます。たいていの場合、本当に知りたいのはそちらです。check-jsonschema は同じチェックをコマンドラインやCIで実行できます。

コマンドラインで何かするなら、jq は持っておくべきツールです。jq empty file.json は検証して成功時には何も出力しないので、スクリプトにぴったりです。jq . は整形します。メモリに収まらないほど大きなファイルには、jq --stream やPythonの ijson が逐次的にパースします。これは文書全体を読み込むページにはできないことです。