要約：JSONは規則が少なく厳格な構文を持つ——パーサーを壊すエラー（末尾のカンマ、引用符のないキー、シングルクォート）はミニファイされたデータでは見えないが、フォーマットすると一目瞭然だ。実際の構文ルールを知ることで、「APIがエラーを返した」という問題を、2秒で修正できる問題に変えられる。このガイドはEncoding Converter、Character Counter、Text Difference、AI Hidden Charactersと組み合わせて使ってください。

JSONをフォーマットするとは、構造を読みやすくするために空白とインデントを追加することを意味する。検証するとは、その構造が実際にRFC 8259で定義された文法に従っているかを確認することを意味する。ミニファイされたJSON——APIが実際に送信するコンパクトで空白のない形式——は正しいが読みにくい。フォーマッターはデータを変えることなくそれを元に戻す。

本当に重要な構文ルール

JSONのキーはダブルクォートで囲まれた文字列でなければならない——{name: "値"}は無効で、{"name": "値"}だけがパースされる。シングルクォートは文字列やキーに対して決して有効ではなく、これはJavaScriptのオブジェクトリテラルとは異なる。JSONの構文は意図的にこれを制限しているのだ。配列やオブジェクトの最後の要素の後の末尾のカンマ——["a", "b",]——は無効なJSONであり、他の言語では無害（あるいは慣習として必要）であっても、手で編集されたJSONがパースに失敗する最も一般的な理由の一つだ。

"正しく見える"が有効であることと同じではない理由

JSON文書は視覚的に有効なものと見分けがつかなくても、パースに失敗することがある——大きな入れ子構造の末尾で閉じ括弧が欠けている、ワープロソフトから貼り付けたスマートクォート（“）が真っすぐな"の代わりに使われている、あるいは迷い込んだコメント（JSON5やJSONCとは異なり、JSONにはコメント構文がまったくない）——これらはすべて、一見問題なさそうに見えながら厳格なパーサーを壊してしまう。だからこそ、見る前にフォーマットすることが役立つのだ。正しいインデントは、期待される入れ子パターンを崩すことで、閉じられていない括弧を視覚的に明白にする。

フォーマットとスキーマ検証

フォーマッターはJSONが構文的に有効かどうかをチェックする——括弧のバランス、正しく引用された文字列、末尾のカンマがないことなど。それはデータそのものが理にかなっているかはチェックしない：数値であるべきフィールドが実際には文字列になっていないか、必須フィールドが欠けていないか、といったことだ。それは別の問題であり、JSON自体が整形式であるかを単にチェックするのではなく、スキーマ定義に対して構造と型をチェックするJSON Schema検証によって扱われる。

散らかった、または壊れたJSONのためのワークフロー

  1. まず生のJSON——ミニファイされたもの、壊れたもの、その他——をフォーマッターに貼り付ける。
  2. パースされたら、実際に探しているフィールドや値を見つけるためにインデントされた構造を確認する。
  3. パースに失敗した場合は、まずエラーの場所を確認する。ほとんどのパーサーは行/列を報告し、それは通常、欠けているカンマ、括弧、または引用符を直接指し示す。
  4. ソースが手で入力されたか、コードエディタ以外から貼り付けられた場合は、末尾のカンマとスマートクォートに特に注意を払う。

避けるべきよくある間違い

  • 有効に見えるインデントが有効なJSONを意味すると想定すること——フォーマットとパースは別々のステップだ。
  • JavaScriptやPythonの習慣から末尾のカンマを追加すること。これらの言語ではしばしば許容されている。
  • ワープロソフトからJSONを貼り付けて、真っすぐな引用符の代わりに曲がったスマートクォートを得ること。
  • "エラーなくフォーマットされる"ことと"APIが期待するスキーマに一致する"ことを混同すること——これらは異なるチェックだ。

ほとんどのJSONエラーは、特定の場所にある特定の一文字だ。フォーマッターの本当の価値は、その場所を探すために途切れない一行をスキャンさせる代わりに、その場所を見える化することにある。