XMLからYAMLへ
このコンバータは、ブラウザ内でXML文書を読みやすいYAMLに変換します。属性は@を接頭辞としたキーになり、要素のテキストは属性や子要素と共存する場合に#textになり、繰り返される兄弟要素はYAMLのシーケンスになります。値は文字列のままなので、郵便番号はそのまま保持され、何もアップロードされません。
XMLからYAMLへとは
XMLは属性、テキスト内容、子要素の3箇所で値を持ち、YAMLは3つすべてを1つのマッピングに収めることができますが、それぞれが衝突しない名前を持つ必要があります。これがこのコンバータが適用する規則全体です：id="bk101"は"@id"というキーになり、要素内のテキストは独自の場所が必要な場合に"#text"になり、子要素は値がマッピングやリストになるキーになります。接頭辞は、要素が属性、子要素、テキストを同時に持つまでノイズのように見えます――その時点で、それらが双方向変換で情報が失われない理由になります。
YAMLのスタイルはサイトの標準スタイルです：2スペースのインデント、シーケンスのダッシュは親キーに揃え、下に詰めず、平文が誤って読み取られそうな箇所のみ引用符を使用します。最後のルールはここで実際に役立ちます。XMLテキストは型付けされていないので、44.95は文字列であり、エミッタはそれを"44.95"と書き出すことで、YAMLパーサーがそれを数値として再推論しないようにします。結果として、双方向変換可能なドキュメントが生成されます：XMLからYAMLに、そして戻すと、同じ値、同じ属性、同じ構造で到着します。
すべてがこのブラウザのタブ内で動作します。XMLはページ内エンジンで解析され、YAMLは解析されたツリーから出力されます。どちらもネットワークに触れることはありません――DevToolsを開き、ネットワークパネルが沈黙しているのを確認すれば、その主張自体が検証されます。
結果を逆方向に送り返すには、YAMLからXMLコンバータ同じ@と#textの規則を尊重するため、手動での名前変更は不要です。
YAMLの出力を読むのが初めてですか？YAML基本ガイドは、インデント、引用符、エミッタが従うスカラーのルールを説明しています。
変換が実際にどのように機能するか
ドキュメントは一度、要素、属性、テキストのツリーにトークン化され、YAMLエミッタはそのツリーしか見ません――したがって、ソースの書式の癖（不揃いのインデント、行をまたがる属性など）が出力に漏れ出すことはありません。ツリーは単一ルートを持つ1つのドキュメントに適合するか、そうでないかのどちらかで、コンバータはそのどちらであるかを示します。
- 解析：単一パスのトークナイザーが要素、属性、テキスト、コメント、CDATAを読み取り、不一致または閉じられていないタグは行番号と共に拒否されます。
- 変換：各要素がマッピングになり――属性は"@key"エントリ、テキストは"#text"、子要素はネストされたキーになります。
- 収集：繰り返される兄弟要素は1つのリストに収集され、<book>が10回出現すると10項目のシーケンスになります。
- 出力：ツリーは2スペースのインデントでYAMLとしてシリアル化され、値が誤って読み取られそうな箇所のみ引用符が使用されます。
XMLの機能がYAMLでどのように扱われるか
ソースドキュメントのすべての機能は出力に予約席があり、その席は2つの機能が1つのキーで競合しないように選ばれています。表は実際のドキュメントに現れる形状のマッピングを示しています――属性を持つ要素、子要素を持つ要素、繰り返される要素。
| XMLの構造 | 生成されるYAML |
|---|---|
| <book id="bk101"> | "@id": bk101を持つbookマッピング |
| <price>44.95</price> | "#text": "44.95"を持つprice |
| 10個の<book>兄弟要素 | 値が10項目のリストであるbookキー |
| <debug/>（空要素） | 存在が明示された空のマッピング: {} |
#textが存在する理由とその出現条件
内容がテキストのみの要素――<price>44.95</price>――は、単純なマッピングprice: 44.95になる可能性があり、属性も子要素もない要素については、実際に読める形式になります。しかし、要素が属性や子要素も持つ瞬間、そのテキストは属性名や子要素名が決して占有できないキーを必要とします。#textがそのキーです。テキストが何かと要素を共有する必要がある場合にのみ出現するため、通常の出力はクリーンなまま複雑な出力は明確になります。
- テキストのみの要素は、その内容を1行で読みやすく保ちます。
- 混合要素――属性とテキスト、または子要素とテキスト――はテキストを"#text"の下に移動します。
- ソーステキスト内のエンティティはそのまま保持されます。パーサーは検証パーザーではなく、エンティティを書き換えません。
値、型、双方向変換保証
XMLテキストは文字列であり、エミッタはそれをそのように扱います：何も数値やブール値に強制変換されることはありません。見える結果は引用符です――44.95は"44.95"と書き出されますなぜなら、引用符なしの44.95はYAMLで数値として再読み取りされ、02134のような郵便番号は先頭のゼロを同じように失うからです。bk101のように何か他のものと間違われることがない値は、平文で出力されます。サイトのYAMLからXMLコンバータで結果を変換し直すと、取得するドキュメントは開始したドキュメントと同じになります：重要な箇所ではバイト単位で、名前、属性、テキスト、構造が同じです。
- 型推論なし：テキストはテキストとして渡され、精度と先頭のゼロが保持されます。
- 数値に見える文字列は出力時に引用符で囲まれ、これが双方向変換で情報が失われない理由です。
- テキストノード内のホワイトスペースは保持されます。要素間のホワイトスペースはデータになりません。
よくある質問
XMLからYAMLへの変換で、ドキュメントがどこかにアップロードされますか？
いいえ。解析とYAML生成の両方が、ページ読み込み時に一度ロードされたコードを使用してこのブラウザタブ内で実行されます。アップロードエンドポイントはなく、ページはconnect-srcが'self'であるContent-Security-Policyで配信されるため、ブラウザはコードに関係なく送信要求を拒否します。変換中にDevToolsのネットワークパネルを確認してください――沈默しており、それがこの約束の検証可能なバージョンです。
出力の@と#textの接頭辞は何を意味しますか？
それらは各値がXMLのどこから来たかを記録します。"@id"のようなキーは属性を保持します――ソースのid="bk101"――そして"#text"は、要素が属性や子要素も持つ場合にその要素自身のテキストを保持します。接頭辞は衝突を保証します：priceという名前の属性とpriceという名前の子要素が同じキーにマッピングされることはなく、YAMLリーダーは常にど種類の値を見ているかを判断できます。
繰り返される要素はどのように処理されますか？
同じ名前を持つ兄弟要素は1つのYAMLシーケンスに収集されます：10個の<book>子要素は、ドキュメント順で10項目のリストを値とする単一のbookキーになります。一度だけ現れる要素は平文のマッピングのままです。これは標準のXMLからデータへの規則であり、これが出力をコードで反復処理しやすくする理由です――各リスト項目は1つのレコードであり、属性と子要素がその内側に折りたたまれています。
なぜYAMLの出力で44.95は引用符で囲まれていますか？
XMLテキストは型付けされていないため、値は文字列44.95です――そしてYAMLでの引用符なしの44.95は、下流のすべてのパーザーで数値として再読み取りされます。数値に見える文字列を引用符で囲むのは、ソースが実際に言ったことを保持するエミッタの方法であり、02134のような郵便番号が先頭のゼロを失わないのを同じルールが守ります。bk101のように誤って読み取られる可能性のない値は、引用符なしで出力されます。
XMLドキュメントのどの部分が無視されますか？
要素データを運ばないため、コメント、DOCTYPE宣言、処理命令はスキップされます。すべての構造的なものは保持されます：要素、属性、テキスト、CDATAセクションです。コンバータは単一のルート要素を必要とします――2つのトップレベル要素があるペーストは、2番目の要素の名前と行番号で拒否されます。なぜなら2つのルートは2つのドキュメントであり、それらを静かにマージすると、元に存在しない構造を捏造することになるからです。
<debug/>のような空要素はどうなりますか？
空要素は明示的な空のマッピング――debug: {}――になり、消えません。これによりキーが保持され、消費者はそのフィールドがドキュメントにあったことを依然として判断できます。別々の開始タグと終了タグで書かれ、内容がない要素<note></note>も同じ場所に配置されます：構造は要素が存在したことを示し、内容だけが空だったことを示します。それを埋めるために何も捏造されません。