JSON バリデーター

JSON の検証器が答える問いはひとつだけです。解析器がこの文書を受け入れるかどうか。狭く聞こえますが、これこそ重要な問いです。あなたの下流にいる利用者は、どの言語であれ同じ文法を当てはめるからです。ここで解析できるなら、あちらでも解析できます。

役に立つのは可否ではなく位置です。現代の JavaScript 実行系は構文エラーの報告の仕方を変えました。新しいブラウザーは文字位置ではなく、問題の周辺を引用した原文の一部を返します。読む側には親切で、道具が入力位置へ変換するのははるかに難しくなりました。一部の検証器が行番号なしで「予期しない記号」とだけ言うようになったのはそのためです。ここでは二分探索で失敗箇所を絞り込み、最小の誤った断片まで縮めることで、エラーが今も行と桁を指し示すようにしています。

現実の失敗の大半はごく少数の原因から来ます。見分けがつけば探す手間が消えます。オブジェクトや配列の最後の要素のあとのコンマは JavaScript では正しく、JSON では誤りです。文字列を単一引用符で囲むのも同じく JavaScript の習慣で、JSON は受け付けません。引用符のないキーは JavaScript のリテラルでは有効で JSON では無効です。どちらの書き方の注釈も、設定ファイルでどれほど自然に思えても、この形式の一部ではありません。そして JavaScript が平気で生み出す裸の NaN や Infinity には、JSON 上の表現が存在しません。

混乱を招く失敗は文字符号化から生まれます。ファイル先頭のバイト順序標識はたいていの編集ソフトでは見えず、最初の文字が解析器の待つ中括弧ではなくなります。文書作成ソフトから貼り付けた文章には、直線の引用符とほとんど見分けのつかない曲線の引用符が混ざっていることがあり、それは別の文字です。完璧に見えるのに位置ゼロで解析を拒む文書は、ほぼ必ずこのどちらかです。

妥当であることは正しいことではありません。文書がきれいに解析できても、用途からすれば誤っていることがあります。必須の項目が欠けている、文字列を期待する場所に数値がある、オブジェクトを求めているのに配列が来ている、といった具合です。これはスキーマ検証という別の、より重い問いであり、文法だけを見る検証器は何も教えてくれません。自分に必要なのがどちらかを知っておくと時間が節約できます。

ここにある他の道具と同じく、文書はブラウザーの中で解析され、外へ送られることはありません。これは特に意味があります。人が検証にかける文書とは本番で問題を起こしている文書であり、そうした文書には実在の利用者に属する実在の識別子が詰まっているからです。