YAML・JSON・TOML・XMLを変換する — 任意の形式、ブラウザ内で

設定ファイルはよく4つの形式で届きます — JSON、YAML、TOML、XML — そして、始めた形式のまま留まることはまれです。KubernetesのマニフェストはYAMLで届き、RustプロジェクトはTOMLを同梱し、APIはJSONを返し、レガシーシステムはまだXMLを話します。データ形式コンバーターを開けば、1バイトもアップロードせずにどれの間でも移動できます。

TL;DR

入力と出力を選び、データを貼り付け、変換して、コピー。

任意から任意へ — JSON、YAML、TOML、XMLを互いに変換します。すべてブラウザ内で。
損失の警告を先に — XML属性や混在テキストが正確に往復しないとき、警告パネルが出力を信頼する前に知らせます。
コピーまたは保存 — 結果をクリップボードに取得するか、出力形式の拡張子でローカルに保存します。

なぜ形式変換が重要なのか

これらの形式はどれも同じもの — キーと値の構造化データ — を表しますが、異なる目的のために作られ、各エコシステムは最も合うものを採用します。摩擦が表れるのはデータが境界を越える瞬間です。CIパイプラインはYAMLを読むが呼び出すツールはJSONを欲しがる、PythonプロジェクトのTOML設定をJSONを話すスクリプトが編集する必要がある、APIはJSONを返すが消費側のサービスはXMLを期待する、といった具合です。

正直なところ、形式は完全に交換可能ではありません（詳しくは制限の節で）。しかし設定ファイルの大半 — フラットまたは浅くネストされた設定、リスト、型付きスカラー — では、綺麗な変換がまさに必要なものです。ツールの仕事は、その変換を速く透明に行い、可逆でないときに警告することです。

4つの形式

それぞれの形式には性格があり、いつ使われるかを知れば正しい出力を選ぶ助けになります。

JSON — 厳格で遍在し、APIとpackage.jsonの既定値。二重引用符の文字列、末尾カンマなし、コメントなしを要求します。どのパーサーも同意します。
YAML — 人間に優しく、インデントで駆動。Kubernetes、CI設定、人が手で編集するあらゆるものを支えます。空白が意味を持つことが長所でもあり罠でもあります。
TOML — 型付き、テーブルベース、設定ファイルのために設計。RustのCargo.toml、Pythonのpyproject.toml、同様のツールの選択肢です。INIより明確で、YAMLより厳格です。
XML — 冗長で、属性と名前空間が多い。エンタープライズシステム、SOAP API、古いドキュメントストアに今も現れるレガシー形式です。

手順：形式間で変換する

データ形式コンバーターは完全にブラウザ内で動きます。手順は次のとおりです。

入力形式と出力形式を選びます。 2つの独立したドロップダウンで、何から何へ変換するかを選びます。入れ替えを使えば瞬時に反転できます — JSONからYAMLにした直後に逆が必要なときに便利です。
入力を貼り付けます。 入力欄に入れます。形式が分からなければ、ツールが提案できます — 貼り付けた内容に基づいて、入力の横に**「検出」**ヒントが表示されます。
オプションを設定します。 3つのコントロールが出力を形作ります。
- インデント（0〜8） — 結果のインデント幅（JSON圧縮時は無視）。
- JSONを圧縮 — 出力がJSONのとき空白をすべて削除し、最小のペイロードにします。
- XML属性プレフィックス — XML属性を表すキーの前に付ける文字列（既定@、最大4文字）。
変換をクリックします。 出力欄に結果が表示され、概要（形式間の変換と最上位の項目数）と、損失のあるものを示す警告パネルが併せて表示されます。
コピーまたは保存します。 結果をコピーでクリップボードへ、ダウンロードで出力形式の拡張子のファイルを保存します。クリアでリセットします。

損失のある変換と警告

一部の変換は完璧にできず、ツールはそれを率直に伝えます。警告パネルが各ケースを列挙し、どこを見ればよいか正確に分かります。

XML属性 — <user id="7">のような属性は、接頭辞付きキー（既定@id）の下に格納されます。JSONやYAMLへの変換は保持しますが、XMLに戻す変換は属性と子要素を区別するために接頭辞に依存し、境界ケースでは損失が生じ得ます。
XMLの混在テキスト — 要素がテキストと子要素の両方を持つとき、テキストは#textキーの下に格納されます。元の混在構造はJSONやYAMLで表現できないため、往復は不完全です。
XML名 — 要素と属性の名前は有効なXML名に正規化されるため、キーの変わった文字は置き換えられます。
TOMLのネスト — 深くネストされたオブジェクトはTOML出力のためにフラット化され、手動確認が必要な場合があります。

警告パネルが空なら、変換は綺麗に往復します。空でなければ、各警告を読み、影響する部分が自分にとって重要かを判断します。フラットな設定ファイルでは通常、警告は一切出ません。

制限と正直なところ

あなたが何を得るか正確に分かるよう、いくつか正直な制約を示します。

YAMLとTOMLのパーサーは独自実装のサブセットです。 一般的なケース — ネストしたマッピング、リスト、スカラー、引用符付き文字列、数値、真偽値、null — を扱いますが、完全なYAMLやTOML仕様のライブラリではありません。複雑または境界ケースの構造（YAMLのアンカーとエイリアス、複数行文字列、TOMLのテーブル配列、日付と時刻）は、専用ライブラリと同じようには解析・シリアライズされない場合があります。
JSONとXMLは堅牢です。 JSONはJSON.parseを通るため、任意の有効なJSONが正確に解析されます。XMLは属性、ネスト、エンティティを扱う専用パーサーを使います。
往復は保証されません。 上の損失ケース（XML属性、混在テキスト、TOMLネスト）は出力形式で常に表現できるとは限らないため、A → B → AがAを正確に再現するとは限りません。原本は保管してください。

よくある質問

変換は可逆（ロスレス）ですか？

フラットまたは浅くネストした設定ファイルでは、はい — 通常、警告パネルは空です。XML属性、XMLの混在テキスト、TOMLの深いネストを使うデータでは変換に損失があり得て、警告パネルが各影響部分を示します。警告はその節を見直すための合図と考えてください。

YAMLをJSONに変換できますか？

はい。入力形式をYAML、出力形式をJSONに設定し（または検出ヒントを使い）、YAMLを貼り付けて変換をクリックします。出力は有効なJSONで、インデントはインデントオプションで制御し、圧縮も選択できます。

なぜXMLの往復結果が変わるのですか？

2つの理由があります。XML属性は接頭辞付きキー（@idなど）にマッピングされるため、戻すときに子要素と区別するにはその接頭辞に依存します。そして混在コンテンツ — テキストと子要素の両方を持つ要素 — は#textの下に格納され、混在XMLへは綺麗に戻せません。警告パネルが両方のケースを報告します。往復の忠実さが重要なら、XMLの原本を保管してください。

JSONのコメントに対応していますか？

いいえ。JSONの仕様にコメントはなく、パーサーはそれを無効な入力として扱います。入力にコメントがあれば変換前に削除するか、コメントを扱える形式（YAMLとTOMLはどちらも対応）を使ってください。