ToolDeck

XML Validator

XML構文を検証して整形式エラーをチェック

サンプルを試す

XML入力

ローカルで実行 · シークレットの貼り付けも安全
こちらもどうぞ：XMLフォーマッターXMLミニファイアーXMLからJSON変換ツールXML to YAMLXPath テスター

XML検証とは？

XMLバリデーターは、XMLドキュメントがXML 1.0仕様（W3C勧告、第5版）で定義された構造ルールに従っているかどうかを確認します。最低限として、このXMLバリデーターはドキュメントが「整形式」であることを確認します。つまり、ルート要素が1つであること、すべてのタグが適切にネストされ閉じられていること、属性値がクォートで囲まれていること、予約文字が定義済みエンティティを使用していることです。これらのチェックのいずれかに失敗したドキュメントは、XMLパーサーが誤った出力を黙って生成するのではなく、エラーをスローします。

整形式と妥当性の違いは重要です。整形式のXMLドキュメントはXML仕様自体の構文ルールを満たしています。妥当なXMLドキュメントはさらに一歩進んで、DTD（文書型定義）、XSD（XMLスキーマ定義）、Relax NGスキーマなどの外部スキーマで定義された制約にも準拠します。このツールは整形式を確認します。これが最初かつ最も一般的な検証ステップです。整形式でなければ、下流の処理は何も進められません。

XML検証は、エラーが本番環境に到達する前に検出します。閉じられていないタグ、要素名の不一致、エスケープされていないアンパサンド、属性の重複は、手動編集されたXMLで最もよく見られるミスです。異なる言語のパーサーはこれらのエラーをさまざまな方法で処理します。エラーを黙って無視するものもあれば、部分的な結果を返すものもあり、例外をスローするものもあります。バリデーターを通じてXMLを事前に確認することで、この曖昧さをなくし、エラー位置の詳細とともに明確な合否の答えが得られます。

オンラインXMLバリデーターを使う理由

XMLの構文エラーを早期に検出することで、XMLデータを処理するアプリケーションの連鎖的な障害を防ぎます。ブラウザベースのバリデーターは、コマンドラインツールのインストールやIDEプラグインの設定なしに即座のフィードバックを提供します。

⚡
即時エラー検出
XMLを貼り付けると、1秒以内に正確なエラー位置とともに合否の結果が得られます。ビルドパイプラインやCLIツールのセットアップを待つ必要はありません。
🔒
プライバシー優先の処理
すべての解析と検証はDOMParser APIを使用してブラウザ内で行われます。XMLがマシンの外に出ることはなく、いかなるサーバーにも送信されません。
🎯
正確なエラー報告
検証が失敗した正確な行と列、およびエラーの説明が表示されます。アプリケーションコードのパーサーからスタックトレースを読むよりも高速です。
📋
アカウントやインストール不要
ページを開いてXMLを貼り付け、結果を確認するだけです。サインアップフォーム、デスクトップソフトウェア、ブラウザ拡張機能は一切不要です。

XMLバリデーターの使用例

フロントエンド開発
ReactやVueコンポーネントに埋め込む前にSVGファイルとXHTMLフラグメントを検証します。SVG内の閉じられていないタグ1つで、コンポーネントツリー全体が壊れることがあります。
バックエンドエンジニアリング
サードパーティAPIからのSOAPレスポンス、XML-RPCペイロード、RSS/Atomフィードをチェックします。デシリアライズロジックを書く前に生のレスポンスを検証することで、実行時のパーサー例外のデバッグを避けられます。
DevOpsとCI/CD
自動編集後にMavenのpom.xml、.csproj、Antビルドファイルが整形式であることを確認します。ビルド設定の構文エラーは、分かりにくいエラーメッセージでパイプライン全体を失敗させることがあります。
QAとテスト
統合テストを実行する前にXMLテストフィクスチャと期待値ファイルを検証します。不正なフィクスチャはデバッグ時間を無駄にする偽陰性を引き起こします。
データエンジニアリング
データベース、政府のオープンデータポータル、ETLパイプラインからのXMLエクスポートをチェックします。XPathクエリやXSLT変換を書く前に構造を検証することで、破損したソースデータへの無駄な作業を防ぎます。
XMLの学習
W3C XMLやXSLTのチュートリアルを学ぶ学生は、演習ファイルをバリデーターに貼り付けて構文を確認できます。エラーメッセージは正確な問題箇所を指し示し、学習サイクルを速めます。

XML整形式のルール

XML 1.0仕様は厳密な構文ルールのセットを定義しています。ドキュメントが整形式と見なされるためには、そのすべてを満たす必要があります。以下の表は各ルール、その要件、および正しい例を示しています。ほとんどの検証エラーはこれらのルールのいずれかに起因します。

ルール要件正しい例
Single root elementDocument must have exactly one root<root>...</root>
Matched tagsEvery opening tag needs a closing tag<p>text</p>
Proper nestingTags must close in reverse order of opening<a><b>...</b></a>
Quoted attributesAttribute values must be in single or double quotes<el attr="val"/>
Entity escapingReserved characters must use predefined entities&lt; &gt; &amp; &quot; &apos;
Case sensitivityTag names are case-sensitive: <A> is not </a><Book>...</Book>
No duplicate attributesEach attribute name must appear once per element<el a="1" b="2"/>
Valid XML declarationIf present, must be the very first line<?xml version="1.0"?>

整形式 vs. DTD妥当 vs. スキーマ妥当

XML検証には3つのレベルがあります。このツールは最初のレベル（整形式）を確認します。これは他の2つの前提条件です。

整形式
XML 1.0の構文ルールを満たしています。ルート要素が1つ、タグが一致していること、属性がクォートで囲まれていること、適切なネスト。すべてのXMLパーサーはまずこれをチェックします。整形式でないドキュメントはXMLとは言えません。
DTD妥当
使用できる要素と属性、その順序、カーディナリティを指定する文書型定義に準拠しています。DTDはインラインまたはDOCTYPE参照で宣言されます。DTD検証はレガシーシステムとXHTMLで一般的です。
スキーマ妥当（XSD / Relax NG）
XMLスキーマ定義（XSD）またはRelax NGスキーマに準拠しています。これらのスキーマはデータ型（整数、日付、URI）、名前空間、複雑なコンテンツモデルをサポートします。XSD検証はSOAP Webサービス、HL7医療データ、エンタープライズ統合で標準です。

コード例

さまざまな言語でXMLをプログラムから検証する方法を示します。各例は整形式をチェックし、ドキュメントが不正な場合にエラーメッセージを返します。

JavaScript (DOMParser)
function validateXML(xmlString) {
  const parser = new DOMParser()
  const doc = parser.parseFromString(xmlString, 'application/xml')
  const error = doc.querySelector('parsererror')
  if (error) {
    return { valid: false, message: error.textContent }
  }
  return { valid: true, message: 'Well-formed XML' }
}

validateXML('<root><item>hello</item></root>')
// → { valid: true, message: "Well-formed XML" }

validateXML('<root><item>hello</root>')
// → { valid: false, message: "Opening and ending tag mismatch..." }
Python
import xml.etree.ElementTree as ET

def validate_xml(xml_string):
    try:
        ET.fromstring(xml_string)
        return True, "Well-formed XML"
    except ET.ParseError as e:
        return False, str(e)

valid, msg = validate_xml('<root><item>hello</item></root>')
# → (True, "Well-formed XML")

valid, msg = validate_xml('<root><item>hello</root>')
# → (False, "mismatched tag: line 1, column 27")

# With lxml — also supports XSD schema validation
from lxml import etree
schema = etree.XMLSchema(etree.parse('schema.xsd'))
doc = etree.fromstring(b'<root><item>hello</item></root>')
schema.validate(doc)  # → True or False
Go
package main

import (
    "encoding/xml"
    "fmt"
    "strings"
)

func validateXML(raw string) error {
    decoder := xml.NewDecoder(strings.NewReader(raw))
    for {
        _, err := decoder.Token()
        if err != nil {
            if err.Error() == "EOF" {
                return nil
            }
            return err
        }
    }
}

func main() {
    err := validateXML("<root><item>hello</item></root>")
    fmt.Println(err) // → <nil>

    err = validateXML("<root><item>hello</root>")
    fmt.Println(err) // → XML syntax error: unexpected end element </root>
}
CLI (xmllint)
# Check well-formedness (part of libxml2, pre-installed on macOS/Linux)
xmllint --noout document.xml
# Exit code 0 = valid, non-zero = errors printed to stderr

# Validate against an XSD schema
xmllint --noout --schema schema.xsd document.xml

# Validate against a DTD
xmllint --noout --dtdvalid schema.dtd document.xml

# Validate from stdin
echo '<root><unclosed>' | xmllint --noout -
# → :1: parser error : Premature end of data in tag unclosed line 1

よくある質問

整形式のXMLと妥当なXMLの違いは何ですか？
整形式のXMLはXML 1.0仕様の構文ルールに従っています。ルート要素が1つ、タグが一致して適切にネストされていること、属性がクォートで囲まれていることです。妥当なXMLはさらに進んで、使用できる要素、属性、データ型を定義するDTDまたはXSDスキーマにも準拠しています。正しい構文を持ちながらもスキーマ制約を破っているドキュメントは、整形式ではあるが妥当ではないことがあります。
XMLドキュメントは妥当だが整形式でないことはありますか？
ありません。整形式は妥当性の前提条件です。ドキュメントがXML構文ルール（閉じられていないタグ、クォートなしの属性など）に違反している場合、パーサーはそこからツリーを構築できないため、スキーマ検証を始めることもできません。まず整形式エラーを修正してから、スキーマに対してチェックしてください。
最も一般的なXML検証エラーは何ですか？
最も頻繁なエラーは5つです。閉じられていないタグや不一致のタグ、テキストコンテンツ内のエスケープされていないアンパサンド、クォートなしの属性値、ルート要素の欠如、タグ名の大文字小文字の誤り（XMLは大文字小文字を区別します）。これらのほとんどは、XMLを手動編集したり、適切なXMLシリアライザーの代わりにコード内で文字列連結を使用したりすることで発生します。
XML検証とXMLリンティングは同じですか？
重なる部分はありますが、同一ではありません。検証はドキュメントがXML仕様（整形式）またはスキーマ（DTD/XSD）に準拠しているかを確認します。リンティングは通常さらに進んで、スタイルの問題もチェックします。一貫しないインデント、未使用の名前空間宣言、冗長なデフォルト属性値などです。libxml2のxmllintはその両方を組み合わせています。--nooutで整形式を確認し、--schemaでXSD検証を追加します。
XML検証はJSON検証とどう違いますか？
XMLはJSONより厳格で複雑な文法を持っています。XMLは一致する開始・終了タグを必要とし、属性、名前空間、混在コンテンツ（テキストと要素の混在）をサポートし、複数のスキーマ言語（DTD、XSD、Relax NG、Schematron）があります。JSON検証は中括弧・角括弧の対応、クォートされたキー、カンマの位置をチェックします。JSON Schemaは存在しますが、XSDよりシンプルです。XMLドキュメントは同じデータのJSON相当と比べて通常2〜3倍大きくなります。
このツールはXSDまたはDTDスキーマに対して検証しますか？
このツールは整形式のみを確認します。XMLがXML 1.0仕様の構文ルールに従っていることを確認します。外部のDTDやXSDスキーマに対する検証は行いません。スキーマ検証にはコマンドラインでxmllint --schemaを使用するか、XSDとRelax NGの両方をサポートするPythonのlxmlを使用してください。
正しく見えるのにXMLが検証に失敗するのはなぜですか？
最もよくある目に見えない原因は次のとおりです。XML宣言の前のバイト順マーク（BOM）、ルート閉じタグの後の不正な文字、テキストコンテンツ内のエスケープされていないアンパサンド（代わりに&amp;を使用）、使用されているが宣言されていない名前空間プレフィックス。XMLをHEXビューアにコピーするか、xmllint --nooutで実行してエラーの正確なバイトオフセットを確認してください。

関連ツール

XMLフォーマッターXMLをフォーマットして構文ハイライト付きで見やすく表示XMLミニファイアー空白とコメントを削除してXMLを圧縮XMLからJSON変換ツールXMLをJSON形式に変換XML to YAMLXMLをYAML形式に変換XPath テスターXPath式をXMLに対してテストし、一致するすべてのノードを確認