テクノロジー · 実用ガイド
TOML で表の二重宣言？見出しを消す前にキーの経路を確認
引用名、ドット付きキー、生成セクションは、文字列が違っても衝突します。元ファイルと解析結果を保ち、次の生成も検証します。
二重テーブルのエラーは意味上の経路を指し、同じ行が二つあるとは限りません。見出しの削除、改名、再インストールの前にファイルと書き手を確認してください。
1. 正確なファイルと書き手を保存する
編集前に元の設定をコピーします。アプリが実際に読むパス、パーサーやPython版、完全なエラー、手作業・マージ・自動生成の別を記録します。エラー行は二度目の宣言を示すことが多いため、すぐ消すのではなく同じ経路を先に定義した箇所を探してください。
出力を調べる間は失敗する生成処理を止めます。管理対象とユーザー所有の値を分けて記録してください。認証情報入りの全設定をオンライン検証に送らず、衝突するキー構造を残した最小の秘匿化例を作ります。
2. 見出し文字列ではなく経路成分を比較する
CPython3.12.14の例では [service.api] の後に [service."api"] を置くと失敗しました。同じ成分を引用しても別の表にはなりません。一方 [service."api.v1"] と [service.api.v1] は異なる木になります。前者の api.v1 は一つのキー、後者は api の下の v1 です。引用位置の変更は設定の意味を変え得ます。
各経路成分と必要な値を書き出します。引用成分内のドットは名前の一部なので、すべてのドットで機械的に分割しないでください。空白や等価な引用表記の違いは、生成側の一意性判定には使えません。
3. 経路が先にどう定義されたかを分類する
同じ例で service=1 の後の [service.api]、service.api.port=8000 の後の [service.api] は拒否されました。service={api={port=8000}} というインライン表の後で [service.api] を拡張する例も失敗しました。値と表、または宣言の衝突であり、字下げでは直りません。
暗黙の親は別です。port を持つ [service.api] の後に name を持つ [service] を置く例は成功しました。本当に重複する service.api は、port と host を保った一つのセクションにまとめると成功しました。所有する宣言を確認し、必要な値を全部残します。独自の後勝ちルールや丸ごと削除は避けてください。
4. 解析木と次の書き込みを検証する
アプリが対応するパーサーで候補コピーを読みます。Python3.11以降の tomllib.load はバイナリーで開いたファイル、tomllib.loads は文字列を受け取ります。検査はTOML構文までで、アプリの設定項目は検証せず、書き込みもしません。8例はCPython3.12.14/TOML1.0で試しました。Python3.15のTOML1.1対応とは区別します。
必要なキー経路、型、値を確認し、アプリ自身の安全な設定検査も実行します。自動生成なら使い捨てコピーで二度実行し、両出力が解析でき、ユーザー値が残り、重複表が増えないことを確かめます。その後にバックアップを保持して置換します。次の生成で再破損する手修正は完了ではありません。書き手や文書化された修正版を使います。
