JSON の整形と検査
既定では並べ替えません。JSON の決まりの上では順序に意味がありませんが、 設定ファイルなど人が読むものでは、書いた人の意図で並んでいることが多いためです。
- 入れ子の深さ思ったより深いときは、1段見落としています
- 2
- キーの数オブジェクトの項目の合計
- 6
- 配列の要素すべての配列の合計
- 3
よくある質問
JSON に末尾のカンマは書けますか？
書けません。{"a":1,} や [1,2,] は誤りです。JavaScript のオブジェクトや配列では書けるため混同されやすいのですが、JSON の仕様には末尾のカンマがありません。設定ファイルで使われる JSONC や JSON5 は JSON とは別の書式で、そちらでは書けます。
キーを ' で囲んでもよいですか？
いけません。JSON の文字列は必ず " で囲みます。' は使えません。またキーも必ず文字列にする必要があるので、{ name: 1 } ではなく { "name": 1 } と書きます。JavaScript のコードからオブジェクトをそのままコピーすると、この2つでつまずくことが多いです。
同じキーを2回書くとどうなりますか？
多くのソフトは、あとに書いたほうだけを残して前のものを黙って捨てます。{"a":1,"a":2} は {"a":2} になります。JSON の仕様はこの場合の動きを定めていないため、エラーにもなりません。気づかないまま値が消えるので、この道具は重複したキーを見つけてお知らせします。
キーを並べ替えても大丈夫ですか？
JSON の仕様の上では、オブジェクトのキーの順序に意味はありません。ただし設定ファイルのように人が読むものでは、書いた人が意図して並べていることが多く、並べ替えると読みにくくなります。この道具が既定で並べ替えないのはそのためです。2つの JSON を見比べたいときだけ、並べ替えを使ってください。
コメントは書けますか？
書けません。JSON にコメントの決まりはなく、// も /* */ も構文エラーになります。考案者のダグラス・クロックフォード氏が、コメントに指示を埋め込む使い方を避けるために外したという経緯が知られています。コメントを書きたい場合は JSONC や YAML など別の書式を使うか、"_comment" のようなキーを1つ設ける方法があります。
貼り付けた内容はどこかに送られますか？
送られません。整形も検査もすべてこの画面の中（お使いの機器の中）で行っています。内容がこの機器から出ることはないので、API の応答や設定ファイルなど、社外に出せないものでもそのまま貼り付けられます。
貼り付けると整形します。壊れているときは、何行目のどこがどう悪いのかを出します。
「何文字目」では探せません
JSON が読めないとき、多くのソフトはこう言います ──Unexpected token } in JSON at position 42。 英語であることより問題なのは、位置が先頭から何文字目で示されることです。
改行を含む長い JSON で「42文字目」と言われても、そこへ辿り着けません。 だからこの道具は、位置を行と列に直し、その行そのものを抜き出して、 問題の桁に印を付けて出します。
位置はブラウザの例外の文言からは取っていません。文言の形はブラウザごとに違い、 同じブラウザでも版によって変わるためです。実際いまの Chrome や Node は 「at position」という形で出さなくなっています。 この道具は JSON を自分で読み直して、つまずいた場所を自分で出しています。
同じキーが2回あると、値が黙って消えます
{"a":1,"a":2} のように同じキーが2回あると、 多くのソフトはあとに書いたほうだけを残します。 結果は {"a":2} で、最初の 1 は消えます。
JSON の仕様はこの場合にどうするかを定めていないため、エラーにもなりません。 設定を書き足していくうちに同じキーを二度書いてしまい、片方だけが効いている状態は実際によく起きます。 この道具は、整形する前に重複を見つけてお知らせします。
JSON に書けないもの
| 書き方 | なぜ書けないか |
|---|---|
| 末尾のカンマ{"a":1,} | JSON の構文に末尾のカンマがありません。JSONC や JSON5 では書けます |
| シングルクォート{'a':1} | 文字列を囲めるのは " だけです |
| 引用符の無いキー{a:1} | キーも文字列なので、必ず " で囲みます |
| コメント// と /* */ | JSON にコメントの決まりはありません |
| NaN・Infinity・undefinedJavaScript の値 | JSON の数はふつうの十進数だけです。null に置き換えてください |
| 先頭の 001 や +1 | 数は 0 か 1〜9 で始まります。符号は − だけで、+ は書けません |
名前は JavaScript から、決めているのは書き方だけ
JSON は JavaScript Object Notation の略です。RFC 8259 の冒頭には「JavaScript のオブジェクトリテラルから派生した」と書かれています。オブジェクトリテラルとは、JavaScript で {"name": 1} のように書く値のことで、 「オブジェクト」「配列」という呼び名も JavaScript の慣わしから来ています。 設計の目標は「小さく、持ち運べて、文字で書けて、JavaScript の一部であること」だったと同じ節にあります。
ただし JSON が決めているのは書き方（構文）だけです。ECMA-404 は 「この規格の目的は正しい JSON テキストの構文を定めることだけで、意味や解釈は与えない」と書いています。 "2024-01-01" が日付なのか、ただの文字の並びなのかは、 送る側と受け取る側が別に取り決めます。書き方だけなので JavaScript 以外の言語でも同じように読み書きでき、メディアタイプ application/json の登録票には、JSON でデータをやり取りしている言語が JavaScript を含めて 20 並んでいます。
42 だけでも JSON。空白に使えるのは4種類
JSON テキストとは値ひとつのことです。RFC 8259 は、以前の規格ではオブジェクトか配列に限っていたと断ったうえで、42 や "こんにちは" や true だけでも JSON テキストだと定めています。 この道具も、値ひとつだけの貼り付けをそのまま整形します。 一方で古い規格に合わせて作られたソフトはオブジェクトと配列しか受け付けないことがあるので、RFC 7493 は、やり取りの決まりを作るときは最上位をオブジェクトか配列にするよう勧めています。
記号のあいだに入れてよい空白は、半角スペース・タブ・改行（LF）・復帰（CR）の4つだけと決まっています。全角スペース（U+3000）はこの4つに含まれないので、 見た目は空白でも、そこで読めなくなります。この道具はその場所を行と列で指し示します。
数の大きさに上限が書かれていない理由
JSON の数には、桁数の上限も、小数の精度の決まりもありません。ECMA-404 は「JSON は数の意味について中立で、人が使う数の書き方、つまり数字の並びだけを提供する」 と書いています。数の持ち方（整数か小数か、何ビットか）は言語ごとに違うので、 書き方だけを決めて、どう持つかは読む側に任せた、というわけです。
そのかわり RFC 8259 は、実際の目安を書いています。多くのソフトは IEEE 754 の倍精度（64 ビットで小数を表す世界共通の決まり）で数を持つので、 それ以上の精度や大きさを期待しないほうが互いに通じやすい、そして整数なら2 の 53 乗から 1 引いた 9007199254740991 まで（負の側も同じ）であれば、どの実装でも値がぴったり一致する、とされています。1E400 や、円周率を小数点以下 30 桁書いた数は「相手がそこまで読める」と期待している印なので、 うまく通じない恐れがある、と例に挙げられています。RFC 7493 は、これより大きな整数（64 ビットの ID など）を正確に渡したいなら、数ではなく文字列に入れて送ることを勧めています。
文字列に書けるエスケープと、文字コードは UTF-8
文字列の中で必ずエスケープ（\ を頭に付けて書くこと）が要るのは、" と \ と、制御文字（U+0000〜U+001F。改行やタブなど）の3種類だけです。それ以外は日本語も絵文字もそのまま書けます。短い書き方は \" \\ \/ \b \f \n \r \t の8つで、そのほかに \u と16進4桁でどんな文字も書けます。ECMA-404 には「\u002F」「\u002f」「\/」「/」の4通りがすべて同じ結果になる、という例が載っています。
16進4桁で書けるのは U+FFFF までなので、それより大きい番号の文字（楽譜のト音記号 U+1D11E など）は、UTF-16 のサロゲートペアという2つの番号に分けて 𝄞 と12文字で書く、と RFC 8259 にあります。
文字コードは UTF-8 と決まっています。RFC 8259 は「閉じた仕組みの外でやり取りする JSON テキストは UTF-8 でなければならない」とし、以前の規格では必須でなかったが、ほとんどの実装が UTF-8 を選んだ結果、互いに通じる唯一の文字コードになった、と経緯を書いています。 ファイルの先頭に付ける BOM（U+FEFF）は、送る側は付けない決まりで、 読む側はエラーにせず無視してもよい、とされています。この道具では、先頭の BOM は1行目1列目の読めない文字として出ます。メディアタイプ application/json の登録票にも charset の項目はなく、「付けても効き目がない」と注記されています。
出どころ: RFC 8259「The JavaScript Object Notation (JSON) Data Interchange Format」（新しいタブで開きます）（第1節・第2節・第6節・第7節・第8.1節・第11節）、 ECMA-404「The JSON data interchange syntax」第2版（新しいタブで開きます）（序文・第1節・第9節）、 RFC 7493「The I-JSON Message Format」（新しいタブで開きます）（第2.2節・第4.1節）、 IANA のメディアタイプ登録票 application/json（新しいタブで開きます）の原文。