この記事の要点

XML は eXtensible Markup Language の略で、1998 年 W3C 勧告の汎用マークアップ言語。データ交換と設定ファイルの両方で長く使われてきた タグ・属性・テキストで構成される点は HTML と同じだが、タグ名は自由に定義でき、構文に対する厳密さが大きく異なる 正しい XML 文書は well-formed (整形式) である必要があり、加えて DTD / XSD でスキーマを定義すれば valid (妥当) な文書として検証できる 名前空間 (xmlns) によって異なる語彙を 1 つの文書内で混在させられる。SVG, MathML, XHTML を同じファイルに同居させるなど XSLT で XML を別フォーマット（HTML/PDF/別 XML）に変換、XPath で要素・属性をクエリ取得する SVG / RSS / Atom / SOAP / MathML / Office Open XML (.docx/.xlsx/.pptx) はいずれも XML ベース。普段意識しなくても触っている JSON や YAML の台頭で API のデータ交換用途では衰退したが、設定・規格・文書系 (XBRL, TEI, DITA 等) では現役

概要

XML (eXtensible Markup Language) は、データを階層的に記述するための汎用マークアップ言語である。1998 年に W3C が勧告し、HTML の祖先でもある SGML を簡素化した位置づけに当たる。HTML が「Web ページを表示する」という特定用途のためにタグセットが固定されているのに対し、XML はタグ名を自由に定義でき、業界・組織ごとに独自の語彙 (XML 方言) を作って使うことが想定されている。

2000 年代には「あらゆるデータ交換の標準」として広く期待され、SOAP Web サービス、Office Open XML（.docx 等）、SVG、RSS/Atom、Ant のビルドファイル、Maven の pom.xml、Spring の applicationContext.xml、Android の AndroidManifest.xml ⋯ ありとあらゆる場所で採用された。その後、よりシンプルな JSON が台頭して API データ交換の主役の座は明け渡したが、設定ファイル・文書フォーマット・業界規格 (XBRL, HL7, TEI, DITA 等) では今も第一線で使われ続けている。

内部構造・構文

XML 文書は必ず単一のルート要素を持つ。先頭に XML 宣言を書くのが推奨で、エンコーディングを明示できる。タグは大文字小文字を区別し、すべての要素は必ず閉じる必要がある（空要素は <br/> のように自己終了タグを使う）。

<?xml version="1.0" encoding="UTF-8"?>
<catalog xmlns="http://example.com/catalog">
  <book id="b001" lang="ja">
    <title>XML 入門</title>
    <authors>
      <author>山田 太郎</author>
      <author>佐藤 花子</author>
    </authors>
    <price currency="JPY">2980</price>
    <description><![CDATA[
      ここには < や > をエスケープせずそのまま書ける。
    ]]></description>
  </book>
</catalog>

整形式 (well-formed) とは「タグの開閉が正しい」「ルート要素が 1 つ」「属性値はクオートで囲む」「予約文字 (&, <, >, ', ") を実体参照またはCDATAで扱う」といった文法的に正しい状態を指す。これすら満たさない XML はパーサがエラーを返して停止する（HTML のように寛容に救済はしてくれない）。

妥当 (valid) はさらに踏み込んで、文書が事前定義したスキーマ（DTD または XSD）に従っていることを意味する。XSD (XML Schema Definition) では「book 要素は title を 1 つ、author を 1 つ以上、price を 1 つ持つ」といった構造制約や、price は xs:integer であるといった型制約まで宣言できる。

名前空間 (Namespace) は xmlns="URI" や xmlns:prefix="URI" で宣言し、同じタグ名でも異なる文脈に属することを示せる。これにより XHTML+SVG+MathML を 1 ファイルに混在させたり、SOAP エンベロープに任意のペイロードを入れたりできる。

主な用途

• 文書フォーマット — Microsoft Office (Office Open XML: .docx / .xlsx / .pptx は内部が ZIP+XML)、ODF
• ベクター画像 — SVG（拡張子 .svg だが中身は XML）
• Web フィード — RSS、Atom（ブログ更新通知の事実上の標準）
• API / RPC — SOAP（XML-RPC の発展形）、XML-RPC、現役の業界系 API
• ビルド・設定 — Maven (pom.xml)、Ant (build.xml)、Spring (applicationContext.xml)、Android (AndroidManifest.xml, layout XML)、Java Web の web.xml
• サイトマップ — sitemap.xml（検索エンジンに URL リストを伝える）
• 業界標準 — XBRL（財務報告）、HL7（医療情報）、TEI（テキスト符号化）、DITA（テクニカルライティング）

関連形式との比較

形式	冗長性	スキーマ	強み	弱み
XML	高	DTD / XSD	名前空間、変換 (XSLT)、コメント、属性とテキストの併用	冗長で読みづらい、パース重い
JSON	低	JSON Schema	軽量、JS と親和、API で標準	コメント不可、属性なし
YAML	低	JSON Schema 等	人間が読みやすい、コメント可	インデント依存で誤りやすい
TOML	中	仕様で型固定	設定ファイル向き、明快	深いネストが書きにくい
HTML	中	仕様で固定	ブラウザが直接描画	タグセットが固定

編集・パーサ・ツール

• エディタ — VS Code（XML 拡張機能で整形・検証）、XMLSpy、Oxygen XML Editor
• パーサライブラリ — Java: JAXP (DOM/SAX/StAX)、Python: xml.etree.ElementTree / lxml、Node.js: xml2js / fast-xml-parser、PHP: SimpleXMLElement / DOMDocument
• 変換 — XSLT プロセッサ (Saxon, Xalan) で XML → HTML / PDF / 別 XML
• クエリ — XPath（XML 内の任意ノードを CSS セレクタのように指定）、XQuery（SQL のような問い合わせ言語）
• 検証 — xmllint（コマンドライン）、各エディタのスキーマ検証機能

注意点・落とし穴

• 冗長で容量を食う — 同じデータでも JSON の 2〜3 倍になりがち。データ量が大きい API では gzip 圧縮や JSON への移行を検討
• XXE (XML External Entity) 攻撃 — 外部実体参照を有効にしたパーサに <!ENTITY xxe SYSTEM "file:///etc/passwd"> を含む XML を投げるとローカルファイルが読み取られる。パーサで必ず外部実体参照を無効化する
• 名前空間の見落とし — XPath 等でクエリしても、名前空間を考慮しないとマッチしない。Spring の Bean XML や SVG を扱うときに頻発する事故
• BOM とエンコード — UTF-8 BOM が先頭にあると一部のパーサが <?xml 宣言を認識できなくなる。エディタの保存設定に注意
• CDATA セクションの誤用 — CDATA 内では入れ子の ]]> が書けない。HTML や JS のコードをそのまま埋め込みたい時は CDATA を使うが、限界も理解しておく
• JSON への安直な変換 — XML は「属性」と「テキスト」を区別するが JSON は区別しない。機械変換すると情報が失われる場合がある

関連リンク

• Web・データ・設定（親カテゴリ）
• ファイル拡張子とは
• HTML（.html / .htm） — XML の親戚にあたるマークアップ
• JSON（.json） — XML を置き換えたデータ交換形式
• web.xml — Java Web アプリのデプロイ記述子
• struts-config.xml の説明
• sitemap.xml