開発者ツール · 構文コンバーター
TOML テーブルが JSON オブジェクトになる方法: [テーブル]、[[配列]]、およびドットキー
· 仕組み
トムル json データ形式
TOML のヘッダーは JSON の中括弧とはまったく似ていませんが、まったく同じネストを定義します。この投稿では、[server]、[[products]]、および a.b.c が JSON オブジェクトと配列にどのようにマッピングされるか、および 2 つのモデルがどこで分岐するかについて説明します。
巣作りはどこから来たのでしょうか? — 深くネストされた JSON に変換された平坦な TOML ファイルと、その原因となったヘッダー
TOML ファイルは、括弧で入れ子になっているため、ほぼ平らに見えることがあります。 `[a.b.c]` は中間テーブルを開くため、その下の `d = 1` は `{"a":{"b":{"c":{"d":1}}}}` になります。 JSON 中括弧は、TOML がアクティブなテーブル パスを通じて表現する階層を可視にします。
ToolAcre は構文解析を smol-toml に委任し、JSON が保持できない値を正規化します。これは行ベースの書き換えではありません。テーブル、点線キー、およびテーブルの配列は、JSON シリアル化の前に通常のオブジェクトおよび配列になるため、出力ではスペルとコメントが使用できなくなります。
[table] ヘッダー — ヘッダーがネストされたオブジェクトを開く方法と、[a.b.c] が暗黙的に中間オブジェクトを作成する方法
単一括弧ヘッダーはテーブルを開きます。 `[owner]` は、次の代入を `owner` に指示します。 `[owner.contact]` は、ネストされた連絡先オブジェクトを作成または入力します。中間オブジェクトには個別のヘッダーが必要ありません。それらの存在は、ヘッダーのパス セグメントからわかります。
ヘッダーの前の割り当てはルートに残ります。後のテーブルは、それらを遡及的に移動しません。変換された JSON を確認するときは、行間の物理的な距離ではなく、完全なプロパティ パスに従います。 TOML の現在のテーブルは、別のヘッダーによって変更されるまでアクティブのままです。
[[テーブルの配列]] — 繰り返される二重括弧ヘッダーがオブジェクトを配列に追加する理由と、その順序が保持される理由
二重括弧ヘッダーはテーブルを配列に追加します。 2 つの `[[server]]` セクションは、ソース順に `server: [{...},{...}]` になります。各ヘッダーの下のフィールドは、別のヘッダーが始まるまでその配列メンバーに属し、JSON で繰り返し構成が明示されます。
配列内の順序はデータであり、保持されます。オブジェクト キーのプレゼンテーションは、オプションが選択されたときに後で並べ替えられる場合がありますが、配列メンバーが並べ替えられることはありません。この 2 つを混同すると、単にドキュメントのフォーマットを変更するだけでなく、サーバーの優先順位やプラグインの順序が変更されてしまいます。
点線キーとインライン テーブル — 同じ入れ子を表現するさらに 2 つの方法として a.b = 1 および { x = 1 }
ドット付き割り当ては、別のパス表記を提供します。 `a.b.c = true` は、対応するテーブル ヘッダーと同じネストされたオブジェクト形状を生成します。 `point = { x = 1, y = 2 }` などのインライン テーブルは、すぐにネストされたオブジェクトになります。これらの形式は、レビュー担当者にとっては非常に異なって見えながらも、同様のツリーを記述することができます。
JSON は、結果のキーと値のみを記録し、それらを作成した TOML 記法は記録しません。したがって、逆変換しても、ヘッダー、ドット付きキー、インライン テーブルの中から元の選択を復元することはできません。 TOML ライターは、ツリーから独自の有効なシリアル化を選択します。
引き継がれる型と引き継がれない型 - 整数、浮動小数点、ブール値、文字列は直接マッピングされます。日時は文字列になり、JSON null には TOML ソースがありません
文字列、安全な整数、浮動小数点数、ブール値、配列、テーブルは直接マッピングされます。 TOML の 4 つの時間型は、オフセット日付/時間、ローカル日付/時間、ローカル日付、ローカル時間ではなく、RFC 3339 のようなソース文字列になり、各パスと種類に警告が表示されます。ライターは後で日時トークンを再作成するのではなく、それらの文字列を引用します。
TOML の符号付き 64 ビット整数は、JavaScript の安全な整数範囲を超える可能性があります。 smol-toml は、必要に応じて BigInt などの値を返します。 ToolAcre は、数値を四捨五入するのではなく、10 進数の文字列に変換して警告します。これにより、JSON 型を変更する代わりにスペルが保持されます。
動作した例: pyproject.toml — [project]、[project.optional-dependency]、および [[tool.plugins]] リストは、各レベルがトレースされて JSON に変換されます
`name = "demo"`、`[project]`、`dependencies = ["a", "b"]`、`[project.optional]`、`test = ["vitest"]` を試してから、別個の名前を持つ 2 つの `[[tool.plugins]]` テーブルを試してください。 JSON は、名前をルートに配置し、プロジェクトとオプションをネストし、ツールの下にプラグイン配列を生成します。
`released = 1979-05-27` と `huge = 9223372036854775807` を追加します。最初のものは文字列 `1979-05-27` になります。 2 番目は 10 進数の文字列になります。どちらの警告も変更されたパスを識別し、サイレントな日付または数値の強制を許可する代わりに、非 JSON 型をレビュー可能にします。
これでカバーされないこと — JSON を、賢明なヘッダー グループ化を使用した慣用的な TOML に変換します。これにはスタイルの選択が含まれますが、ルールが完全に決定することはありません
JSON-to-TOML はルート オブジェクトに対してサポートされていますが、慣用的な作成者の選択やコメントは再作成されません。 Null 値のキーは省略されます。配列内の null は位置を保持するために空の文字列になります。 TOML ドキュメントはテーブルでなければならないため、ルート配列、スカラー、または null は拒否されます。
この動作により、逆変換が範囲外であるというアウトラインの意味が修正されます。コンバーターは TOML を書き込みますが、スタイルの忠実性は約束されていません。区別は重要です。サポートされるシリアル化は、ソース ファイルをバイトごとに復元したり、メンテナが好むレイアウトを選択したりすることと同じではありません。
JSON を TOML に書き戻すことはサポートされていますが、コメント、日時型、および著者スタイルは返されません
TOML ヘッダーをパスとして読み取り、二重括弧を追加操作として読み取ります。 JSON ビューは、結果のツリーをトレースするのに役立ちますが、警告によって型の境界を越える日付時刻とワイド整数が公開されます。いずれかの警告が表示された場合は、操作をロスレスと呼び出さないでください。
構成を移行する場合は、変換された出力の横に元のファイルを保管してください。まず値を確認してから、リーダーとターゲット ツールの TOML 組織を編集します。構文コンバーターは、機械的な解析と書き込みのステップを実行します。プロジェクト固有のグループ化、受け入れられるキー、またはアプリケーションがそのファイルをサポートするかどうかを決定することはできません。
最終的な比較では、一緒にすると曖昧になりやすい 3 つの質問を分離する必要があります。まず、解析された値は生き残ったでしょうか?次に、TOML のみの型は JSON 文字列になったのでしょうか、または null は消えましたか?第三に、新たにシリアル化された TOML は、保守者が理解できる方法で構成されていますか?最初の 2 つは、値と警告に対してチェックできます。 3 つ目は人間によるレビューが必要です。これらのチェックを別々にしておくと、タイプや作成者の構造が変更されたときに、技術的に有効なシリアル化が忠実な移行と呼ばれることがなくなります。