無料 XML → CSV コンバーター

XMLからCSVへの変換がよく必要になる理由

XMLは冗長で階層的だが、CSVは平坦で密度が高い。sitemap.xml、RSS / Atomフィード、WordPressのエクスポートファイル、Appleのplist設定、Mavenのpom.xml依存関係リスト、GPSトラック（GPX）、Google Earth地点（KML）、銀行明細フォーマット（CAMT.053、XML形式のMT940）、ECサイトの商品フィード、医療HL7 v3、XBRLの財務レポート、MusicXMLの楽譜など、多くの有用な実データがXMLに存在しており、行に平坦化するまでほぼ分析できない。Excel、Google Sheets、SQLのLOAD DATA、Pandas、R、Tableau、Power BIはすべてCSVをそのまま読み込める。これらのツールにXMLを取り込むにはまず変換が必要だ。

根本的な不一致

XMLは任意のネストを許可しているが、CSVは二次元だ。汎用的なロスレスのXML→CSV変換は存在しない。どのコンバーターも、ツリーのどのレベルが「行」を表すか、深いネストをどう扱うかについて仮定を置く必要がある。よくある形状は2つある：

• 繰り返しレコード形式（簡単なケース）。同じ形状の多くの子要素を含むルート要素。<catalog><book>…</book><book>…</book></catalog>。各<book>が行になり、そのリーフ要素が列になる。これがコンバーターが探してきれいに処理できる形式だ。
• 混合コンテンツドキュメント形式。XHTMLやDocBookのような、マークアップが埋め込まれた流れるようなテキスト。これにはきれいなCSVマッピングがなく、通常は単一の文字列セルとしてシリアライズされるか拒否される。

ツールはルートの最も頻繁な直接の子要素を見つけることで繰り返し要素を自動検出する。これは実際のXMLフィードの約90%で正しく動作する。XMLがそのパターンに合わない場合は、まず簡単なXPathスクリプトで前処理するか、繰り返しレコード形式に手動で編集する。

変換がうまくいくよくあるXMLフィード

• sitemap.xml：すべての<url>エントリがloc、lastmod、changefreq、priority列を持つ行になる。SEO監査やコンテンツ目録に役立つ。
• RSS / Atomフィード：各<item>または<entry>が行になる。コンテンツマーケティング分析や別のプラットフォームへの移行に役立つ。
• WordPressエクスポートXML（WXR）：投稿、ページ、添付ファイルの<item>タグ。Substack、Ghost、または静的サイトジェネレーターに移行する際によく使われる。
• GPX（GPS交換フォーマット）：<trkpt>トラックポイント（lat、lon、ele、time）が行になる。ルート分析に役立つ。
• KML（Google Earth）：名前、説明、座標を持つ<Placemark>エントリ。
• iTunes / Apple plist XML：繰り返しレコード形式のプレイリストエントリやアプリメタデータ。
• OFX / QFX / CAMT銀行明細XML：トランザクションが会計ソフト取り込み用の行になる。
• 商品カタログフィード：多くのECプラットフォームはCSE送信用の<product>繰り返し要素を持つXMLフィードを提供する。

属性、ネスト、繰り返し子要素の処理方法

• 属性（<book id="42">など）は列に平坦化される。コンバーターは曖昧でない場合、属性名を直接列ヘッダー（id）として使用する。
• ネストされた要素はドット記法で平坦化される：<person><address><street>Main</street><city>NYC</city></address></person>は列address.streetとaddress.cityを生成する。これはPandasのjson_normalizeがネストされたJSONに使用するのと同じ規則だ。
• 繰り返し子要素（<tags><tag>a</tag><tag>b</tag></tags>など）は問題になりうる：明確な平坦表現がない。タグごとの列やタグごとの行の出力が必要な場合は前処理すること。
• 5つの定義済みエンティティ参照（&、<、>、'、"）は変換中にアンエスケープされる。XMLのTom & JerryはCSVセルではTom & Jerryになる。
• CDATAセクションはアンラップされ、内容がそのままセル値になる。
• コメントと処理命令は削除される。CSVに相当するものがない。

エンコーディング：Excelの罠

XMLはエンコーディングを<?xml version="1.0" encoding="UTF-8"?>で宣言する。CSVにはエンコーディング宣言がないため、読み込む側が推測する。WindowsのExcelはデフォルトでWindows-1252を使用するため、Byte Order Mark（BOM）なしでUTF-8のCSVを開くと文字化けが発生する（「é」が「é」に、「ü」が「ü」に化ける）。修正方法：CSVの先頭にUTF-8 BOM（）を付けて保存するか、ExcelのデータメニューのData → From Text/CSVインポートウィザードを使ってUTF-8を明示的に選択するか、UTF-8をBOMなしで正しく扱うGoogle Sheetsでファイルを開く。

区切り文字の選択

RFC 4180によると、標準的なCSV区切り文字はカンマだ。このツールはセミコロン、タブ、パイプもサポートしている。用途に合ったものを選ぶ：

• カンマ：デフォルト。OSのリージョン設定が英語の場合にExcelで読み取れる。ほとんどの用途で安全。
• セミコロン：カンマが小数点区切り文字として使われる欧州大陸やラテンアメリカで好まれる。ExcelはOSのリスト区切り文字を使用するため、フランス語またはドイツ語ロケールのExcelはセミコロン区切りのCSVを生成する。
• タブ：フィールドにカンマが含まれる場合（住所、自由テキスト）に便利。科学データでよく使われる。
• パイプ：自然なデータにはほとんど出現しない区切り文字へのフォールバック。データにカンマ、セミコロン、タブがすべて含まれる可能性がある一部のレガシーエンタープライズシステムで使われる。

RFC 4180に従い、選択した区切り文字、改行、二重引用符を含むフィールドは自動的に二重引用符で囲まれる。埋め込まれた二重引用符は二重化でエスケープされる。どの区切り文字を選んでも同じ引用規則が適用される。

プライバシー

XMLペイロードには機密情報が含まれることが多い：銀行明細のトランザクション、社内従業員データ、内部URLを明かすサイトマップ、医療記録、NDA付きの商品カタログ。ブラウザ組み込みのDOMParserはタブ内で完全に実行され、ネットワークリクエスト、サーバーへの往復、ログエントリはない。データはクリップボードから解析されたメモリ内ツリーに渡され、平坦化のために1回走査されて結果が出力テキストエリアに表示される。「ダウンロード」をクリックしない限り、ディスクには何も書き込まれない。

よくある間違い

1. 繰り返しレコード形式でないXMLを貼り付ける。繰り返しのない単一の設定ファイルのようなドキュメントは使用可能なCSVに平坦化できない。このコンバーターは「類似アイテムのリスト」形式のXML向けだ。
2. 属性プレフィックスが往復すると期待する。<product id="42">はidという列になる（product@idやproduct.idではない）。CSVを他の場所でXMLとして再インポートする場合は再マッピングが必要だ。
3. 対象者に合わない区切り文字。フランス語版Excelでカンマ区切りのCSVを開くと単一の列に折り畳まれることがある。ファイルが最終的にどこで使われるかに合わせて区切り文字を選ぶ。
4. ExcelのためのUTF-8 BOMを忘れる。BOMなしではWindowsのExcelで非ラテン文字が壊れて見える。BOMを追加するかGoogle Sheets / ウェブ版Excelでファイルを開くこと。
5. XHTMLやDocBookを変換しようとする。混合コンテンツドキュメントXMLはきれいに平坦化できない。それらには表形式コンバーターではなく適切なXML/XSLTパイプラインを使う。
6. フィールド値に存在するCSVインジェクションリスク。XMLにユーザー生成テキストが含まれている場合、ExcelやSheetsで出力を開くと、=、+、-、または@で始まるセルは数式として解釈される。OWASPはこれを実際の攻撃クラスとして記録している。ユーザー生成コンテンツのエクスポートを共有する前にサニタイズすること。
7. 繰り返し子要素。XMLに<tags>ラッパーと複数の<tag>子要素がある場合、平坦出力ではきれいに表現できない。タグごとに1行に平坦化（親フィールドを繰り返して）するか、XMLを前処理してタグを区切り文字付き文字列としてインライン化する。

よくある質問

ツールはXMLをスキーマに対して検証するか？

いいえ。ブラウザ組み込みのDOMParserを使って整形式チェックのみを行う。XSDまたはRELAX NG検証が必要な場合はxmllint、Saxon、またはW3C XML Schemaバリデーターのような専用ツールを使う。CSVへの安全な平坦化には整形式チェックで十分だ。

XMLはどれくらいの大きさまで対応できるか？

ブラウザが保持できる量まで。サーバーが関与していないためサーバーサイドの制限はない。最新デバイスでは数十メガバイトが1〜2秒で変換される。数百メガバイトのXMLがある場合は変換前にバッチ分割する。単一のブラウザタブで処理するとメモリ制限に達することがある。

ツールはXML名前空間を処理できるか？

はい。<atom:link>のような名前空間付き要素は認識され、プレフィックスが列名に保持される。CSVヘッダーにプレフィックスが不要な場合は、出力に対して簡単な検索・置換を実行して除去する。

XMLはどこかにアップロードされるか？

いいえ。すべての解析と平坦化はブラウザ組み込みのDOMParserを通じてブラウザ内で行われる。テキストエリアの内容は送信・記録・保存されない。タブを閉じるとデータは消える。

このツールとJSON-to-CSVツールの違いは？

目標は同じ（階層データを行に平坦化する）だが入力フォーマットが異なる。XMLはより冗長で、属性を許可し、名前空間を持ち、特殊文字にエンティティ参照を使用する。XML-to-CSVコンバーターはそれらの機能を専門的に処理する。JSON-to-CSVコンバーターはオブジェクトの配列入力を期待する。JSONがあればそのツールを使い、XMLがあればこちらがより良い結果を出す。

逆変換（CSVからXML）は可能か？

このツールからはできないが、逆変換は一般的に簡単だ。行要素名を選び、各行をラップし、各列を子要素に変換するだけだ。csvとxml.etreeを使った小さなPythonまたはNodeスクリプトで20行程度で処理できる。またはExcelのPower Queryのような構造化データツールを使えば、選択したスキーマでCSVをXMLにエクスポートできる。