RFC 8259: JSON

このRFCが決めたこと

横にスクロール

RFC 8259（2017年12月、Tim Bray編）は、JSONを定義する現行の文書だ。RFC 4627（2006年7月、Douglas Crockford）で始まりRFC 7159（2014年3月）を経た系譜の到達点で、STD 90すなわちインターネット標準に格上げされている。決めていることは驚くほど少ない。値は6種類（オブジェクト、配列、数値、文字列、true／false／null）、構造文字はわずか6個、そして本文はわずか16ページだ。

短さは手抜きではなく設計思想だ。JSONは「どう書くか」の文法をきっちり固定する代わりに、「その値をどう解釈し、どんな型に載せるか」の大半をアプリケーションと言語処理系に委ねている。実務のバグは、この委ねられた空白地帯にほぼ集中している。数値の精度、重複キーの扱い、日付の表現——どれもJSON自身は答えを持たず、実装ごとに答えが違う。

要点の精読

4627から8259への系譜とECMA-404

JSONの仕様は3世代を経ている。初版のRFC 4627は情報提供（Informational）扱いで、application/json というメディアタイプを登録した。RFC 7159が標準化トラックに乗せ、RFC 8259がインターネット標準として確定させた。改訂で最も影響が大きかったのは、7159での「JSONテキストの定義変更」だ。

4627ではトップレベルがオブジェクトか配列でなければならなかった。7159はこの制約を外し、JSONテキストを「直列化された任意の値」と再定義した。結果として、次はすべて単独で正しいJSONテキストになる。

42            ← 7159以降は正しいJSONテキスト（4627では不可）
"hi"          ← 同上
true          ← 同上
{"n": 42}     ← 4627でもOK（トップレベルがオブジェクト）

もう一つの特徴が二重標準だ。同じ文法をEcma International がECMA-404として別途定義しており、その第2版もRFC 8259と同じ2017年12月に出た。8259はECMA-404を規範的（normative）参照として挙げつつ、「ECMA-404は本仕様が相互運用性のために避けるよう勧める慣行のいくつかを許している」と明記する。文法は同一だが、相互運用上の助言はIETF側が上乗せしている、という関係だ。両者に差異が見つかればECMAとIETFが協調して両文書を更新する、と取り決められている。

UTF-8の義務化とBOMの扱い

エンコーディングは7159から8259への実質的な変更点の一つだ。7159は「JSONテキストはUTF-8、UTF-16、UTF-32のいずれかで符号化されるものとする（SHALL）」としていた。8259はこれを絞り込み、閉じたエコシステムの外でやり取りするJSONテキストはUTF-8で符号化しなければならない（MUST）と定めた。異なるシステム間で交換するなら、事実上UTF-8一択だ。

BOM（バイトオーダーマーク、U+FEFF）の扱いも明確になっている。生成側はネットワーク送信するJSONテキストの先頭にBOMを付けてはならず（MUST NOT）、解析側は先頭のBOMをエラー扱いせず無視してよい（MAY）。この規範語の強度差を意識すると、実装が守るべき境界が正確につかめる。つまり相手がBOMを送ってこない保証はない一方、自分が送る実装は絶対に付けてはならない。堅牢なパーサは受信時に先頭のBOMを黙って読み飛ばすのが無難だ。なおapplication/json メディアタイプには charset パラメータが定義されていない。文字コードはUTF-8前提で運ぶ、という設計がここにも表れている。

数値は文法と相互運用性がずれている

数値はJSONで最も現実のバグを生む場所だ。文法上、数値は十進で表され、任意の桁数を書ける。整数部・小数部・指数部からなり、次のルールがある。

正しい:   0   -3   3.14   1E400   1e-7   1.0
誤り:     +3   03   .5   5.   0x1F   NaN   Infinity

先頭ゼロは禁止（03 は不可）、数値全体の符号として付けられるのは- だけで先頭の+ は許されない（指数部の1E+10 の+ は別）、そしてNaN やInfinity は文法に存在しない。この繊細な文法を手書きの正規表現で検証しようとすると、指数部や境界を取りこぼしやすい（正規表現パターン集で扱ったような落とし穴だ）。

問題はその先にある。文法は任意精度を許すのに、仕様の相互運用性に関する助言はIEEE 754倍精度（binary64）を前提に書かれている。仕様は、整数が[-(2^53)+1, (2^53)-1] すなわち-9007199254740991から9007199254740991の範囲にあれば、実装同士が値をぴったり一致させられる、と述べる。裏を返せば、この範囲を超える整数は受け取り側で丸められ、値が静かにずれうる。

さらに1.0 と1 は文法上は区別されるが（片方は小数部を持つ）、仕様はどちらが整数でどちらが浮動小数点数かという意味を割り当てていない。この空白の埋め方は言語処理系任せで、JavaScriptはすべて倍精度、Pythonはint とfloat を使い分け、Goのencoding/json は既定でfloat64 に載せる。JSONの数値を言語の型へどう写すかは処理系ごとに違う、という前提を忘れると、往復（parse して再度 stringify）で値が変わる事故につながる（言語ごとの型の扱いはプログラミング側の話題だ）。

重複キーと順序

オブジェクトについて仕様が定める規範は、驚くほど緩い。曰く「オブジェクト内の名前は一意であるべき（SHOULD）」。MUSTではなくSHOULDなので、重複した名前を持つJSONは文法上は不正ではない。そして重複したときの挙動を、仕様は明確に「予測不能」と書く。多くの実装は最後の組だけを採り、別の実装はエラーにするか解析に失敗し、さらに別の実装はすべての重複を報告する、と例示される。

{"role": "user", "role": "admin"}

このJSONを、あるコンポーネントはuser と読み、別のコンポーネントはadmin と読む——それが仕様上あり得る。ここに現実のセキュリティ問題が潜む。認証を担う前段と権限判定を行う後段が別々のパーサを使い、重複キーの勝者について意見が食い違うと、検査をすり抜ける。これがパーサ差異（parser-differential）攻撃で、SHOULDをMUSTのように信頼した設計が生む典型的な穴だ。

順序についての規定も押さえておきたい。オブジェクトのメンバ順序は有意ではなく、パーサが呼び出し側に順序を見せるかどうかは実装によって異なる、と仕様は述べる。一方で配列の要素順序は有意だ。この非対称性が実務に効く。

JSONが決めていないこと（コメント・日付・I-JSON）

JSONの「無いもの」を把握しておくと、多くの設計判断が楽になる。仕様に存在しないのは主に次だ。

• コメント — 構文に無い。設定ファイルで欲しくなるが、JSONそのものには書けない（JSON5やJSONCといった非標準の拡張が別に埋める）。
• 日付・時刻型 — 型が無いため、慣習としてISO 8601（RFC 3339）形式の文字列 "2017-12-01T00:00:00Z" で表す。
• 整数と小数の区別 — 前述の通り数値は一種類で、int とfloat を分けない。
• 末尾カンマ — 配列やオブジェクトの最後の要素の後にカンマを置けない。
• URIやバイナリの型 — 無い。URIは文字列にそのまま入れ（RFC 3986: URIの表現をそのまま値にする）、バイナリはbase64などの文字列にして運ぶ。

文字列にも落とし穴がある。文法上は"\uDEAD" のような対になっていないサロゲート（lone surrogate）を書けてしまうが、これを受け取ったソフトウェアの挙動は予測不能で、文字列長が食い違ったり実行時例外で落ちたりしうる、と仕様は警告する。書けることと相互運用できることは別だ。

これらの緩さを実務向けに締め直したのがI-JSON（Internet JSON、RFC 7493、2015年3月、Tim Bray）だ。UTF-8を必須とし、オブジェクトに重複した名前を認めず、サロゲートや非文字を排し、数値をIEEE 754倍精度の範囲に収めるよう求める。さらに時刻はRFC 3339、バイナリはbase64urlという慣習まで示す。8259が「あるべき（SHOULD）」で濁した箇所を「しなければならない（MUST）」に引き上げたプロファイル、と捉えるとよい。新しくAPIを設計するなら、8259の緩さに甘えるより最初からI-JSON相当の制約を課すほうが安全だ。

つまずきやすい点

第一に、64ビット整数を数値のまま送らないこと。前述の通り安全なのは2^53 - 1 までで、それを超えるIDや金額は文字列で運ぶのが定石だ。第二に、重複キーを「最後が勝つ」と決めつけないこと。それは一部の実装の挙動に過ぎず、仕様上は予測不能で、境界をまたぐと差異攻撃の入口になる。第三に、オブジェクトのキー順に依存しないこと。順序が有意なのは配列だけで、キー順を前提にした比較・署名・キャッシュキー生成は壊れうる。

第四に、規範語を読み分けること。UTF-8はMUST、名前の一意性はSHOULD、BOMの無視はMAY——この強度差がそのまま「破ると相互運用が壊れる/正当化すれば逸脱できる/完全に任意」の境界になる（RFC 2119の読み方が効く）。最後に、手元でJSONを整形・検証したいときは、正規表現で自作するより検証済みのツールに任せるほうが速く確実だ（実用ツール集にブラウザ完結のものを置いている）。

まとめ

RFC 8259は、16ページでJSONの文法を確定させ、STD 90として標準化した簡潔な仕様だ。ただし本当の勘所は、仕様が「あえて決めていない」空白——数値の精度、重複キーの勝者、日付やコメントの不在——にある。文法を覚えるだけでは本番のバグは防げず、UTF-8はMUST、名前の一意性はSHOULDといった規範語の強度と、IEEE 754倍精度という相互運用の前提を押さえて初めて、JSONを安全に運べる。さらに厳密さが要るならI-JSON（RFC 7493）へ進むとよい。他のRFC解説はRFC精読から辿れる。