XMLフォーマッター＆ミニファイアー
XMLを貼り付けて瞬時にフォーマット、美化、ミニファイします。
使い方
- 入力エリアにXMLを貼り付けます。
- 美化するにはフォーマット、圧縮するにはミニファイをクリックします。
- 結果をコピーまたはダウンロードします。
よくある質問
XMLにエラーが含まれている場合はどうなりますか?
ツールはブラウザに組み込まれたDOMParserを使ってXMLを検証します。構文エラーは出力の上の赤いボックスに表示されます。
CDATAセクション、コメント、処理命令をサポートしていますか?
はい。フォーマッタはCDATAセクション、コメント、処理命令を含むすべてのXMLノードタイプを保持します。
サイズ制限はありますか?
厳密な制限はありません · ブラウザのメモリに依存します。数MBのXMLファイルは通常瞬時にフォーマットされます。
XMLの実践的な概要
XML 1.0は1998年2月10日にW3C勧告となった。編集者はTim Bray、Jean Paoli、C. M. Sperberg-McQueenで、ワーキンググループはSunのJon Bosakが議長を務めた。Tim Brayのローンチ時のコメントがその設計意図を捉えている：「XMLは拡張可能で、国際化されていて、堅牢でシンプルで、Web向けに作られている。」現在の正式バージョンは第5版（2008年11月26日公開、Bray、Paoli、Sperberg-McQueen、Eve MalerおよびFrançois Yergeau編集）だ。XMLはSGML（ISO 8879:1986）から直接派生している。SGMLははるかに大きく実装が難しいドキュメントフォーマットで、XMLはほとんどの使用頻度の低い部分を削ぎ落としながらドキュメントモデルを維持した。
2026年にXMLが現役の場所
JSONは10年以上にわたりREST APIペイロードを席巻してきたが、スキーマの厳密さ、ドキュメントセマンティクス、または確立された標準が要求される場所ではXMLが依然として根強く使われている。どのような場面でXMLに出会うかを知ることが、優れたフォーマッターの価値の半分を占める：
- Officeドキュメント形式：MicrosoftのXMLパーツで満たされたZIPアーカイブである
.docx/.xlsx/.pptxはECMA-376およびISO/IEC 29500として標準化されている。OpenDocumentの.odt/.ods/.odp（ISO/IEC 26300）も同じパターンに従う。EPUBの電子書籍もXMLでパッケージされている。 - Webボキャブラリー：SVG（ベクターグラフィックス）、MathML（数学記法）、Atomフィード、RSS 2.0、そしてGoogleとBingがクロールスケジューリングのために解析する
sitemap.xmlプロトコル。 - SOAPとエンタープライズメッセージング：銀行、通信、保険、政府のバックエンドは依然としてSOAPエンドポイントを公開しており、多くはRESTファサードの背後にある。XML上の業界標準には、デリバティブ向けのFpML、SEC申告向けのXBRL、保険向けのACORD、決済メッセージング向けのISO 20022が含まれる。
- ビルドおよび設定ファイル：Mavenの
pom.xml、レガシーSpring beans、すべてのAndroidリソース（AndroidManifest.xml、res/values/strings.xml、res/layout/*.xml）、およびXMLバリアントのAppleのInfo.plist。 - 垂直ドメイン間交換：Google Earth向けKML、GPSトレース向けGPX、楽譜向けMusicXML（4.0は2021年公開）、ローカライゼーション向けXLIFF（2.1は2024年7月にISO 21720として標準化）、臨床文書向けHL7 v3 / CDA。
整形式と妥当性：この2つは異なる
XMLには2つの異なる適合レベルがあり、混同しやすい：
- 整形式（Well-formed）とはドキュメントがXMLの文法に従っていることを意味する：ルート要素がちょうど1つ、すべてのタグがバランスよく適切にネストされ、属性値が引用符で囲まれ、エンティティ参照がセミコロンで閉じられ、テキストコンテンツにエスケープされていない
<や&がないことだ。 - 妥当性（Valid）とは整形式のドキュメントが、さらに宣言されたDTD、XSD（XML Schema 1.1）、RELAX NG、またはSchematronスキーマに準拠していることを意味する：正しい場所に正しい要素があり、属性値の型が正しく、カーディナリティが正しいことだ。
このフォーマッターは整形式チェックのみを行う。ブラウザ組み込みのDOMParserはparsererror要素を通じて最初に検出したパースエラーを報告し、ツールはそれを赤いエラーボックスに表示する。スキーマに対する妥当性検証には別のツールが必要だ（XSD向けのSaxon、libxml2のxmllint --schema、W3C XMLバリデーターサービスなど）。
5つの定義済みエンティティ参照
W3C XML 1.0 §4.6によると、「整形式ドキュメントは以下のエンティティを宣言する必要がない」：amp、lt、gt、apos、quot。末尾のセミコロンは必須で、一部のHTML用法と異なり、XMLは&を末尾の;なしに決して受け付けない。
| エンティティ | 文字 | 使用が必要な場面 |
|---|---|---|
< | < | 要素コンテンツでは常に必要（そうしないとタグが開始してしまうため） |
& | & | 常に必要（そうしないとエンティティ参照が開始してしまうため） |
> | > | コンテンツ中の]]>シーケンスの内側で必須。その他の場所では対称性のために推奨 |
' | ' | 単一引用符で区切られた属性値の内側 |
" | " | 二重引用符で区切られた属性値の内側 |
CDATAセクション、コメント、処理命令
XMLをフォーマットする人なら誰でもいずれ出会う3つの特殊な構文機能：
- CDATAセクション：
<![CDATA[ … ]]>ブロックは<と&をエスケープせずに任意のテキストを埋め込める。CDATA内に記述できない唯一のシーケンスはリテラルの閉じ区切り文字]]>だ。XMLドキュメント内にコードサンプル、正規表現パターン、またはHTMLフラグメントを埋め込む際に便利だ。 - コメント：
<!-- … -->。文字列--はコメント内で使用できない。 - 処理命令：
<?target …?>。XML宣言自体は厳密にはPIではないが、ほとんどのツールは同様に扱う：<?xml version="1.0" encoding="UTF-8"?>が推奨される最初の行だ。
名前空間
XMLの名前空間メカニズムは、複数のボキャブラリーが1つのドキュメント内で共存できる仕組みだ。AtomとカスタムExtension、SOAPとWS-Securityヘッダー、OOXMLのメインドキュメントパートと関連する名前空間からの関係、図面、画像などが共存できる。構文はデフォルト名前空間にxmlns="…"、プレフィックス付きにxmlns:prefix="…"で、フォーマッターは両方を変更せずに保持する。名前空間URIは識別子であってURLではなく、何かを解決する必要はない。
有名なXMLセキュリティの落とし穴2つ
Billion Laughs攻撃。再帰的に展開するエンティティを持つ小さなXMLファイルは、パーサーのメモリ内で数十億文字に膨れ上がることがある：
<!ENTITY lol "lol">
<!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
<!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
<!-- … nine more layers later, the document expands to 10^9 lols -->現代のパーサーはこれを防ぐためにエンティティ展開に上限を設けている。XXE（XML External Entity）攻撃は、外部エンティティを解決してローカルファイルを読み取る（<!ENTITY xxe SYSTEM "file:///etc/passwd">）か、サーバーからSSRFリクエストを引き起こすパーサーを悪用する。OWASPのXXE防止チートシートは明確だ：「XXEを防ぐ最も安全な方法は、DTD（外部エンティティ）を常に完全に無効にすることだ。」ブラウザのDOMParserはまさにそれを実行しており、DOCTYPEエンティティ宣言を完全に無視する。これがクライアントサイドのフォーマッターが信頼できないXMLを安全に処理できる理由だ。
整形（Pretty-Print）とミニファイ
- 整形 / 読みやすくは、ネストされた要素をインデントし、開始・終了タグを独立した行に配置して、ミニファイ版より通常30〜50%大きいが読みやすい出力を生成する。デバッグ、差分レビュー、または不慣れなスキーマの学習時に使用する。
- ミニファイは要素間のすべてのホワイトスペースを削除し、テキストコンテンツ内のホワイトスペースは保持する（XMLは
xml:space="default"でオーバーライドされない限り、要素コンテンツ内のホワイトスペースをデフォルトで有意と定義している）。本番ペイロードや転送バイト数が重要な場合に使用する。
xml:space属性は、ドキュメントに埋め込まれたソースコードをそのままにする必要がある場合など、ホワイトスペースが本当に重要な場面でのエスケープハッチだ。先祖要素にxml:space="preserve"を設定すると、準拠プロセッサーはすべてのスペースと改行を子孫要素においてバイト単位で保持する。
フォーマッターが検出するよくあるXMLエラー
- テキストコンテンツにエスケープされていない
&。裸のアンパサンドは常に無効だ。&を使うこと。 - タグの不一致または未閉鎖。最もよくあるパースエラー。すべての
<tag>には対応する</tag>が必要だ（または自己終了形式<tag/>を使用する）。 - 複数のルート要素。XMLドキュメントは最外部要素がちょうど1つ必要だ。トップレベルに兄弟要素が2つある場合は親要素で囲む。
- エンコーディングの不一致。
<?xml version="1.0" encoding="UTF-8"?>宣言はファイルの実際のバイトエンコーディングと一致しなければならない。UTF-8宣言付きのUTF-16 BOMはこのバグの典型的な例だ。 - 属性値の予約文字。
<tag attr="a<b">は<が引用符内で無害に見えても無効だ。 - XML宣言の前に迷子のBOM。一部のテキストエディターは厳密なパーサーを混乱させるUTF-8 BOMをサイレントに挿入する。
xml:space="preserve"領域内の混在した改行コード。CR / LF / CRLFが混在すると、異なるプラットフォームを往復する際に目に見えるホワイトスペースの不具合が生じる可能性がある。
よくある質問
XMLのフォーマットで出力が生成されないのはなぜか？
ほとんどの場合、入力が整形式でないためだ。出力の上のエラーボックスにブラウザのDOMParserが検出した最初のパースエラーが表示される。通常は欠落または不一致のタグ、エスケープされていない&、またはルート要素の欠落だ。エラーを修正して再実行する。
XMLはサーバーにアップロードされるか？
いいえ。整形とミニファイはどちらもブラウザ組み込みのDOMParserと小さなJavaScriptシリアライザー内で実行される。XMLはページから外に出ることはなく、認証情報、内部URL、または機密の顧客データが含まれる可能性があるSOAPペイロードや設定ファイルにとって重要だ。
ツールはXSDまたはDTDスキーマに対して検証できるか？
いいえ。スキーマ検証はスキーマファイルの読み込みと参照の解決が必要で、ブラウザが行う整形式チェックとは別の問題だ。XSD検証にはコマンドラインでSaxonまたはxmllint --schemaを使うか、W3C XML Schemaバリデーターサービスを使う。
XMLは2026年もまだ有用か、それともJSONを使うべきか？
何をするかによる。新しいREST APIにはJSONがほぼ常に正しい選択だ。しかしXMLはOfficeドキュメント（.docx、.xlsx）、エンタープライズメッセージング（SOAP、金融標準）、Androidリソース、EPUB、RSS / Atom、SVG、および規制業界のほとんどの交換フォーマットでは依然としてデフォルトだ。XMLを読み取り、フォーマットし、検証する方法を知ることは依然として基本スキルだ。ただしJSONのように毎日の最初のツールではない。
「すべてのノード型を保持」とはフォーマッターにとって何を意味するか？
CDATAセクション、コメント、処理命令はすべて入力に表示されるとおりに保持され、フォーマッターは要素間のホワイトスペースのみを変更する。<![CDATA[ if (a < b) { … } ]]>ブロックはその内容にエスケープが必要な<文字が含まれていても、バイト単位でラウンドトリップする。