JSON フォーマッター
ブラウザ内で JSON を整形・検証・圧縮できます。データを貼り付けてインデントのスタイルを選ぶだけで、すぐにきれいで読みやすい出力が得られます。何もアップロードされません。
0 行 · 0 文字
インデント
JSON フォーマッター の使い方
- 1
JSON を貼り付ける
最小化された JSON、乱れた JSON、すでにインデントされた JSON のいずれかを入力パネルに貼り付けます。
- 2
インデントを選ぶ
整形後の出力のインデントを、スペース2つ、スペース4つ、またはタブから選びます。
- 3
整形または最小化する
「Format」をクリックして JSON を読みやすく整形・検証するか、「Minify」で1行にコンパクト化します。
- 4
結果をコピーする
「Copy」ボタンを使い、整形または最小化した出力をプロジェクト向けに取得します。
JSONを扱う: 整形、検証、そして痛い目に遭う間違い
JSONとは実際に何なのか
JSON(JavaScript Object Notation)はテキストベースのデータ交換フォーマットで、サービス同士がHTTP越しに会話する標準的な方法になりました。名前に反して言語に依存せず、主要なあらゆる言語にパーサーが存在し、伝送される形式はただのUTF-8テキストです。文書はちょうど6つの値の型から組み立てられます。オブジェクト(順序のないキー/値の集まり)、配列(順序のあるリスト)、文字列、数値、真偽値の true と false、そして null です。APIのレスポンスから設定ファイルまで、シリアライズするものはすべてこの6つに分解されます。
2つのルールが絶えず人を戸惑わせます。第一に、オブジェクトのキーは二重引用符で囲まれた文字列でなければなりません。JavaScriptのオブジェクトリテラルとは違い、裸の識別子は許されません。第二に、JSONには整数と浮動小数点数の区別がなく、コメントの構文もありません。数値はただの数値であり、残したい人間向けのメモは、文字列の値の中に置くか、パースの前に取り除かなければなりません。
整形と最小化
これらは同じデータの2つの見方です。整形(beautifying や pretty-printing とも呼ばれます)は、改行とインデントを挿入して入れ子が一目でわかるようにします。これは、ペイロードを読むとき、バージョン管理で2つのレスポンスを比較するとき、あるいはドキュメントに例を貼り付けるときに望むものです。最小化はその逆で、意味のない空白を1バイト残らず取り除いて1つのコンパクトな行を作ります。これは、1キロバイトごとに遅延と帯域の代償を払うネットワーク越しに送るものです。
どちらの方向もデータそのものについては無損失です。JSONではトークン間の空白に意味はないので、40行のオブジェクトを1行にまとめてからまた展開しても、パースした結果は同一の値になります。変わるのはバイト数と読みやすさだけであり、まさにこれが、このツールが1つのスタイルを押し付けるのではなく両方のボタンを提供する理由です。
実際にぶつかる構文エラー
最もよくある単一のエラーは末尾のコンマです。配列の最後の要素やオブジェクトの最後のペアの後にあるコンマのことです。JavaScriptはこれを許容しますが、JSONは禁じているので、閉じ括弧の前にコンマで終わるリストはパースに失敗します。そのすぐ後に続くのが、二重引用符の代わりの単一引用符(JSONの文字列は二重引用符を使わなければなりません)と、JavaScriptのソースからそのままコピーされた引用符のないキーです。
ほかのよくある原因として、紛れ込んだコメント(// やブロック形式。これは JSONC や JSON5 では有効ですが厳格なJSONでは無効です)、仕様には単純に存在しない NaN、Infinity、undefined のような値、そして文字列の中の生のタブや改行といったエスケープされていない制御文字があります。検証器がある行を指したときは、強調された位置の1〜2文字手前を調べてください。パーサーは多くの場合、本当の間違いの次のトークンになって初めて問題に気づくからです。
インデントスタイルを選ぶ
2スペースは、Web上のJSONの事実上の標準であり、多くのリンターやフォーマッターを含むほとんどのツールが既定で出力するものです。4スペースは深く入れ子になった構造をよりゆったりと読ませ、タブは、ファイルをバイト単位で同一に保ちつつ、各開発者が画面上の幅を自分で選べるようにします。正しい答えは、すでにリポジトリで使われているものが何であれ、それです。1つのプロジェクトの中でスタイルを混ぜると、騒がしく無意味な差分が生まれます。
インデントは純粋に見た目だけのもので、文書がパースされた瞬間に捨てられるので、正しさには決して影響しません。1つの幅を選び、それを一貫して適用し、別のソースから貼り付けられたものはフォーマッターに正規化させてください。
キーの順序とデータの完全性
このフォーマッターは文書のインデントと空白を整え直しますが、キーの順序を変えたり、どの値も変更したりはしません。これが大切なのは、JSONの仕様はオブジェクトを順序のないものと定義しているにもかかわらず、実際にはほぼすべての本物のパーサーが挿入順を保持し、後続の利用者、つまりスナップショットテスト、署名されたペイロード、差分を読む人間のレビュアーが、それに依存していることが多いからです。こっそりキーをソートするツールは、署名の検証を壊したり、1行の変更を100行の組み替えの中に埋もれさせたりしかねません。
安定した差分やコンテンツのハッシュ化のために正規化されソートされた出力が本当に欲しい場合、それは整形の副作用ではなく、意図的に、別個に、自覚して選ぶべき操作です。整形と並べ替えを別々に保つということは、何が変わったかを常に正確に把握できるということです。
数値、精度、Unicode
JSONの数値は10進数で、宣言されたサイズ上限はありませんが、ブラウザでそれらをパースするJavaScriptエンジンは、それらを64ビットの浮動小数点数として保存します。つまり、約9千兆(安全な整数の上限)より大きい整数は往復で精度を失うことがあり、これが、大きなID、スノーフレーク値、金額がしばしば生の数値ではなく文字列として伝送される理由です。正確さが重要なら、その値を引用符で囲んでください。
文字列は完全なUnicodeです。文字を直接UTF-8として書くことも、バックスラッシュ u のエスケープシーケンスとして書くこともでき、どちらの形も同じコードポイントにパースされます。フォーマットが端から端までUTF-8テキストなので、アクセント付きの文字、非ラテン文字、絵文字は、整形しても最小化しても損なわれずに残ります。
すべてはブラウザ内にとどまる
すべてのパース、検証、再シリアライズは、JavaScriptでローカルに実行されます。貼り付けたものは何もアップロードもログ記録もサーバーへの保存もされないので、アクセストークン、内部の識別子、顧客データを含むAPIのレスポンスを整形しても安全です。実用上の上限はアップロード制限ではなくデバイスのメモリなので、大きなエクスポートも、まずまずの仕様のマシンなら問題なく整形できます。
役立つ習慣を1つ。連携がうまく動かないときは、まず生のレスポンスをここに貼り付けてください。自分のコードを疑う前にペイロードが正しい形式のJSONであることを確かめれば、シリアライズのバグとパースのバグを数秒で切り分けられますし、しかもペイロードをどこにも漏らさずにそれができます。
よくある質問
Format と Minify の違いは何ですか?
フォーマッターは JSON を検証しますか?
どんなインデントオプションがありますか?
キーの順序を並べ替えたり、データを変更したりしますか?
私の JSON はアップロードされますか?大きなファイルを扱えますか?
関連ツール
こちらの便利なツールもどうぞ