JSON構文チートシート

6つの構造文字

JSONの構造をすべて担うのは、6つの約物文字です。オブジェクトを包む波括弧{ }、配列を包む角括弧[ ]、キーと値を隔てるコロン:、そしてオブジェクト内のペアや配列内の値を隔てるカンマ,です。文法のほかの部分は構造的な役割を果たしません。ドキュメント内のその他の文字は、文字列の中にあるか、4つのホワイトスペース文字のどれかです。カンマは厳密に区切りです。2つの項目の間にのみ現れ、閉じ波括弧や閉じ角括弧の前に現れることはありません。

{"name":"Ada","tags":["math","pioneer"]}

{"name":"Ada","tags":["math","pioneer"],}

ホワイトスペース：ちょうど4文字

文字列の外では、JSONが許すホワイトスペース文字はちょうど4つです。スペース（U+0020）、水平タブ（U+0009）、ラインフィード（U+000A）、キャリッジリターン（U+000D）。それ以外——垂直タブ、フォームフィード、ノーブレークスペース、バイトオーダーマーク——は、多くのエディタがそれらの文字を見えない形で表示するにもかかわらず、構文エラーです。だからこそ、ワープロから貼り付けたJSONはしばしば検証に失敗します。画面上はきれいに見えても、文法が知らない文字を含んでいるのです。

ホワイトスペースは、整形を可能にする存在でもあります。文法はトークン間のこの4文字を無視するため、同じドキュメントを、回線上では1つの長い行に、エディタではインデントされた木構造にでき、2つの形式は意味的に同一です——読み込んだあとは、どのパーサーにも区別がつきません。

{"a":1,"b":[2,3]}

{
  "a": 1,
  "b": [
    2,
    3
  ]
}

文字列：ダブルクォートと9つのエスケープ

JSONの文字列はダブルクォートで包まれます。シングルクォートは決して使いません。内側では、バックスラッシュ\がエスケープを導入し、RFC 8259は2文字のエスケープをちょうど9個定義しています。うち2つは必須です。リテラルのダブルクォートのための\\"と、リテラルのバックスラッシュのための\\\\。この2文字は、エスケープしなければ文字列を終わらせたり壊したりするためです。さらに6つは任意の短縮形——フォワードスラッシュのための\/と、テキストに最もよく現れる5つの制御文字のための\b \f \n \r \tです。9番目の形式が\uXXXXで、任意のUnicodeコードポイントを4桁の16進数で書きます。

エスケープの対象でない文字は、すべてUTF-8としてリテラルで書けます。そして2つの形式は等価です。パーサーはどちらでも同一の文字列を渡します。エスケープは表記であってデータではない——この点を、エスケープのガイドが詳しく掘り下げています。

"quote": "she said \"hi\""
"path": "C:\\Users\\ada"
"e-acute": "\u00e9"

quote:   she said "hi"
path:    C:\Users\ada
e-acute: é

数値：ECMAScriptから拡張を引いたもの

数値は、平易な記法の整数または小数で、指数を付けても構いません。RFC 8259はECMAScriptの数値文法を採用し、その拡張を取り除いています。16進なし、8進なし、先頭ゼロなし、先頭のプラスなし、後ろに点だけという形もなし。指数はeまたはEを使い、符号は付けても構いません。数値が始めてよい符号は、無地のハイフンマイナスだけです。NaN、Infinity、-InfinityはJSONではありません——そのような定数を持つ言語は、慣習として代わりにnullを書きます。

精度は意図的に実装に任されています。文法は、パーサーが何桁まで尊重しなければならないかを定めていないため、非常に長い数値は黙って変わって届くことがあります。相互運用可能な生成者は、整数を対象プラットフォームが正確に表現できる範囲に収めます。JavaScriptの背後にあるIEEE 754倍精度では、2^53 − 1までです。

3つのリテラルと5つの定番の拒否

値の種類を完成させるのは、素の3つのトークンです。true、false、そしてnull。すべて小文字で、クォートは付けません。True、FALSE、Noneは構文エラーであり、個性的な大文字小文字の使い方ではありません。この周囲に、現実に拒否される文書のほぼすべてを説明する5つの線が、文法には引かれています：

• コメントは禁止。RFC 8259にコメント構文はありません。//も/* */も、どこに現れても構文エラーです。フォーマットを自分で管理できる場所なら、"_comment"のような兄弟キーで注記してください。
• 末尾カンマは禁止。[1, 2, 3,]も{"a":1,}も無効です。どんなに親切そうに見えても——カンマは区切りであり、項目を無と隔てることはできません。
• シングルクォートと、クォートなきキーも禁止。{name:'ada'}は無効なJSONです。{"name":"ada"}が文法の唯一の書き方です。
• 重複キーは——公式には——禁止。文法は同じ名前が2回現れることを許しますが、どちらの値が勝つかはRFC 8259 §4が実装に委ねているため、重複に依存する文書には定義された意味がありません。
• トップレベルの値は任意。RFC 8259以降、文書全体が素の文字列、数値、ブーリアン、nullでも構いません。RFC 4627の「オブジェクトと配列のみ」ルールは廃止済みで、"hello"も42も完全なJSON文書です。

エンコーディング：UTF-8とバイトレベルのルール

RFC 8259 §8.1はバイトエンコーディングを確定しています。閉じたエコシステムの一部でないシステム間でやり取りされるJSONテキストは、UTF-8でエンコードしなければなりません。開かれた回線上にUTF-16やUTF-32のJSONは存在せず、生成者はバイトオーダーマークを先頭に付けてはいけません。パーサーは先頭のBOMをエラーにせず無視してもよいものの、仕様に適合するものはBOMを出力しません。層の分かれ方に注目してください。\uXXXXのエスケープは個々の文字列内での表記の選択であり、UTF-8は文書全体の性質です。2つは異なる問題を解決します。

これで文法は終わりです。ルールを体に染み込ませる最速の方法は、自分の文書を実際にぶつけてみることです。本物のペイロードを整形し、一度に1つずつルールを破り、バリデーターのエラーを1つずつ読む。10分のわざとらしい失敗は、このページの二回目の通読より多くを教えてくれます。