YAMLからXMLへ
このコンバータは、お使いのブラウザ内でYAMLのマッピングとシーケンスをXMLに変換します。マッピングはネストされた要素に、シーケンスは繰り返し要素に、スカラ値はテキストコンテンツになります。キーは合法的なタグ名にサニタイズされ、XML 1.0に従ってテキストがエスケープされます。@で始まるキーは属性になります。何もアップロードされません。
YAMLからXMLへとは
YAMLとXMLの両方で木構造を表現できるため、変換は主に語彙の違いです：マッピングは子要素を持つ要素に、シーケンスは繰り返される要素に、スカラはテキストコンテンツになります。YAMLが表現できない唯一のものはルート要素名です――XMLドキュメントは正確に1つ必要です――そのため、コンバータは<root>をドキュメント要素として提供し、あなたのドキュメントをその中にネストします。トップレベルのリストは、各アイテムごとに繰り返し要素を1つ持つ<root>になります。トップレベルのマッピングは、キーを1つ下のレベルで要素名として保持します。
この取引の厳格な側面はXMLの名前ルールであり、コンバータはそれらを推測するのではなく強制します：すべてのキーが合法的なタグ名になり、許可されていない文字セットの外側の文字はアンダースコアに置換され、名前が数字で始まる場合は先頭にアンダースコアが追加されます。テキストは出力時にXML 1.0に従ってエスケープされます――コンテンツの&、<、>、および属性値内の二重引用符――そのため、どの標準準拠のパーサーでも結果を読み取ることができます。値はそのままの文字としてクロスオーバーします。ポート番号やバージョン文字列を推測する数値強制ステップはありません。
すべてがこのブラウザのタブ内で動作します。YAMLはページ内エンジンで解析され、XMLは解析されたドキュメントからシリアライズされます。ネットワークに触れるものは何もありません――DevToolsを開き、ネットワークパネルが静まっているのを確認し、プライバシーの主張が自己検証されます。
ラウンドトリップを確認するには1つの貼り付けで十分です。なぜなら、XMLからYAMLへのコンバータが@と#textの規約を逆方向にも読み込むからです。
入力側が不安定な部分――インデント、引用符、型推論――であれば、YAML基本ガイドがこのパーサーが期待するルールを説明しています。
変換の実際の仕組み
ドキュメントは一度だけプレーンデータに解析され、XMLライターはそのデータだけを見ます――元のテキストを見ることはありません。その分離が以下のルールを予測可能にするものです：ライターはYAML構文に驚かされることはなく、パーサーはXMLの外観によって影響を受けることはありません。各段階には1つの仕事と1つの出力があります。
- 解析：YAMLがマッピング、シーケンス、スカラとして読み込まれます――日々の核心部分で、コメントは許可され、アンカーまたはエイリアスはサポート外です。
- ラップ：ドキュメントは単一の<root>要素内に配置されます。なぜならXMLは正確に1つのルートを必要とし、YAMLにはそのための名前がないからです。
- レンダリング：マッピングは子要素としてネストされ、シーケンスは繰り返し要素になり、スカラ値はそのキーで名付けられた要素のテキストコンテンツになります。
- エスケープとインデント：テキストは3つの必須XMLエスケープを受け、属性は追加で引用符をエスケープし、ドキュメントはレベルごとに2スペースで整形されます。
タグ名ポリシーの詳細
XML 1.0の名前は、文字、アンダースコア、コロンで始まり、数字、ハイフン、ドット、コロンを含むことができます。それ以外は使用できません。YAMLのキーはそれより自由であるため、すべてのキーがチェックされ修復されます：スペースはアンダースコアになり、先頭の数字は先頭にアンダースコアが付き、既に合法だったキー――content-typeのようなケバブケースを含む――はそのまま通過します。特に、ドットはXML名内の合法的な文字であるため、address.cityのようなキーはここではaddress.cityという名前の単一の要素になり、ネストされたペアになりません。ネストはキーの句読点ではなく、YAML構造自体によって表現されます。
| YAMLキー | 出力される要素 | 理由 |
|---|---|---|
| role | <role> | 既に合法――そのまま通過 |
| first name | <first_name> | スペースがアンダースコアに置換 |
| 2fa | <_2fa> | 名前は数字で始めることはできない |
| content-type | <content-type> | ハイフンはXML名で合法 |
属性、テキストと@の規約
YAMLにはマッピングがあり、XMLには属性があります。その橋渡しは、サイトのXMLからYAMLへのコンバータが逆方向に使用するのと同じ規約です：@で始まるキーはその要素の属性になり、特別な#textキーは要素が属性または子要素も持つ場合に要素自身のテキストを保持します。{"@id": bk101, "#text": A guide}という形式で記述されたレコードは、bookキーの下にある場合<book id="bk101">A guide</book>として出力されます。この規約は任意です――プレーンなキーと値には必要ありません――しかし、それは2番目の構文なしにプレーンなYAMLデータからXMLの全表面にアクセスできることを意味します。
- @sku: A-1は、囲み要素の属性sku="A-1"になります。
- #textは要素自身のテキストを保持するため、属性とコンテンツは衝突せずに共存できます。
- null値は完全に省略されます。空文字列は自己終了要素になるため、両者はYAMLでは異なり、出力もその違いを尊重します。
- 数値とブール値は文字列化されます――8080はテキストの8080として、trueはテキストのtrueとして到達します。
コンバータが隠蔽しない境界線
3つの入力は、肩すかしではなく、名前付きエラーまたは明示的な文書化された動作になります。このコンバータのパーサーが意図的にサポートしないYAML機能――アンカーとエイリアス、マージキー、ディレクティブ――は、半実装ではなくエラーで拒否されます。なぜなら、アンカー展開を推測するコンバータはコンテンツを捏造するからです。マルチドキュメントストリームは最後のドキュメントを使用して変換され、ここで文書化されます。偶然発見されるのを防ぎます。そして、スカラだけのドキュメントも依然として変換されます：それは<root>内のテキストになります。
- アンカー、エイリアス、マージキー：名前付きエラーで拒否され、推測によって展開されません。
- マルチドキュメントストリーム：最後のドキュメントが優先され、その動作は偶然発見されるのではなくここで文書化されます。
- インデントに使用されたタブ：YAML自身のルールに従い、解析時に拒否されます。
よくある質問
YAMLをXMLに変換する際、ファイルはどこにアップロードされますか？
いいえ。解析とXML生成の両方が、ページが開かれたときに一度読み込まれたJavaScriptを使用してこのブラウザタブ内で実行されます。データを送信するAPIルートはなく、ページのContent-Security-Policyはconnect-src 'self'に設定されているため、ブラウザ自体は送信要求を拒否します。両方の主張をDevToolsで確認できます：変換時にネットワークパネルには要求が表示されません。
なぜ私のXMLは<root>要素で囲まれていますか？
XMLは正確に1つのルート要素を必要とし、YAMLにはその名前がありません――YAMLファイルは単なるデータです。そのため、コンバータは<root>をドキュメント要素として提供します：トップレベルのシーケンスは、各アイテムごとに繰り返し要素を1つ持つ<root>になり、トップレベルのマッピングはキーを1つ下のレベルで子要素として保持します。異なるルート名が必要な場合は、YAMLでそのキーの下にデータを配置すると、その名前の要素になります。
YAMLキーはどのように合法的なXMLタグ名に変換されますか？
各キーはXML 1.0の名前ルールに対してチェックされ、失敗した場合のみサニタイズされます：文字、数字、アンダースコア、ハイフン、ドット、コロン以外の文字はアンダースコアになり、数字で始まる名前には先頭にアンダースコアが追加されます。既に合法だったキーはそのまま通過します。ドットはXML名内で合法であるため、address.cityはその名前の単一の要素になります――ネストはキーのドットではなく、YAML構造から来ます。
YAMLはXML属性とテキストコンテンツを生成できますか？
はい、@の規約を介して可能です：@で始まるキーはその要素の属性になり、予約済みの#textキーは要素自身のテキストを持ちます。bookキーの下に"@id": bk101と書くと<book id="bk101">が生成され、"#text": A guideを追加するとその中にテキストが配置されます。これはサイトのXMLからYAMLへのコンバータが出力するのと同じ規約であるため、ドキュメントは手動での名前変更なしに両方向でフォーマットを横断できます。
数値、ブール値、空の値はコンバータでどう扱われますか？
スカラは文字列化されます。なぜならXMLテキストには型がないからです：8080はテキストの8080に、trueはテキストのtrueになり、フォーマットの変更はありません。null値は要素を全く生成せず、空文字列は自己終了要素になります――YAMLが行う区別は出力で保持されます。テキストは出力時にエスケープされます（&、<、>、属性内の"）、そのためパーサーは書いたとおりの文字を正確に読み取ります。
パーサーはどのYAML機能をサポートしますか？
日々の核心部分：マッピング、シーケンス、プレーンと引用されたスカラ、コメント、および通常のスカラ型です。アンカーとエイリアス、マージキー、ディレクティブはサポート外であり、推測されるのではなく名前付きエラーで拒否されます――静的なアンカー展開は、ファイルになかったコンテンツを捏造します。マルチドキュメントストリームの場合、最後のドキュメントが変換されるものです。これは偶然発見されるのではなくページで文書化されます。