JSON 比較

JSON に文字列としての差分を取ると、たいてい読めたものになりません。理由は構造にあります。意味がまったく同じ二つの文書が、すべての行で異なることがあり得ます。キーの順序が違う、字下げが違う、片方は圧縮され片方は整形されている。行単位の道具はそれらをすべて変更として報告し、本当に違っている一つの項目は雑音の中に埋もれます。

構造としての比較は、まず両方を解析し、得られた値どうしを比べます。キーの順序は問題でなくなります。オブジェクトは定義上、キーから値への順序のない対応だからです。空白も問題でなくなります。解析を生き延びていないからです。残るのは、あなたが尋ねた問いへの答えです。どのキーが加わり、どのキーが消え、どのキーが同じままで値だけ変わったのか。

配列は構造比較が本当に難しくなる場所であり、結果に驚くより理由を知っておくほうが有益です。配列は順序を持つので位置が意味を担い、先頭に一つ挿入すればそれ以降のすべてが一つずつずれます。素朴な位置比較はそこで全要素を変更と報告します。技術的には正しく、役には立ちません。配列の並べ替えは本物の変更であり、そのように報告されるべきです。実務的な助言は、配列の差分を編集の一覧としてではなく、順序という問いを念頭に置いて読むことです。

型の変化はとりわけ注意に値します。利用者を静かに壊すのがまさにそれだからです。数値の 1 だった項目が文字列の「1」になっても、描画された差分ではほとんど同じに見え、下流の厳密な言語すべてで振る舞いが変わります。欠けていたキーを null が置き換えた場合も同じで、多くの閲覧器ではどちらも何もないように表示され、両者を区別する解析器にとっては意味が違います。

よくある用途が読み方を決めます。配備の前後で API 応答を比べれば、変更が通信上で実際に何を変えたかが分かり、それは公開された変更点の説明を上回ることが少なくありません。二つの環境の設定ファイルを比べれば、検証環境が動いて本番が動かない理由を説明する、ただ一つの異なる指定が見つかります。試験用の固定データと実際の出力を比べることは、失敗の原因究明を数分から数秒に縮めるやり方です。

二つの文書はどちらもブラウザーのタブ内で解析され比較されます。何も送信されません。これはこの site の他のどこよりも意味があります。二つの本番データを比べるとは、実在の顧客記録を二組、同時にページ上に置くことだからです。