JA
ブログに戻る

JSONを整形・検証する方法

JSONを整形するには、インデントと改行を加えて構造を読みやすくするフォーマッターに貼り付けます。検証するには、構文をチェックして壊れている箇所を正確に指し示すパーサーに通します。整形（ビューティファイやプリティプリントとも呼ばれます）と検証は、たいてい一緒に行われます。よいツールは、有効なJSONを再インデントし、入力が壊れているときには何がおかしいのかを正確に教えてくれます。以下では、各操作が実際に何をするのか、整形と圧縮をいつ使い分けるのか、そしてパーサーが投げるエラーをどう読んで直すのかを解説します。

整形・圧縮・検証：3つの異なる仕事

これら3つの言葉は同じ意味で使われがちですが、データに対してそれぞれ別のことを行います。

  • 整形（ビューティファイ） はインデントと改行を加え、ネストしたオブジェクトや配列を視覚的に揃えます。データを変えるのではなく — 空白だけを変えるので — 設定ファイルやAPIレスポンスを目で追うのがはるかに楽になります。
  • 圧縮（ミニファイ） はその逆です。不可欠でないスペース・タブ・改行をすべて取り除き、ペイロードを可能な限り小さくします。データは同一で、実質的に1行に詰め込まれるだけです。
  • 検証 は、そのテキストがそもそも正規のJSONかどうかをチェックします。バリデーターは入力をパースし、整形式であることを確認するか、最初に当たった構文エラーを報告します。

実際には、読んだりデバッグしたりしている間は整形し、データを通信に乗せたり保存したりする直前に圧縮します。検証は両方を支えています — そもそも有効なJSONでないテキストは、確実に整形も圧縮もできないからです。

整形と圧縮の使い分け

人がデータを見る必要があるときは、いつでも整形を選びましょう。

  • デバッグ中にAPIレスポンスを確認するとき。
  • package.json、tsconfig.json、その他の設定ファイルをレビュー・編集するとき。
  • バージョン管理で2つのJSONファイルを差分比較するとき。一貫したインデントは差分を小さく意味のあるものに保ちます。
  • ログからの密な1行の塊を貼り付けて、その構造を実際に理解したいとき。

バイト数が重要で、誰も読まないときは圧縮を選びましょう。

  • HTTPレスポンスやリクエストボディでJSONを送るとき。ペイロードが小さいほど転送が速くなります。
  • 環境変数やURLに設定を埋め込むとき。
  • 多数のレコードを保存するとき。何千行にもわたると空白が積み上がります。

便利な習慣があります。ソースファイルは読みやすさのために整形しておき、ビルドやサーバーが送出時に圧縮するようにすることです。これで両方の良いとこ取りができます — リポジトリでは読みやすく、通信ではコンパクトに。

よくあるJSONエラー（とその直し方）

JSONは意図的に厳格で、それこそがあらゆる言語間で可搬性を持つ理由です。その同じ厳格さが人々をつまずかせます。とくにJavaScriptのオブジェクトリテラルを書き慣れている人はそうです。何度も繰り返し出てくるエラーは次のとおりです。

  • 末尾のカンマ。 オブジェクトや配列の最後の項目の後のカンマ — {"a": 1,} — は無効です。取り除きましょう。これは最もよくある間違いです。大半のプログラミング言語がこれを許すからです。
  • 二重引用符の代わりに単一引用符。 JSONはキーと文字列値の両方に二重引用符を要求します。{'name': 'Ada'} は {"name": "Ada"} にしなければなりません。
  • 引用符のないキー。 キーは常に引用符で囲まれた文字列です。{name: "Ada"} はJavaScriptのオブジェクトであってJSONではありません。{"name": "Ada"} でなければなりません。
  • カンマの欠落。 最後を除くすべての項目には、次の項目と区切るカンマが必要です。間に何もない2つの値が並ぶとパースに失敗します。
  • コメント。 JSONにコメント構文はありません。// で始まる行や /* */ で囲まれた行は許されず、検証を通すには事前に取り除く必要があります。

さらにいくつか注意点があります。数値は先頭のゼロや末尾の小数点を持てません。文字列は \n や \" のような特殊文字をエスケープしなければなりません。そして数値と文字列以外で許される唯一のリテラルは true、false、null（小文字、引用符なし）です。

パースエラーの読み方

検証が失敗すると、パーサーは通常、位置 — 行と列、または文字オフセット — を報告します。その場所を文字どおりに読んでください。エラーは、パーサーが意味を取れなかった最初の文字の位置に報告されます。それは多くの場合、本当の間違いのすぐ後ろです。たとえばカンマの欠落は、カンマがあるべき隙間ではなく、次のキーの先頭で指摘されることがよくあります。報告された箇所に飛び、そのすぐ前のトークンを見ましょう。最初のエラーを直したら再検証してください。パーサーは最初の問題で止まるので、その裏にまだ問題が潜んでいるかもしれません。

ブラウザ内でプライベートに行う

多くのオンラインJSONツールは、貼り付けたものを何でも処理のためにリモートサーバーに送ります。JSONはアップロードするには最悪のデータであることがよくあります。なぜなら、まさにそこにAPIキー、アクセストークン、内部ホスト名、顧客レコード、その他の秘密情報が存在しがちだからです。

AndevのJSONフォーマッターは、これを完全に回避します。ブラウザ自身のネイティブな JSON.parse と JSON.stringify を使うので、次のことが言えます。

  • データは決してアップロードされない。 すべてはお使いの端末上でローカルに動作し、何もどこにも送られません。
  • 正確なパースエラーを表示する。 入力が無効なとき、具体的なメッセージと位置が見えるので、すぐに問題へ向かえます。
  • インデントの大きさを選べる。 2スペース、4スペース、タブのいずれかでプロジェクトのスタイルに合わせて整形 — または1行に圧縮できます。
  • 即時。 アップロードして待つ往復がなく、貼り付けるのと同じくらい速く結果が現れます。

これは、あなたのアプリケーションがすでに使っているのと同じJSONエンジンに頼っているため、報告される検証結果は、同じ文字列をコードがパースしたときの実際の挙動と一致します。だからこそ、機密性の高い設定やAPIペイロードに安心して使え、送出前の手早い健全性チェックとして信頼できます。

近接する作業については、同じローカル・アップロードなしの方式が、AndevのBase64エンコーダー／デコーダーとURLエンコーダー／デコーダーを支えています — どちらも、JSONをデータURI・トークン・クエリ文字列に埋め込んでいるときに便利です。

重要なポイント

  • 整形は読みやすさのためにインデントを加え、圧縮はより小さなペイロードのために空白を取り除き、検証は構文をチェックします。これらは3つの別々の仕事です。
  • 人には整形、通信には圧縮 — ソースファイルは読みやすく保ち、ビルドに出力をコンパクトにさせましょう。
  • 大半のエラーは厳格さの罠: 末尾のカンマ、単一引用符、引用符のないキー、カンマの欠落、コメントは、すべて無効なJSONです。
  • パースエラーは報告された位置で読み、そのすぐ前のトークンを確認しましょう。1つ直したら再検証を。パーサーは最初の問題で止まるからです。
  • ローカルに保つ。 ブラウザネイティブのフォーマッターはデータを決してアップロードしません。これは、設定やAPIのJSONの中に存在する秘密情報にとって最も重要なことです。

今すぐJSONを整理またはチェックする必要がありますか？無料でプライベートなJSONフォーマッターを開きましょう — アップロードなし、登録なし — あるいはブラウザ内開発者ツールの全ラインナップをご覧ください。