XMLからCSVへ
このコンバーターは、ブラウザ内でXMLをRFC 4180形式のCSVにフラット化します。ルート要素の繰り返しの子要素が行に、その属性が@接頭辞付きの列になり、要素のテキストは文法要求がある場合にのみ引用符付きでCRLFで終わる名前付きの列に配置されます。アップロードは一切行われません。
XMLからCSVへとは
実際のテーブルのように振る舞うほとんどのXMLは、一つの形状を共有しています：多くの同名の子要素を持つコンテナ要素があり、各子要素が一つのレコード（書籍の目録、エントリーのログ、注文のリストなど）を表す。このコンバーターはまさにその形状を探します。ルートの繰り返しの子要素を見つければ、後は自動的に行います：各子要素が一行に、その属性と内部要素が列に、そして各行のすべての列の集合がヘッダーになり、最初に現れた順序で配置されます。
慣例は、すべてのXMLブリッジが使用するものと同じで、ここで明確にされています：属性は名前を保持して@接頭辞を付け、id="bk101"は@id列になります；要素のテキストは#text値になります；そして一つのレコード内で繰り返される子要素は、静的にマージされるのではなく、インデックス付きの列に展開されます。CSV側は厳密なRFC 4180です—CRLF行終端、フィールドにカンマ、引用符、または改行が含まれる場合にのみ二重引用符のエスケープ—そして値はそのまま渡され、郵便番号を再フォーマットするための数値強制は行いません。
すべてがこのブラウザタブ内で動作します。XMLはページ内エンジンで解析され、CSVは解析されたツリーから構築されます。どちらもネットワークに触れることはありません—DevToolsを開き、ネットワークパネルが静まっているのを見て、主張が正しいことを確認してください。
代わりにスプレッドシートのエクスポートからXMLを構築したい場合、CSVからXMLへコンバーターは同じ慣例を逆方向に適用します。
CSV側が保証するもの—引用符、CRLF、二重引用符—は、このサイトのRFC 4180ガイドで適切に説明されています。
変換の実際の動作方法
ドキュメントは一度ツリーにトークン化され、その後の表形式の読み取りは別個で、正直なステップです：ツリーには繰り返しの子要素の形状があるかどうかのみで、そうでないと偽ると、見た目は良いが意味が異なるCSVが生成されます。形状が見つかった場合、すべてのレコードはリーフパスにフラット化され、ヘッダー行はすべてのレコードにおけるそれらのパスの順序付きの和集合です—最初に現れたものが先なので、列順は偶然的にアルファベット順になるのではなく、安定して予測可能です。
- 解析：シングルパスのトークナイザーが要素ツリーを構築します。コメント、DOCTYPE、処理命令はスキップされ、2つ目のルート要素は行番号とともに拒否されます。
- 選択：ルートの最初の繰り返しの子要素が行を提供します—<catalog>が<book>の子要素で満たされているのが典型的なケースです。
- フラット化：属性は@列に、要素テキストは#textに、より深いネストはauthor.#textのようなドット付きパスになります。
- 出力：レコードごとにCRLFで終わる一行を、フィールドがカンマ、引用符、または改行で強制される場合にのみ引用符付きで出力します。
XMLの機能が列にマッピングされる方法
XMLには値を運ぶ3つの方法—属性、テキストコンテンツ、子要素—があり、フラットなグリッドには1つしかありません：名前付きの列。以下のマッピングは標準的なもので、ソースの2つの機能が出力で衝突しないように、そしてヘッダー自体が各列の値がどの種類から来たかを示すように選ばれています。
| XML構造 | 列 | 例のセル |
|---|---|---|
| 属性 id="bk101" | @id | bk101 |
| 要素テキスト <price>5.95</price> | price.#text | 5.95 |
| 属性とテキストを持つ要素 | @sku plus #text | A-1, Widget |
| 繰り返しの孫要素 | book[0].#text, book[1].#text | one, two |
値はそのまま渡されます
XMLツリーとCSVの間に型推論のステップは意図的にありません。XMLのテキストはテキストなので、44.95は文字の44.95として到着し、郵便番号は先頭のゼロを保持し、1e5のような値は100000に展開されません。エンティティも同じ方法で渡されます：パーサーは検証パーサーではなく、エンティティ参照を書き換えないので、セルに配置されるのはソーステキストに含まれていたものとまったく同じです。宛先が型付きの値を必要とする場合、このツールをCSVからSQLコンバーターと組み合わせてください。そのコンバーターは、その時点でセルから型を推論し、選択は可視化され、元に戻せます。
- 数値は正確な文字を保持します—精度が作られたり失われたりしません。
- テキストノード内の空白は保持されます。要素間の空白はデータにはなりません。
- 空要素（<debug/>）は消えるのではなく、空のセルを持つ列を生成します。
このコンバーターが推測を拒否する場合
2つの構造はコンバーターに情報を捏造を強制し、どちらも特定のメッセージで拒否されます。最初のものは繰り返しの子要素のないドキュメントです—表形式の何も含まない単一のルートは、行の形状を捏造しなければ行にできません。2つ目は複数のルート要素を持つドキュメントで、そもそも一つのドキュメントではありません。エラーは問題の2つ目の要素とその行を名指しし、何も書き出されません。ほとんど合致する断片でも断片であり、最速の修正方法は貼り付ける前にラッパー要素を削除または名前を変更することです。
- 繰り返しの子要素なし：期待される<root><item>…</item></root>形状を名指しするエラー。
- 複数のルート：拒否され、2つ目の要素とその行が報告されます。
- 不一致の終了タグ：ツリーがwell-formedでなくなる点で拒否されます。
よくある質問
XMLからCSVへの変換でファイルがどこかにアップロードされますか？
いいえ。XMLの解析とCSVの構築の両方、ページが開かれたときに一度読み込まれたJavaScriptを使って、このブラウザタブ内で行われます。データを送信するAPIルートはなく、ページのContent-Security-Policyはconnect-src 'self'に設定されているため、ブラウザ自体がアウトバウンド要求をブロックします。どちらの主張もDevToolsで確認できます：変換中にネットワークパネルを監視してください—リクエストは表示されません。
どのXML要素がCSVの行になりますか？
コンバーターはルート要素の子要素を見て、繰り返されるものを取ります—同じ名前の要素が多く現れるもの、例えば<catalog>内の<book>などです。各出現が一行になります。子要素が繰り返されない場合、オブジェクト形状の子要素はそれぞれ自身のレコードとして扱われ、表形式の何も含まないルートは、誤解を招く一行のファイルにフラット化されるのではなく、名前付きのエラーで拒否されます。
なぜ一部の列名は@で始まったり#textを含んだりしますか？
接頭辞は各値がXML内でどこにいたかを記録します。@接頭辞は属性を示します—id="bk101"は@id列になり—#textは要素自身のテキストを示します。要素が属性や子要素も持つ場合、それ自身の名前が必要です。接頭辞は衝突を防ぎます：idという名前の要素とidという名前の属性はさもなければ一つの列で争い、ヘッダーがどちらだったかを示すことができません。
数値に変換されるか、値は書かれたままですか？
値は書かれたままです。ツリーはテキストを文字列として保持し、CSVライターは型推論を行わないため、44.95は44.95として渡され、02134のような郵便番号は先頭のゼロを保持し、あなたの背後で何も再フォーマットされません。これはサイトのXMLからYAMLコンバーターも同じ方針で、どちらの方向に変換されたファイルも文字ごとに同じ値を示します。
出力の引用符付きフィールドと改行はどのように処理されますか？
RFC 4180に従います：カンマ、二重引用符、または改行を含むフィールドは二重引用符で囲まれ、そのようなフィールド内の引用符は二重化されます。行はCRLFで終わります—仕様で定義され、スプレッドシートソフトが期待する終端子です。フィールドは文法が要求する場合にのみ引用符付きです—装飾的な引用符はありません—これはファイルを小さくし、すべてを引用符付きでエクスポートするよりもdiffしやすくします。
XMLのコメントとDOCTYPE行はどうなりますか？
スキップされます。コメント、DOCTYPE宣言、処理命令は表形式のデータを運ばないので、ツリーには単に含まれません；解析は要素構造から続きます。コンバーターが一つだけ要求するのは単一のルート要素です—2つ目のトップレベル要素を持つドキュメントは、要素の名前と行番号とともに拒否されます。なぜなら2つのルートは2つのドキュメントであり、一つの行セットではないからです。