開発者ツール · JSON フォーマッタおよびバリデータ
JSON の標準履歴: RFC 4627 から RFC 8259 および ECMA-404
· 背景
json 規格 検証
JSON は 2 つの標準化団体によって少なくとも 4 回指定されています。この投稿では、Douglas Crockford の json.org から RFC 8259 および ECMA-404 へのパスをたどり、その過程で開発者にとって実際に何が変わったのかを説明します。
私のパーサーはどの仕様に従っていますか?
パーサーはどの仕様に従いますか?答えは通常、通常のオブジェクトや配列ではなく、端に表示されます。 `"ready"` などのトップレベルの文字列、先頭のバイトオーダー マーク、重複するメンバー名、および異常に大きい数値をテストします。さまざまなドキュメントでさまざまなレベルでの構文と相互運用性が説明されていますが、実装では独自のデータ型とエラー動作が追加されています。標準の名前付けは、観察されるパーサー コントラクトがすべての JSON 実装に関する想定から切り離されている場合にのみ役立ちます。
ToolAcre のリポジトリ証拠は具体的であり、一般的な標準の歴史よりも範囲が狭いです。フォーマッタは `JSON.parse` を使用して値を生成し、 `JSON.stringify` を使用して値を出力します。解析が失敗した後、ローカル スキャナは安定した診断位置と理由を提供します。
json.org と JSON の初期の説明
json.org は、JavaScript のオブジェクト リテラル構文から派生したコンパクトな表記法として JSON を提示し、そのコア構造を簡単な文法で文書化しました。この初期の説明は、開発者にオブジェクト、配列、文字列、数値、ブール値、null の共有名と参照を提供するのに役立ちました。ここで歴史的証拠を引用せずに、あるページまたは人物が独力でフォーマットを発見したり、その採用を確立したと主張するよりも、このページを初期の公開説明として説明する方が安全です。
現在のリポジトリ ソースには、json.org のアーカイブ履歴、ブラウザの使用状況、委員会の議論は含まれていません。これらは、このアプリケーションが今日どのように JSON を解析および診断するかを示しています。したがって、この記事の過去の記述は古い規格文書に近いものにとどめ、ローカルファイルが証明できない動機や市場への影響を帰属させることは避けています。
RFC 4627 in 2006 — 最初の IETF 記述、application/json メディア タイプ、およびテキストはオブジェクトまたは配列でなければならないという規則
RFC 4627 (2006 で公開) では、インターネット交換用の JSON について説明し、`application/json` メディア タイプを登録しました。 JSON テキストの定義では、文字列、数値、リテラルがコンテナ内の値として存在する場合でも、最上位にオブジェクトまたは配列が必要でした。 `"ready"` のみを含むドキュメントは、RFC 4627 の JSON テキスト定義の範囲外であっても、後の定式化では有効な値になる可能性があるため、この制限は有用な歴史的な違いです。
この文書では、当時利用可能な実装のコンテキストでのエンコーディングとセキュリティの問題についても説明されています。このリポジトリの変更ログとして読み取るべきではありません。ToolAcre には RFC 4627 互換モードが含まれておらず、そのパーサー パスは値の構築をホスト JavaScript エンジンに委任します。
ECMA-404 in 2013 — Ecma の最小限の構文のみの標準、および 2 つの組織が 1 つの形式を記述することになった理由
ECMA-404 は、2013 で最初に公開され、意図的にコンパクトな形式で JSON 構文を指定します。その焦点は、あらゆるネットワークでの使用のための完全な交換プロファイルではなく、有効な JSON テキストの文法です。この範囲は、ECMA-404 と IETF ドキュメントが、強調する周囲の相互運用性のガイダンスが異なるにもかかわらず、同じ基本的な表記法を記述できる理由を説明するのに役立ちます。 2 つの標準化団体の存在は、通常の使用において 2 つの互換性のないフォーマットを意味するものではありません。
組織が特定の出版経路を選択した理由に関する主張には、このコードベースを超えた文書ソースが必要であるため、この記事は規格の日付から委員会の動機を推測するものではありません。関連する実際的な点は、RFC 8259 と ECMA-404 は構文の調整を目的としているのに対し、RFC 8259 は相互運用可能な交換に重要な推奨事項を提供しているということです。
RFC 7159 および RFC 8259
RFC 7159 は、2014 の RFC 4627 を置き換え、JSON テキストの定義をシリアル化された値に拡張し、オブジェクトまたは配列のみの最上位ルールを削除しました。 RFC 8259 は、2017 の RFC 7159 を置き換え、JSON に対して通常引用される IETF リファレンスのままです。閉じたエコシステムの外側のシステム間で交換される JSON に対して UTF-8 が必要であり、文法だけでどこでも同じ結果が保証されるかのように振る舞うのではなく、数値、重複した名前、Unicode、およびバイトオーダーマークに関する相互運用性の注意を記録します。
トップレベルの `true` は、`JSON.parse` が受け入れるため、ToolAcre の最新のルート値ルールを遵守するためのコンパクトな方法です。この結果は、この実装の動作を示しています。すべてのブラウザ、サーバー、または API がより広い定義を採用した場合には再構築されません。
働く開発者にとって何が変わったのか
開発者にとって最も明確な仕様変更は、ルートでの JSON 値の現代的な受け入れと、相互運用可能なエンコーディングのためのより強力なガイダンスです。あまり目立たない教訓は、有効な構文にはまだ実装の選択肢が残っているということです。重複するオブジェクト名は折りたたまれる可能性があり、メンバーの順序付けは意味論的な契約ではなく、非常に大きな数値は精度を失う可能性があり、異常な Unicode シーケンスはライブラリ内を異なる方法で移動する可能性があります。したがって、標準に準拠したドキュメントには、アプリケーション スキーマによる追加の制約が適用される可能性があります。
このフォーマッタでは、重複する名前と数値トークンが最初に `JSON.parse` を通過するため、後の書式設定には元の字句文書ではなく結果の JavaScript 値が反映されます。スキャナーは障害後の診断に貢献します。重複したメンバーや任意精度の数値は保持されません。これらはリポジトリに裏付けられた観察です。
これでカバーされない内容
これでカバーされないのは、JSON の上に重ねられる仕様です。 JSON スキーマはドキュメントの形状と値に対する制約を記述します。 JSON ポインタはドキュメント内の位置を指定します。 JSON パッチは変更を表します。これらは基本文法とは異なる問題を解決するものであり、JSON 自体の新しいバージョンとして扱うべきではありません。 JSONC、JSON5、および同様のオーサリング形式も、受け入れられた構文を拡張または変更するため、サイレントに厳密な検証に組み込まれるのではなく、独自のパーサーが必要になります。
この記事では、JSON の採用、ブラウザのサポート、または XML との競合に関する包括的な社会史も避けています。これは、リストされているリポジトリ ソースがその物語を実証できないためです。ギャップを埋めるために外部からの引用が発明されたことはありません。
要点: RFC 8259 は引用すべきリファレンスです
RFC 8259 は、現在の JSON 構文と相互運用性のガイダンスについて引用する実践的な IETF リファレンスであり、調整された Ecma 構文標準を提供する ECMA-404 とともに使用されます。 RFC 4627 および RFC 7159 は、公開された定義が、特にトップレベルでどのように変更されたかを理解するのに引き続き役立ちます。 「JSON 仕様」を権威者に対する漠然としたアピールとして使用するのではなく、正確な主張をサポートする文書を引用し、規範的なルールと特定のパーサーで観察される実装動作を区別します。
ToolAcre の場合、擁護可能な声明は、リポジトリが JavaScript の JSON パーサーとシリアライザーを使用し、失敗後の診断のために厳密なローカル スキャナーを追加しているということです。最上位の値、不正な形式の句読点、および数値処理のテストにより、そのルートが記述されます。それらは歴史的資料ではありません。