01 / 例
例
{"yuzā":{"namae":"こんにちは","messeji":"ようこそ"},"yūkō":true}{
"/yuzā/namae": "こんにちは",
"/yuzā/messeji": "ようこそ",
"/yūkō": true
}コード整形 / MULTIVERTO
入れ子になった JSON オブジェクトのプロパティを、JSON Pointer 形式のパスキーに変換します。
01 / 例
{"yuzā":{"namae":"こんにちは","messeji":"ようこそ"},"yūkō":true}{
"/yuzā/namae": "こんにちは",
"/yuzā/messeji": "ようこそ",
"/yūkō": true
}02 / ガイド
ネストされた JSON オブジェクトのプロパティを JSON ポインタパスキーに変換します。ネストされたオブジェクトを歩き、配列とスカラー値を葉として保持します。
この例では入力「{"yuzā":{"namae":"こんにちは","messeji":"ようこそ"},"yūkō":true}」から出力「{ ⏎ "/yuzā/namae": "こんにちは", ⏎ "/yuzā/messeji": "ようこそ", ⏎ "/yūkō": true ⏎ }」が得られます。⏎ は実際の改行を示します。 区切り記号、名前、値の型を確かめてから結果を使ってください。JSON オブジェクトの平坦化では、ファイルや要求全体を変換する前に小さなレコードを受け取り側のパーサーと比較します。この操作は入れ子のオブジェクトのプロパティを JSON Pointer のパスキーへ変えます。
平坦化ではオブジェクトのプロパティ名に RFC 6901 JSON Pointer のトークンを使います。スラッシュが階層を区切り、名前中のチルダは ~0、スラッシュは ~1 になります。これはパスの表現であり、JSON 全般の圧縮方法ではありません。配列は丸ごと末端の値として残すため、数字のプロパティ名と配列の添字を混同しません。スカラー値と空のオブジェクトも末端です。逆操作は、そのようなパスをキーに持つ平坦な JSON オブジェクトを受け取り、入れ子のオブジェクトを作り、衝突するパスを拒否します。設定を調べる人が、各階層を開かずにどの入れ子のプロパティが変わったか確認するには、パスキーが便利です。ルート配列は対象外です。最上位にオブジェクトが必要なためです。結果の一つの枝を追うと、オブジェクトのメンバーが増えるごとにスラッシュ区切りのトークンが追加され、配列の値はそこへ到達したパスに結び付いたままです。空のルートなら出力には空のオブジェクトを値に持つ一つの空パスがあります。これにより本当に空の文書と、変換結果がない状態を区別できます。平坦なキーを編集する前に、そのスラッシュが階層を示すのか、プロパティ名の一部なのか確認してください。
確実に往復変換するには、オブジェクトを平坦化し、生成されたパスを元の階層へ戻してから、パッチや取り込みに使ってください。復元した JSON 構造について、空のオブジェクト、配列、スラッシュやチルダを含むプロパティ名も比較します。パスの接頭部分を手作業でスカラーの末端に変えないでください。逆変換は、重なるパスや末端値の下に子を作ろうとするパスを拒否します。スラッシュを含むプロパティとチルダを含むプロパティを試します。トークンではそれぞれ ~1 と ~0 を使い、配列は末端値のままです。元データと結果は見た目が似ていても役割が異なります。上記の方法が定義するのは対応する範囲であり、その形式名のあらゆる拡張ではありません。厳格な受け取り側に渡すなら、多くの記録を変える前に小さな既知の例を試してください。検証に失敗した場合は元の入力と最初に報告されたエラーに戻ります。生成結果だけを編集すると原因が隠れることがあります。
ガイドを探す