報告の内容
解析できる文書には、根の値の形と大きさを返します。
✓ Valid JSON
Root: object (4 keys)
Size: 312 characters, 18 lines
そうでなければ、解析器のメッセージを、位置を行と桁に直して返します。二度ではなく、一度だけ。
どんな JSON の値も文書である
42 は妥当な JSON です。"こんにちは" も、true も、null もです。
RFC 7159(2014 年)以降そうなっています。元の RFC 4627 は最上位にオブジェクトか配列を求めていました。古い解析器の一部はいまも旧規則を課します。検査器が「はい」と言い、ライブラリが「いいえ」と言う日に思い出すとよいでしょう。
重複キーは警告であって誤りではない
{ "port": 8080, "port": 3000 }
報告は文書を妥当と告げ、二つ目の port の位置を注記として添えます。
これは JSON フォーマッターとの意図的な違いです。あちらは同じ入力を拒否します。RFC 8259 はオブジェクトの名前が一意であるべきだと述べます。SHOULD であって MUST ではないので、この文書は本当に妥当であり、検査器は見えるものを述べます。
整形器は何かを作らねばなりません。作るとは、二つの値のどちらが残るかを決めることです。解析器ごとに決め方は違います。大半は最後を、あるものは最初を採り、拒否するものもあります。その選択はあなたのものであって道具のものではありません。だから整形器は止まり、検査器は警告します。
「妥当」が意味しないこと
そのファイルがあなたの思うことを言っている、という意味ではありません。
必須項目の欠落、数値が入るべき場所の文字列、アメリカ式に書かれた日付、打ち間違いのある URL。どれも問題なく解析できます。それを確かめるにはスキーマ——JSON Schema と、それを読む検査器——が要ります。このページが答えるのとは別の問いです。
プライバシー
すべての処理はブラウザ内のJavaScriptだけで完結します。データがアップロードされることはないため、機密情報でも安心して利用でき、オフラインでも動作します。