JSON5とJSONの違い
JSONの厳格さこそが機能です。RFC 8259があるからこそ、地球上のすべてのパーサーが一致するのです。JSON5はその普遍性の一部を、人間の快適さ――コメント、引用符なしのキー、シングルクォート、末尾カンマ、16進数――と引き換えにします。プログラムが読むものはすべてJSONのままにし、JSON5は、すべての消費者が同じライブラリで解析する設定ファイルの中だけで許可しましょう。
JSON5とJSONの違いとは
人間を苛立たせてきたJSONファイルは、皆同じ方法でそれを行います。フィールドが存在する理由を説明できない、ブロックを一時的に無効化できない、最後のカンマを取り除くのはパーサーが許容できたはずの雑用、という具合です。JSON5はコミュニティの答えです――JSONの厳密なスーパーセットであり、ECMAScript 5の構文を手本に、コメントを追加し、引用符を緩め、末尾カンマといくつかの数値まわりの便利さを許容します。有効なJSONは常に有効なJSON5です。逆は決して成り立ちません。
仕様はIETFの文書ではなくjson5.orgにあり、その置き場所こそがこの取引の率直な要約です。RFC 8259の文法が保証するのは、東京で書かれたペイロードがトロントでも同一に解析されること――ルールは1ページ、方言はありません。JSON5は、厳格なJSONが決して問わない問いを復活させます：どのパーサーで、そのどのバージョンか？ブラウザはJSON.parseしか同梱しないため、JSON5は常に依存関係を意味します。
だからこそ、実務での分担はきれいです。通信経路と保存されるものにはJSON、人間が保守する設定にはJSON5。そこではパーサー依存は一度きりのコストで、コメントは十分に見合います。このページでは、JSON5が何を追加し、何を代償にし、境界線がどこにあるかを順に見ていきます――サイトのローカルJSONツールが、どちら側の確認にも対応します。
自分のファイルが厳格さの線上のどこに位置するか知りたいなら、JSON検証ツールがRFC 8259をローカルで解析し、厳格なパーサーが拒否する最初の構造を指し示します。
すでに厳格なサブセット内にあるファイルには、JSONフォーマッターがブラウザ内で引用符、キー、インデントを正規化します。アップロードは一切ありません。
JSON5が実際に追加するもの
JSON5の拡張はすべてES5のオブジェクトリテラル構文――JSONが元々生まれた場所――に由来します。コメントが復活します。// から行末まで、そして/* block */。キーは有効な識別子であれば引用符なしで書けます。文字列はシングルクォートと、より多くのエスケープを使えます。数値は16進数、先頭または末尾の小数点、先頭のプラス記号、そしてInfinity、-Infinity、NaNという特殊な値を得ます。末尾カンマは両方のコンテナで許容されます。
| 機能 | JSON（RFC 8259） | JSON5 |
|---|---|---|
| コメント | なし――意図的に排除 | // と /* */ を許可 |
| オブジェクトのキー | ダブルクォートの文字列のみ | 有効な識別子なら引用符不要 |
| 文字列の引用符 | ダブルクォートのみ | シングルかダブル |
| 末尾カンマ | 構文エラー | 許可 |
| 数値 | 10進のみ、先頭の+は不可 | 16進、+.5、5.、Infinity、NaN |
| 標準 | RFC 8259 / ECMA-404 | json5.orgの仕様、ライブラリで定義 |
代償：誰がそのファイルを読めるか
JSON.parseは最初に遭遇したコメント、シングルクォート、裸のキーを拒否します――ブラウザネイティブのJSON5は存在せず、それを同梱するサーバープラットフォームもありません。したがってすべての消費者が、互換性のある挙動に固定した同じライブラリを必要とします。ドキュメントが厳格なJSONでなくなった瞬間、「どのパーサーでも動く」は成り立たなくなります――その保証こそが、RFC 8259が買っていた主要なものです。
より微妙な代償は、その隙間で育つ方言の動物園です。JSONC――コメントと末尾カンマのみ――を実際に受け入れるのはtsconfigやVS Codeですが、JSONCは厳格な引用符と数値を保つため、JSON5ではありません。ファイルは方言の間を漂い、エディタはハイライトで食い違い、ツールチェーンのアップグレードが許容されていた構造をエラーに変えることもあります。厳格なJSONには、管理すべきそうした曖昧さがありません。
それぞれの居場所
分担は読み手に従います。人間が書き、レビューする設定は、フィールドを説明するコメント、デバッグ中のコメントアウトしたトグル、ノイズを減らす引用符なしのキーから恩恵を受けます――ツールチェーンがすでにサポートしている限り、そこはJSON5の領土です。プログラムが出力または消費するもの――APIペイロード、保存された状態、構造化ログ、キューメッセージ――は厳格なJSONのままです。普遍性こそが存在意義だからです。
- ワイヤーフォーマット：常にJSON――どの消費者も共有設定ゼロで解析できなければなりません。
- 人間が保守する設定：ツールがすでにネイティブに扱えるなら、JSON5かJSONC。
- スキーマとドキュメント：厳格なJSONは説明をスキーマの中へ押し込みます。コメントには居場所がないからです。
- 保存データ：JSON――その未来の読者には、まだ選ばれていないツールも含まれます。
相互変換
JSONからJSON5への変換は無料です。厳格なJSONはすでにJSON5として解析できるため、「変換」は構造ではなくスタイルの問題です。JSON5からJSONへの変換は、予想どおりの箇所で損失が生じます。コメントには行き先がなく消え、Infinity、-Infinity、NaNにはJSON値がないため、nullか文字列になります。それ以外はすべて生き残ります。キーは引用符を得て、引用符は正規化され、16進数は10進で同じ値として到着します。
境界線は自分の目で確認できます。JSON5ファイルを厳格なバリデーターに貼り付ければ、最初のエラーが線を越えた構造――コメント、引用符、末尾カンマ――を指し示します。この診断は逆方向にも効きます。設定ファイルがいつか厳格なツールに読まれなければならないなら、初日から厳格なサブセットの中に保ってください。ダウングレードこそが損失を伴う旅だからです。
どちらをどの場面で選ぶか
既定はJSONにし、理由があるときだけJSON5に手を伸ばします。その理由とは、人間が保守し機械はただ消費するファイル――ビルド設定、機能フラグ、環境定義――であり、さらにJSON5をネイティブに解析するツールチェーンがすでにあることです。消費者が未知、外部、長期にわたるなら、厳格さは形式主義ではなくインターフェースの契約です。
指針はきれいに反転します。一度もコメントを必要としたことのない設定ファイルにJSON5は不要です。そしてサービスが実行時に解析し始めたJSON5ファイルは、静かにワイヤーフォーマットへ変わっています――つまり、JSONに戻りたがっています。
よくある質問
ファイルをアップロードせずに、ここでJSONの整形や検証はできますか？
はい。フォーマッターと検証ツールは完全にブラウザのタブ内で動作します――解析はブラウザ自身のJSONエンジンでRFC 8259に基づいて行われ、リクエストはページから出ず、サイトのContent-Security-Policyが外向きの呼び出しをブロックし、DevToolsのネットワークパネルは沈黙したままです。設定ファイルがマシンから出ることはありません。厳格なJSONは検証を通ります。JSON5の拡張は、該当する構造を名指しする構文エラーとして現れます。
JSON5は公式の標準ですか？
RFCの意味では違います。json5.orgで仕様が定められ、リファレンス実装とコミュニティが錨となっています。一方JSONにはRFC 8259とECMA-404があります。実務ではこれは、適合性を述べる規定がなく、レジストリがなく、同じパーサーを共有することでのみ相互運用が保証されることを意味します――「どのパーサーでも動く」というJSONの約束の正反対です。
JSONがコメントをサポートしないのはなぜですか？
Douglas Crockfordがフォーマットの標準化の際に意図的に取り除きました。ベンダーがコメントの中に解析ディレクティブを埋め込み始め、実装間の相互運用性を壊したからです。データ交換フォーマットはすべての読み手に同じ意味を与えなければならないため、文法は最小のままとされました。生き残った慣習は、"_comment"のような兄弟キーか、ツールチェーンが許す場合のJSONCです。
JSON.parseはJSON5を扱えますか？
いいえ――最初のコメント、シングルクォート、引用符なしのキー、末尾カンマで例外を投げます。実際のJSON5ファイルの大半は即座にこれに当たります。JSON5ライブラリを使うか、まず厳格なJSONへ書き直す必要があります。JSONCの罠にも注意してください。コメントと末尾カンマを受け入れるパーサーでも、それはJSON5パーサーではなく、シングルクォートと16進数は拒否されます。
JSON5からJSONへの変換でデータは失われますか？
コメントは失われます――正当なJSON表現が存在しないため、どのコンバーターも設計上それを捨てます。Infinity、-Infinity、NaNは値を失い、コンバーターに応じてnullか文字列になります。それ以外はすべて生き残ります。引用符なしのキーは引用符を得て、シングルクォートはダブルクォートになり、16進数は10進で同じ値として到着します。コメントが重要なら、ファイルはコメントが合法である場所にとどめるべきです。
設定ファイルはJSON5にすべきですか、それともYAMLですか？
ツールチェーンがすでにJSON5を扱えるなら、そのままにしてください――移行のコストはコメントの価値を上回ります。新しく始めるなら、YAMLのほうが実戦で鍛えられた人間向け設定フォーマットです。ブロックスカラー、再利用のためのアンカー、10年分のツールを備え、その代償がインデントへの敏感性と型の推論です。JSON5の利点は、厳格なJSONから小さな一歩のところにあることで、設定を機械用データへ昇格させるのが些細だという点です。