JSON 整形：整形・1行への圧縮・構文エラーの位置特定

整形が本当に必要な場面

API のレスポンスが1行に圧縮されていて、入れ子の構造が追えないときです。展開すると、あるフィールドがオブジェクトの中にあるのか、配列の要素の中にあるのかが一目で分かります。

送信前の自己チェックもよくある場面です。末尾の余分なカンマ、引用符のないキー、文字列内のエスケープされていない改行、対応の取れていない括弧は、人間にも見えますが最終判断は解析器のほうが確実です。JSON.parse に位置を出させるほうが、目で追うより速く終わります。

逆方向も必要です。デバッグ用の複数行 JSON を1行に圧縮して、環境変数、コマンドライン引数、1行の設定値に収めるときに使います。

• 1行に圧縮された API レスポンスを展開する
• 送信前に構文を確認する
• 1行に圧縮して環境変数や設定値に収める
• 2つのバージョンの構造の違いを比べる

失敗しないための手順

整形の実体は JSON.parse してから JSON.stringify する処理で、インデントは2スペースです。出力は「解析後の結果」であり、元のレイアウトではありません。キーの順序が変わることもあり、空白は整形時に作り直されます。

エラーの position は、ブラウザの JSON.parse が返す文字オフセットです。Chrome と Edge では0から始まり、通常は行と列も表示されます。解析器が止まった位置であって、原因の文字とは限りません。カンマの抜けは次のキーで、余分な末尾カンマは閉じ括弧で報告されがちなので、報告位置より数行前から確認してください。

JSON は厳格な形式です。コメント、シングルクォート、末尾カンマ、NaN、undefined はすべて不正で、その場でエラーになります。コメント付きの設定は JSONC なので、JSON 用のツールで整えるものではありません。緩い構文が必要なら JSON5 や JSONC の解析器を使ってください。

大きな整数は精度を失います。JSON.parse はすべての数値を IEEE-754 の倍精度浮動小数点数に変換するため、2^53−1（9007199254740991）を超える整数は正確ではなくなります。たとえば 1234567890123456789 は 1234567890123456800 になります。これは JSON.parse の制限で、整形が原因ではありません。注文番号やスノーフレーク ID は、発生元で文字列として保存してください。

大きなファイルではメモリに注意してください。数百 KB から数 MB までは通常すぐに終わりますが、数十 MB のファイルでは、元のテキスト、解析後のオブジェクト、シリアライズ結果が同時にメモリに残るため、目に見えて固まることがあり、メモリの少ない端末では失敗することもあります。処理は送信されず、タブが固まっても再読み込みで復帰します。

• インデントは2スペース。出力は解析後の結果
• position は0から始まる。報告位置の数行前を見る
• コメント・シングルクォート・末尾カンマはエラー
• 2^53−1 を超える整数は変わる。ID は文字列で

代替手段と限界

コマンドラインの jq は、大きなファイルやバッチ処理に向いています。ストリーム処理でメモリ使用量が少なく、フィールドの抽出、絞り込み、変換までできます。導入と構文の学習の手間はかかります。

特定のフィールドだけを見たいときは、開発者ツールの Network → Response で検索するほうが速いです。JSON 全体をコピーする必要はありません。

大きな整数を正確に扱いたい場合は BigInt に対応した解析器を使うか、値を文字列として扱ってください。コメントや末尾カンマが必要なら JSON5 や JSONC、構造の検証が必要なら JSON Schema を使います。

このツールはスキーマ検証を行わず、元の数値の文字列表現も保持しません。整形、圧縮、エラー位置の特定までが役割です。

• 大きなファイルやバッチ処理 → jq
• 特定のフィールドだけ見る → 開発者ツール
• 大きな整数 → BigInt 対応の解析器か文字列
• コメントが必要 → JSON5 や JSONC