XML バリデーター

An XML validator reads a document and answers a single, narrowly scoped question: is this text well-formed XML that any conformant parser will be able to accept? That is a structural question, not a semantic one. The validator does not know whether your price element should be positive, whether a user element ought to have an email, or whether a feed conforms to a particular publisher's editorial rules. It checks the layer that has to hold before any of those higher-level checks can even begin.

Why "well-formed" is a precise term

The W3C XML specification defines well-formedness as a fixed list of constraints: a single root element, every opening tag has a matching close, elements nest without crossing, attribute values are quoted, special characters are escaped, and the file declares a known encoding. A document that breaks any one of those rules is, by definition, not XML — even if it looks similar. The validator's job is to enforce that definition mechanically so disagreements never come down to "it parsed in my editor".

The well-formedness rules the validator enforces

Knowing which rule failed makes the error message useful. Each of the items below maps to a class of failures that an XML parser will refuse to recover from.

• Exactly one root element. A document with two top-level siblings is not XML, even if each subtree is individually well-formed.
• Every start tag has a matching end tag, in the same case, in the right place: Item open and Item close must match exactly, not Item open with item close.
• Elements nest without crossing: b containing i containing text containing close-i containing close-b is fine; crossing the closes is not.
• Attribute values are always quoted with matching single or double quotes. An attribute without quotes around its value is not allowed.
• Special characters are escaped inside text and attributes: ampersand becomes &, less-than becomes <, and stray quote marks inside an attribute value use " or '.
• The encoding declared at the top of the file (or assumed via BOM or HTTP header) actually matches the byte content. A UTF-8 file declared as ISO-8859-1 will fail on the first non-ASCII byte.

Rule of thumb: fix the first reported error before chasing later ones. A single unclosed tag near the top almost always produces a cascade of misleading errors further down.

このツールの使い方

1. Prepare representative XML documents, feeds, and copied markup blocks that need structural validation in XML バリデーター instead of starting with the largest or most sensitive real input.
2. Run the workflow, generate a validity result with the first XML structure problem highlighted for review, and review closing tags, nesting order, attributes, escaping, namespaces, and whether the copied text is truly XML instead of HTML-like markup before deciding the result is ready.
3. Only copy or download the result after it fits feed debugging, config review, import QA, and support triage and no longer conflicts with this constraint: Well-formed XML is only the first gate; schema or application-specific meaning still has to be checked elsewhere.

XML バリデーター の例

実用的な XML バリデーター の例では、まず小さなサンプルで構造が通るかを確認してから、完全なファイルや payload を試します。

入力例

<item><name>ToolKit</name></item>

期待される出力

Valid XML; root element: item

Four common failures and what the validator says

A) unclosed tag
  <book><title>XML in a Nutshell<author>Eckstein</author></book>
  -> end tag "book" found, but "title" is still open

B) crossed nesting
  <b><i>important</b></i>
  -> end tag "b" does not match the currently open "i"

C) unquoted attribute
  <a href=https://example.com>link</a>
  -> attribute value must be quoted

D) bare ampersand
  <title>Lock & Key</title>
  -> entity reference must end with ";"; did you mean &amp; ?

Notice that all four errors live at the structural layer. None require knowing what the document is about — only how XML wants tags, attributes, and entities to be written.

Where running an XML validator pays off

Validation is most useful at the moment a file is about to leave your hands. Once a malformed XML document is in a feed, an import pipeline, or a partner's inbox, fixing it costs an order of magnitude more than catching it at the source.

• Before publishing an RSS or Atom feed — readers and indexers stop trusting feeds that occasionally fail to parse.
• Before posting an XML payload to a SOAP service or partner API where the server gives only "parse error" with no line number.
• After hand-editing a configuration file (Spring, Maven, Ant, Tomcat) where a missing close tag silently breaks the next deploy.
• When a generated XML export looks fine in a browser but is rejected by a strict importer — validation rules out the structural layer first.
• When debugging an Office Open XML or SVG file, where one malformed element near the start usually blocks everything downstream.

Things well-formedness alone cannot tell you

Passing well-formedness only means the document can be parsed. Whether the parse tree is what the consumer expects is a separate question with its own tools. Knowing the boundary saves a lot of "but it validates!" debates.

• Schema validation (DTD / XSD / RELAX NG) checks element names, allowed children, attribute types, and required occurrences. Well-formedness ignores all of those.
• Namespace correctness: a document can be well-formed and still use the wrong namespace URI, which makes downstream lookups silently miss every node.
• Business invariants — a price element being positive, a date being in the past — never appear in XML's notion of validity at all.
• Whitespace inside mixed-content elements is significant to readers but not to validators; the document may parse but render differently than expected.
• Very large documents may fall over on entity expansion (billion laughs) regardless of well-formedness — security review and parser hardening are separate concerns.

Well-formedness vs adjacent XML checks

実用上の注意

• 検証が答えるのは XML の構造が使えるかどうかであり、業務上の意味が正しいかどうかではありません。
• 後続のエラーを追う前に、まず最初に報告された構文エラーを直してください。先頭側の崩れが連鎖的な誤報を生みやすいためです。
• 本番インポートや監査に使う場合は、修正後の最終データを実際の受け取りシステムでもう一度照合してください。

XML バリデーター の参考情報

XML バリデーター は、このツールで XML 入力が「有効」と見なされる条件と、次の工程を止めやすい構文エラーの種類を説明します。

• 検証では、後続処理に渡す前に構文と構造の一貫性を確認します。
• 最初に報告された問題から直してください。先頭付近の構文エラー 1 つで後続に多くのエラーが連鎖することがあるためです。
• 最終的に使えるかどうかは、実際のインポーター、パーサー、公開環境でも確認してください。

参考資料

• RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
• ECMA-404: The JSON Data Interchange Syntax
• W3C: Extensible Markup Language (XML) 1.0