整形できるJSONでも、データが正しいとは限らない

字下げで設定やサービスの応答は調べやすくなります。しかし価格が正しいか、必須項目があるか、測定単位が適切かまでは分かりません。

構文は最初の確認であって最後ではない

JSONは文字列とプロパティ名を二重引用符で囲みます。コメントや最後の要素に続くカンマは標準構文に含まれません。

読み取れた後は必須項目、型、単位、許容値というデータ要件を確かめます。quantityが文字列でも有効なJSONにはなりますが、数値を求めるサービスには不適合です。

参考資料: RFC 8259 — JSON syntax and interoperability

文字列の中の空白はデータ

構造記号の周りの空白は、構造を変えずに調整できます。一方、引用符内の空白は値の一部であり、圧縮表示はすべての空白を消す操作ではありません。

ToolRoofは元の数値と文字列の表記を保持します。整形のために識別子"0042"を数値42へ変えたり、1e3を別表記に書き換えたりしません。

参考資料: RFC 8259 — JSON syntax and interoperability

重複したキーには別の判断が必要

重複の扱いはソフトによって異なるため、標準はオブジェクト内の名前を一意にすることを推奨します。整形成功だけでは作者が意図した値は確定しません。

最後の値が必ず採用されると思わず、元データの要件に従って重複を解消します。ここで大きな数値を保持できても、別システムの読み取り精度までは保証できません。

参考資料: RFC 8259 — JSON syntax and interoperability

例:箱のコードは計算用の数値ではない

{"item":"box blue","quantity":2,"amount":1e3,"code":"0042"}は、名前内に2つの空白、数値のquantity、指数表記のamount、先頭が2つのゼロの文字列codeを持ちます。字下げでこの違いを消してはいけません。

圧縮表示でもbox blueの2つの空白、1e3の表記、文字列"0042"は残ります。{"count":2,"count":3}には元データでの判断が必要です。見やすくしても意図した個数は決まりません。

参考資料