JSONからTOMLへ
このコンバーターは、ブラウザ内でJSONから完全にTOML 1.0を出力します。スカラーキーが最初に書かれ、その後[テーブル]、そして[[テーブルの配列]]の順になるため、すべての定義はそれが属するヘッダーの前に記述されます。TOMLとの互換性のないキーはフラグされ、nullは名前付きパスで拒否され、トップレベルの配列は変換できません――TOMLには匿名のルートがありません。
JSONからTOMLへとは
方向性が重要です：JSONは通常、プログラム内で生成されます――APIペイロード、保存されたドキュメント、ビルドツールの状態――一方、TOMLは通常、何かを設定する人間が読み取ります。したがって、JSONをTOMLに変換することは、実際の配置ルールを持つ形式に再入力することを意味し、最大のルールは噛みつくまで見えません：TOMLでは、キーがファイル内での位置が、そのキーがどのテーブルに属するかを決定します。[servers]ヘッダーの後にretries = 3と書くと、それは黙ってルートのキーではなくserversのキーになります。
このコンバーターは、スカラーキーを最初に、次に[テーブル]、最後に[[テーブルの配列]]の順に出力するため、すべてのキー/値ペアが属するヘッダーの下に書かれ、すべてのテーブルが次のヘッダーが開く前に完全に定義されます。JSONオブジェクトはテーブルになり、オブジェクトの配列はテーブルの配列になり、スカラーの配列はインライン配列のままです。すべての値は、すでに存在するTOML 1.0の型として出力されます――推論ステップはなく、誤る余地もありません。
すべてはこのブラウザのタブ内で行われます。貼り付けたJSONはブラウザのJSON.parseで解析され、そのドキュメントからメモリ内でTOMLが構築され、ネットワークを越えるものは一切ありません――作業中はDevToolsのネットワークパネルは空のままです。ページのContent-Security-Policyがその状態を維持します。
逆の変換はより一般的です――スクリプトでCargo.tomlを読み込むこと――そのTOMLをJSONに変換するページはそれを処理し、日時を文字列のまま、まさにこのコンバーターが受け取るように保持します。
JSONがフォーマッターではなくスクリプトから来た場合、まずJSON検証ツールで実行してください――そこで解析に失敗したドキュメントは、同じメッセージでここでも失敗します。
なぜスカラー、テーブル、配列の順に出力されるのか
TOMLの配置ルールが、出力がその順序になる理由です。[テーブル]ヘッダーの後に書かれたキーはそのテーブルに属し、[[テーブルの配列]]ヘッダーの後に書かれたキーはその最新のエントリに属します――したがって、スカラーとヘッダーを混在させる出力は、ファイルが正しい構造ではなくても解析を成功させ、誤った構造に変換してしまいます。あるレベルのキー/値ペアを最初に出力し、次にそのサブテーブル、次にそのテーブルの配列を出力する順序は、ラウンドトリップが可能な唯一の順序です。このルールは、すべてのネストされたテーブル内でも再帰的に適用されます。
文字列には独自のルールが1つあります：すべてがTOMLの基本文字列として二重引用符で出力され、バックスラッシュ、引用符、制御文字はTOML 1.0で定義されるようにエスケープされます。コンバーターは、句読点を節約するためにリテラル文字列に切り替えません。なぜなら、バックスラッシュがリテラルであるかを判断することは、コンバーターがすべき推測だからです。キーも同じルールに従い、port: 8080のようなキーは引用符付きで曖昧さなく到達します。
JSONからTOMLへのマッピング
コンバーターが扱すべての形式と、そのTOML 1.0の出力先：
| JSON | TOML出力 |
|---|---|
| オブジェクト | [テーブル]ヘッダー、その下のキー |
| オブジェクトの配列 | [[テーブルの配列]]エントリ、オブジェクトごとに1つ |
| スカラーの配列 | インライン配列: ["fast", "safe"] |
| 文字列 | 標準的なエスケープを持つ基本文字列 |
| ドットやスペースを含むキー | 引用符付きキー: "app.name" = 1 |
| null | 拒否されます――TOML 1.0にはnullがありません |
出力の見た目
以下の作業例は、コンバーターの「サンプルを読み込む」ボタンが生成する正確なペアです：2つのスカラーとインラインのtags配列を持つルートオブジェクト、1つのネストされたownerオブジェクト、そして2つのオブジェクトを保持するservers配列です。順序に注目してください――ルートのプレーンなキー/値ペア（tagsを含む）はすべて[owner]の前に出現し、両方のserversエントリは配列順で1つの[[servers]]ヘッダーファミリの下に配置されます。この順序は見た目のためではありません。ファイルが同じ構造に解析されるようにするためだからです。
このファミリー全体と同じように、出力は解析されたドキュメントから生成されるため、ソースJSONのインデントの癖は意味とキーの順序で保持されますが、レビューアがdiffできるように、一貫したTOMLスタイルで再印刷されます。
このコンバーターが不正に変換せず、拒否する境界ケース
入力には、忠実なTOML 1.0の表現が存在しないものがあり、そうでないふりをすると、嘘をつく設定ファイルを渡してしまうことになります：
- トップレベルの配列またはスカラー――TOMLドキュメントは常にキー/値ペアのルートテーブルであるため、トップレベルがオブジェクトでないJSONファイルは、明確なメッセージで拒否されます。
- 任意の場所にあるnull――TOML 1.0にはnullがないため、コンバーターは拒否し、正確なパスを名指しで示し、キーを削除するか値を意図的に選ぶのはあなたの判断に任せます。
- ドットのような見えるキー――a.bという裸のキーはドット付きキーとして解析され、ネストされたテーブルに配置されるため、そのようなキーは引用符付きの基本文字列として出力され、プレビューでフラグされるので、おそらくネストを意図していた名前を見つけられます。
よくある質問
変換中にJSONはサーバーに送信されますか？
いいえ。変換はこのブラウザタブ内で完全に実行されます：JSON.parseとTOMLライターは、ページが開かれた時に一度だけ読み込まれるページローカルのJavaScriptです。アップロードエンドポイントはなく、Content-Security-Policyがページが接続を開くことを禁止します。DevToolsがそれを証明します――いくつ変換しようと、ネットワークパネルは空のままです。
なぜスカラーは[テーブル]ヘッダーの前に書かれる必要があるのですか？
TOMLでは、[servers]ヘッダーの後のすべてのキーはserversに属するため、スカラーとヘッダーを混在させると、ファイルがクリーンに解析される間に意味が変わってしまいます。あるレベルのキー/値ペアを最初に書き、次にそのサブテーブルとテーブルの配列を書く順序は、開始した構造に解析し返す唯一の順序です――それはスタイルではなく、正確性です。
JSONのnullはどうなりますか？
拒否されます。TOML 1.0にはnull値がありません――言語はそのための表記法を提供しない――したがって、忠実な出力は存在しません。コンバーターはowner.middleのような問題のあるキーの正確なパスを報告し、停止します。キーを削除するか、センチネル文字列に置き換えるのは、出力に組み込まれた静かな推測ではなく、あなたの判断です。
配列はどう変換されますか？
内容によってです。すべての要素がオブジェクトである配列は、オブジェクトごとに1つのエントリを持つ[[テーブルの配列]]になります。スカラーまたは混合値の配列は、1行のTOMLインライン配列になり、空の配列は[]として出力されます。フラット化または再形成されることはありません――コンバーターは与えられた構造をそのまま出力し、それが結果を予測可能にします。
ドット、スペース、コロンを含むキーはどうなりますか？
TOMLの裸のキーは文字、数字、アンダースコア、ハイフンのみを許可するため、それ以外は引用符付きキーでなければなりません。このコンバーターはそのようなキーを基本文字列として出力します――"app.name" = 1――これはTOML 1.0ではドット付きパスではなく単一のキーとして定義されます。引用符付きキーはフラグされるので、おそらくネストを意図していた名前を確認し、手動で名前を変更できます。
JSON文字列から本当のTOMLの日時を取得できますか？
変換ではできませんし、誠実にそうです。JSONには日付型がないため、コンバーターは"1979-05-27T07:32:00Z"がタイムスタンプであるか、偶然そのように見える文章であるかを知ることはできません。すべての文字列は引用符付きの基本文字列として出力されます。裸のTOML日時が必要な場合は、出力から引用符を手動で削除してください――テキストはすでに有効なRFC 3339です。