JSON検証
JSONバリデーターは、RFC 8259に基づく厳格な構文検証をブラウザ内で直接実行し、ペイロードをネットワークに送信しません。構文エラーの正確な行と桁を視覚的なキャレットポインタで示し、わかりやすい言葉による診断とともに、末尾カンマ、シングルクォート、引用符のないキー、対応しない括弧、BOM、ワープロのスマートクォートを個別に分類します。
JSON検証はどう動きますか？
ブラウザ標準のJSON.parse()実装は、"Unexpected token in JSON at position 4812"のような、役に立たないことで悪名高いエラーメッセージを出します。この生の例外では、開発者はバイトオフセットを手作業で数え、どの引用符、カンマ、括弧が誤って置かれているのかを推測するしかありません。
ToolsByUsの検証ツールは、RFC 8259に従って行番号、桁位置、区切り文字のネストスタック、文字の先読みを追跡する、専用の非再帰的な字句スキャナとトークン検証器を実装しています。
- 生の例外をそのまま出さない：例外は捕捉され、問題の文字を正確な行と桁で指し示すキャレットスニペット付きの、対処につながる診断レポートに変換されます。
- エラーの明示的な分類：末尾カンマ、引用符のないオブジェクトキー、シングルクォートの区切り文字、区切りカンマの欠落、対応しない括弧（例：配列を波括弧で閉じる）を正確に特定します。
- スマートクォートとBOMの検出：リッチテキストエディタやワープロからJSONをコピーしたときに混入しがちな、目に見えないUTF-8バイトオーダーマーク（0xFEFF）やカーリークォート（
“、”）を検出します。 - 厳格な数値文法：RFC 8259セクション6に違反する、
NaNやInfinityといったIEEE 754の非有限数や、先頭ゼロ付きの数値（012など）を拒否します。 - 10,000階層の深さへの対応：反復型の有限状態マシンを採用し、ブラウザのコールスタックオーバーフローに達することなく、深くネストした構造を検証します。
パーサは、BEFORE_KEY、AFTER_KEY、COLON、BEFORE_VALUE、AFTER_VALUEの状態の間を遷移する状態マシンを維持し、開き括弧（[と{）が後入れ先出しの順序で正確に対応する閉じ括弧と一致することを確認しながら動作します。
不正な入力の例
{
'service': "auth",
"active": true,
}出力例
Line 2, Column 3:
'service': "auth",
^
Error: Single quotes are not allowed in JSON. Use double quotes (").
Recommendation: Replace single quotes with double quotes.JSON検証が対応するオプションとエッジケースは？
| パラメータ | 型 | デフォルト | 動作とエッジケース |
|---|---|---|---|
| TRAILING_COMMA | 構文エラー | 禁止 | } または ] の前の末尾のカンマ。JavaScript/JSON5 では有効ですが、RFC 8259 Section 4 に違反します。 |
| SINGLE_QUOTES | 構文エラー | 禁止 | 文字列またはプロパティキーを囲む単一引用符 (')。JSON では標準の ASCII 二重引用符 (") が必要です。 |
| UNQUOTED_KEY | 構文エラー | 禁止 | 二重引用符なしのオブジェクトプロパティ識別子 (例: { name: 'value' })。 |
| MISSING_COMMA | 構文エラー | 禁止 | 連続するオブジェクトのキーと値のペア、または配列の要素間に区切りとなるカンマがない場合。 |
| MISMATCHED_BRACKET | 構造エラー | 禁止 | 不一致のコンテナ区切り文字、例えば配列を中括弧で閉じる場合 ( ] vs } )。 |
| SMART_QUOTES | エンコーディングエラー | 検出 | ワードプロセッサのタイポグラフィカル引用符 (“ ”)。列の位置と修正方法とともに自動的に診断されます。 |
| BOM (Byte Order Mark) | エンコーディングエラー | 0xFEFF | RFC 8259 Section 8.1 では、ネットワークでの交換において先頭の UTF-8 バイトオーダーマークは禁止されています。 |
| NAN_INFINITY_REJECTED | 数値文法 | 禁止 | NaN、Infinity、-Infinity は RFC 8259 Section 6 では有効な JSON 数値トークンではありません。 |
よくある質問
有効なJavaScriptオブジェクト構文がJSON検証で失敗するのはなぜですか？
JSON（RFC 8259）はプログラミング言語ではなく、データ交換フォーマットです。末尾カンマ、シングルクォートの文字列、引用符のないプロパティキー、コメント、NaN値といった、JavaScriptでは許される機能は、Python、Go、Java、C++、Rustのパーサ間の相互運用性を確保するため、JSON標準で明示的に禁止されています。
キャレットポインタは何を示していますか？
キャレット（^）は、字句パーサが予期しない文字や不正なシーケンスに遭遇した、文字の桁を直接指し示します。数メガバイトのペイロードの中でも、構文が壊れている正確な位置を見つける助けになります。
検証ツールはスマートクォートをどう検出しますか？
ドキュメントツール、ブログ記事、メールクライアントからテキストをコピーすると、ASCIIの二重引用符（\"）が組版用のカーリークォート（Unicode U+201CとU+201D）に変換されていることがよくあります。検証ツールはこれらのUnicodeコードポイントを明示的に検出し、標準の二重引用符への置き換えを提案します。
JSONがコメントを拒否するのはなぜですか？
Douglas Crockfordは、パーサが処理ディレクティブやプラグマを持つことがないように、元のJSON仕様からコメントを意図的に除外しました。これにより、JSONは純粋なデータ交換フォーマットであり続けています。コメントに対応した設定ファイルにはJSONCを使ってください。
RFC 8259では重複キーはどのように扱われますか？
RFC 8259は、オブジェクトのキーは一意であるべきと定めています。一部の標準パーサは前の値を後の値で黙って上書きしますが、ToolsByUsは重複キーを診断警告で強調表示し、気づきにくいデータ損失のバグを防ぎます。
検証したペイロードはバックエンドに送信されますか？
いいえ。パース、トークンの確認、検証は100%クライアントサイドで、ブラウザ内で行われます。データがコンピュータの外に出ることは一切なく、バックエンドを一切持たないアーキテクチャで保証されています。