JSON を INI に変換

この一文がこの変換のすべてです。INI ファイルはセクションの並びで、それぞれが平坦なキーと値の行を持ち、セクションの中にセクションを入れる方法はありません。仕様というものが存在せず、1985 年生まれで設定形式に仕様が必要だという考えより前からあり、パーサーごとに引用符やコメントについての見解が少しずつ違います。レジストリがこの形式をレガシー扱いにしている理由です。

JSON は無制限に入れ子にできます。そのため変換は木構造を 2 段に押し込む必要があり、興味深いのはそれがうまくいくかどうかではなく、3 段目以降を何が引き受けるかです。短く言えば、データは保ちつつ構造をあきらめます。これは設定ファイルが普段移動する方向としては正しい取引です。

オブジェクトを値に持つトップレベルのキーはすべてセクションになります。server、logging、database というオブジェクトを持つ JSON ファイルは [server]、[logging]、[database] を生み、それぞれの中のキーがその下に書かれます。もともと人が書いた設定であれば、これは非常にしばしば正確に一致し、出力は人が自分でタイプしたであろうファイルになります。

単純な値を持つトップレベルのキー——デバッグフラグやバージョン番号など——は、最初のセクション見出しのあとではなく前に書かれます。これは様式の選択ではありません。INI のセクションは次の見出しまでのすべての行を自分のものとするので、もっと下に書かれた素のキーは、直前にあったセクションのメンバーになってしまい、意味が変わってしまいます。

3 段目の入れ子はドット区切りのキーとして書かれます。server が tls オブジェクトを持ち、その中に証明書のパスがあれば、出力は [server] セクションの中に tls.cert という行を持ちます。何も捨てられず、元の形へ戻る道はキー名の中に書き込まれます。

この慣習を理解して入れ子を再構築するパーサーもありますが、多くはそうではなく、tls.cert をたまたまドットを含むキーとして扱います。設定を読むだけならどちらでもたいてい問題ありません。ただし一般には往復可能ではありません。本当にドットを含む JSON のキーは、1 段の入れ子と見分けが付かなくなり、どちらだったかをどんな読み手も判断できません。

キーは残り、値は残りません。null は、キー、等号、そして何もない状態として出てきます。これは INI が未設定の値に対して持てるもっとも近い表現です。この形式には null もそれを表す方法もないからです。

あなたのパーサーがそれをどう扱うかはさまざまで、10 秒かけて確認する価値があります。Python の configparser は空文字列を返します。一部の読み手も空文字列を返しますが、真偽値の文脈では偽として扱います。キーそのものを完全に読み飛ばす読み手もあります。「何も設定されていない値」と「設定されていないこと」の違いがアプリケーションの挙動を左右するなら、そのあいまいさをそのまま出荷するのではなく、該当する行を手作業で削除してください。

INI にはリストがありません。許可されたホスト 3 つの配列は、0、1、2 というキーを持つ 3 行になります。すべての値は保たれますが、どのパーサーの慣習ともほとんど一致しません。リストに対応する形式は、たいてい 1 行にカンマ区切りで値を並べることを期待しており、一部は同じキーの繰り返しを期待します。

これは、INI にしたあとではなく、実行する前に JSON の側で変えておく価値がある唯一の部分です。アプリケーションが期待する区切り文字で配列を 1 つの文字列に結合してから変換すれば、出力はパーサーがネイティブに読める 1 行になります。逆の順番で行うと、番号付きのグループを 1 つずつ手作業で編集することになります。

トップレベルの JSON 配列は、配列の位置にちなんだ名前のセクション——[0]、[1]、[2]——を生み、それぞれが 1 件のレコードのキーを持ちます。このファイルは構文的には有効な INI ですが、それを読んでまともに動くプログラムはありません。

この出力は失敗というより信号です。INI は設定形式——1 つのアプリケーションのための名前付き設定の集まり——であり、レコードの一覧はデータです。手元にあるのが一覧なら、人が読むなら CSV や表計算ファイル、プログラムが読むなら JSON かデータベースが行き先です。この変換は拒否しません。1 レコードだけのファイルを求めるのは正当な用途だからです。しかし番号付きのセクションが並ぶなら、もともとの問いへの答えは「いいえ」だったということです。

ほとんどの値はそのままの姿で書かれます。パス、ホスト名、ポート番号、フラグなど、誰かが自分でタイプしたファイルのように見えるままです。3 種類の値だけは違います。改行を含む値、すでに引用符で始まり終わっている値、両端にスペースやタブを持つ値はダブルクォートで囲まれ、その中では改行はバックスラッシュと n、復帰はバックスラッシュと r、バックスラッシュ自体は 2 つのバックスラッシュとして書かれます。

このエスケープは最近加えられたもので、本物の欠陥を修正しています。2026 年 8 月 9 日までは、改行を含む JSON の文字列は本物の改行としてそのまま書かれていました。つまり {"app":{"motd":"hello\n[admin]\npassword=secret","plain":"x"}} という JSON は、元データのどこにもない [admin] セクションを生み出し、その後ろに書かれた plain というキーは app の中ではなく、その作り出されたセクションの中にあるものとして読み戻されていました。1 つの値が隣のキーを移動させてしまえたのです。この変換ツールは両方の処理が同じエスケープに合意しているので、複数行の値も往復に耐えます。ファイルを読む別のプログラムがこのエスケープを理解しない場合、改行の代わりに 2 文字がそのまま返ってくることがあるので、証明書や埋め込まれたスクリプトは、いまも独立したファイルとして持ち、INI にはそのパスだけを書いておくべきです。

INI はすべてをテキストとして保存します。JSON の true は true として書かれ、8080 は 8080 として書かれ、それが後で何を意味するかは、ファイルを読むソフト次第です。Python の configparser は getboolean や getint でこれを明示的に扱い、真として yes、on、1 も受け入れます。

値を信頼する前に、使っているパーサーがどちら向きに推測するかを知っておく価値があります。JSON の中の 1.0 というバージョン文字列は、読み戻されるとほぼ確実に数値として扱われます。先頭にゼロを持つビルド識別子は、何かがそれを整数として扱った瞬間にゼロを失います。それが問題になるなら、直すべきはファイルではなく、ファイルを読むアプリケーション側です。

出力にコメントは含まれません。JSON にはそもそも渡せるコメントがないからです。INI はコメントに対応しています。セミコロンかハッシュで始まる行です。この変換ツールは逆方向に読むときはどちらも尊重します。

設定を INI に移す目的はたいてい人がそれを編集することにあるので、コメント行はすぐに加える価値があります。どの値が環境ごとに違うか、どれが他の場所の値と一致していなければならないか、どのセクションをアプリケーションがまったく無視するか。それはまさに、生成された JSON ファイルには決して持てなかった情報です

これはこのブラウザーのタブの中で動く素の JavaScript です。ファイルはアップロードされず、アカウントも待ち行列もなく、無料枠は 100 MB まで受け付けます。どんな設定ファイルよりも桁違いに大きい容量です。

このペアにとって、プライバシーの話は飾りではありません。設定ファイルはデータベース接続文字列、API のエンドポイント、内部のホスト名、そして誰も認めたがらないほど頻繁に、環境変数にすべきだったパスワードを持っています。それをどこかのサーバーで変換することは、何の見返りもなく、それらすべてを第三者に渡すことになります。