JSON フォーマッター

この JSON フォーマッターの役割

JSON (JavaScript Object Notation) は、プログラム間で構造化データをやり取りする最も一般的な形式です — API 応答、設定ファイル、ログ行などです。コンパクトに設計されており、それゆえオブジェクトが数階層ネストしたり 1 行で届いたりすると読みにくくなります。このツールは貼り付けた JSON を 2 通りに書き直します: 一貫したインデントで構造がひと目で分かる整形版か、任意の空白をすべて取り除いて回線上でできるだけ小さくした圧縮版です。

整形と同時に検証も行います。再直列化する前にテキストを解析するため、不正な JSON が誤解を招く出力を生むことはありません — 代わりに、割り出せるかぎりは解析が失敗した行と列が示されるので、問題箇所へ直接飛べます。

整形と圧縮 — それぞれの使いどころ

二つのモードは正反対の目的を持ち、多くの作業では段階に応じて両方を使います:

• 読んだりデバッグしたりするときは整形 — API 応答を調べる、2 つのペイロードを比べる、プルリクエストで設定ファイルを確認する、といった場面です。インデントが文字の壁を、たどれるツリーに変えます。
• 送り出すときは圧縮 — JSON を HTML に埋め込む、Cookie やキャッシュに保存する、1 バイトを惜しむリクエスト本文に載せる、といった場面です。圧縮された JSON は、空白を除いただけのバイト単位で等価なデータです。

インデントの選択 (スペース 2 個、4 個、タブ) は整形出力にのみ影響します。スペース 2 個は JavaScript と Web ツールで最も一般的な慣習で、スペース 4 個やタブはそれを好むチームに向いています。どれを選んでも結果は有効な JSON のままです — インデントは純粋に見た目だけのものです。

検証エラーの読み方

JSON が不正なとき、このツールは素っ気ない「無効」ではなく、最初の問題の行と列を報告します — 行と列がどこを指すかの節が述べる、ただ一つの場合を除いて。エンジンのエラーメッセージはブラウザによって異なり、位置を省くことも多いため、位置は独立して計算され、調べ始めるのに妥当な箇所を指します。最初のエラーを直して再確認してください — 1 つのはぐれ文字が、いくつもの見かけ上の問題に波及することがよくあります。

よくある JSON の誤り

JSON は、似ている JavaScript のオブジェクトリテラルよりも厳格です。人がつまずきやすいのは次の誤りです:

• 末尾のカンマ: オブジェクトや配列の最後の項目の後ろのカンマは、JavaScript では有効ですが JSON では無効です。
• 単一引用符: JSON の文字列とキーは二重引用符を使わなければなりません。'value' は無効で、"value" が正しい形です。
• 引用符のないキー: すべてのオブジェクトのキーは引用符付きの文字列でなければならないので、{ name: "x" } は { "name": "x" } にする必要があります。
• コメント: JSON にはコメント構文がありません。// や /* */ は解析エラーになります。
• 特別な数値: NaN、Infinity、-Infinity は有効な JSON の数値ではありません。
• 誤った引用符: ワープロから貼り付けた「スマートクォート」は引用符に見えますが別の文字であり、解析できません。

報告される行と列が指しているもの

位置は、あなたが何かを書き落とした場所ではありません。パーサーがそこにあってはならないものに初めて出会った場所であり、この二つは通常べつの場所です。下のオブジェクトでは 3 行目を閉じるはずのカンマが欠けていて、このツールは 4 行目、3 列目 — 次のキーを開く引用符 — を報告します。その引用符が来るまで誤りは何もありませんでした。文書は 3 行目のあとで正しく終わることもできたからで、パーサーが書き落としを知るのは、カンマでも閉じ波括弧でもないものに出会ったときだけなのです。

{
  "id": 42,
  "name": "widget"
  "price": 9.99
}

• カンマの欠落は、そのあとに続くものの最初の文字の位置で報告されます。上のようにインデントされた JSON ではそれが次の行になるので、示された行はその一つ上の行と合わせて読んでください。
• 余分なカンマは閉じ括弧の位置で報告されます。最後のペアが 2 行目にあるオブジェクトなら 3 行目、1 列目です。カンマはもう一つペアが来ると約束し、括弧はその約束を破るものだからです。
• 閉じられていない文字列は、たいていは開いた引用符ではなく、その文字列が始まった行の末尾で報告されます。あとの行にある次の引用符が、別の場所でそれを閉じてしまうことがあるからです。改行は JSON の文字列の中に置けないので、改行がそこにあってはならない最初の文字になります。
• 完璧に見える文書で 1 行目、1 列目と出るときは、たいていバイト順マークです。一部のエディターは UTF-8 として保存するときにこれを書き込みます。目に見えず、開き波括弧の前に座り、JSON にはその置き場所がありません。

そして位置をまったく割り出せないときは、推測した座標を挙げるのではなく、位置を付けずに失敗だけを報告します。自信ありげに示された行と列が完全に正しい構文を指していれば、あなたは間違った場所を探すことになり、それは文書が解析できないと知るだけよりも悪いのです。

整形が変えるものと保つもの

ほとんどの文書では、答えは空白だけで、ほかには何もありません。しかしこのツールはあなたのテキストを編集するのではなく、実際の値へ解析してその値を書き直します。そしてこの往復に耐えないものが五つあります。どれもツールの欠陥ではなく — それぞれ、数値やオブジェクトとは何かについて JSON 仕様が述べていることです — どれも、出力を元のテキストに上書きする前に知っておく価値があります。

• 同じキーを二度書いた場合: 二つのうち後のものだけが残ります。オブジェクトは一つのキーを二度持てないからです。RFC 8259 は、名前が重複したオブジェクトを受け取るソフトウェアの振る舞いは予測できないと述べており、別のパーサーは先のほうを残すこともあるので、二つのうちどちらが残るかも頼りにできることではありません。
• 十五桁より長い整数: JSON の数値は倍精度浮動小数点として読まれ、これは 2 の 53 乗までの整数をすべて正確に保ちます — 十六桁の数です — ですから十五桁の整数は必ず残り、それより長いものは残らないことがあります。12345678901234567890 を貼り付けると 12345678901234567000 が出てきます。長いデータベース識別子がいつもの犠牲者です。できるなら文字列のままにしてください。
• 指数形式と末尾のゼロは正規化されます: 1e3 は 1000 として、1.50 は 1.5 として戻ります。標準の書き方で書かれた同じ数です。
• その表現が支えられる範囲の外にある量は、まるで別のものとして戻ります: 1e400 には倍精度の値がなく null として戻り、1e-400 は 0 として戻ります。長い小数は、長い整数と同じように、その表現が持つ精度に丸められます。
• エスケープはそれが表す文字になります: \u00e9 は é として戻り、エスケープされたサロゲートペアはそれが綴る絵文字として戻ります。どのパーサーにとっても同じ文字列で、二つの書き方のうち一方が単に短いだけです。

キーの順序はあなたが書いたとおりに保たれますが、知っておく価値のある例外が一つあります。数字だけからなり、素朴な非負の整数として読めて、およそ四十億より小さいキーは配列の添字として扱われ、どこに書いてあっても、数値の順でそのオブジェクトの先頭に戻ってきます。ほかには何も動きません。ほかのキーが並べ替えられることはなく、加えられたり名前を変えられたりすることもありません。このどれかが気になるなら、整形ではなく圧縮して、結果を元のテキストと一文字ずつ比べてください。往復が何をしたかを見るいちばん短い道です。

読みたい JSON が文字列の中にあるとき

ウェブフックのログ、メッセージキュー、データベースの列は、JSON 文書ひとつをまるごと一つの文字列値として運ぶことがとても多く、その中の引用符はすべてエスケープされています。外側の文書は完全に有効なので、ツールはそれを整形して有効と報告します — そしてあなたが読みに来た部分は、長い一行のバックスラッシュのままです。何も壊れていません。これは二つの文書で、一方が他方の文字列の中に包まれているのです。

{
  "event": "order.created",
  "payload": "{\"id\":42,\"total\":19.99}"
}

読むには二回の手順が必要になります。外側の文書をここで整形し、目的の文字列の引用符のあいだにあるものをコピーし、エスケープを解いて、その結果をもう一度貼り付けてください。JSON 文字列エスケープのツールがその中間の手順を行います。そのエスケープ解除の向きは、バックスラッシュとそれに続く引用符を二重引用符そのものに戻し、その行をこのページが整形できる文書に戻します。ファイルを作ったものを自分で制御できるなら、より良い直し方は上流にあります。ペイロードを文字列ではなく入れ子のオブジェクトとして送れば、どちらの手順も要りません。

一行に一つのオブジェクトは一つの文書ではない

ログファイル、API のエクスポート、ストリーミングのエンドポイントは、一行に完全な JSON オブジェクトを一つ持つことがよくあります。この形式は JSON Lines、または NDJSON と呼ばれます。各行はそれ自体で有効な JSON ですが、ファイルは JSON 文書ではありません。JSON 文書は最上位の値をちょうど一つ持つのに対し、これは複数を、一つずつ続けて、それらをつなぐものなしに持っているからです。

{"level":"info","msg":"started"}
{"level":"warn","msg":"retrying"}
{"level":"error","msg":"gave up"}

それをここに貼り付けると、ツールは 2 行目、1 列目を報告します。最初のオブジェクトはきれいに終わり、そして文書が終わっているべき場所で二つ目が始まったからです。そこからの道は二つあります。一度に一行だけ整形する — ログの一件を読んでいるときに欲しいのはこれです。あるいはファイルを一つの文書にする — 行を角括弧で包み、最後の行以外のすべての行末にカンマを置く — 配列を期待する何かにまとめて読み込ませようとしているときに欲しいのはこれです。