Walidator XML sprawdza, czy dokument XML spełnia reguły strukturalne zdefiniowane w specyfikacji XML 1.0 (zalecenie W3C, wydanie piąte). Podstawowym zadaniem tego walidatora XML jest potwierdzenie, że dokument jest poprawnie uformowany: ma jeden element główny, wszystkie tagi są prawidłowo zagnieżdżone i zamknięte, wartości atrybutów są ujęte w cudzysłowy, a znaki zarezerwowane używają predefiniowanych encji. Dokument, który nie spełnia któregokolwiek z tych wymagań, spowoduje, że parsery XML zgłoszą błędy zamiast po cichu produkować nieprawidłowe dane wyjściowe.
Rozróżnienie między poprawnym uformowaniem a walidacją ma istotne znaczenie. Poprawnie uformowany dokument XML spełnia reguły składniowe samej specyfikacji XML. Ważny dokument XML idzie dalej: jest zgodny z ograniczeniami zdefiniowanymi w zewnętrznym schemacie, takim jak DTD (Document Type Definition), XSD (XML Schema Definition) lub schemat Relax NG. To narzędzie sprawdza poprawne uformowanie — pierwszy i najczęstszy krok walidacji. Bez niego żaden dalszy etap przetwarzania nie może się rozpocząć.
Walidacja XML wykrywa błędy zanim trafią do środowiska produkcyjnego. Niezamknięte tagi, niezgodne nazwy elementów, nieeskejpowane ampersandy i zduplikowane atrybuty należą do najczęstszych błędów w ręcznie edytowanym XML. Parsery w różnych językach obsługują te błędy inaczej: niektóre kończą działanie bez komunikatu, inne zwracają częściowe wyniki, jeszcze inne rzucają wyjątki. Przepuszczenie XML przez walidator eliminuje tę niejednoznaczność i daje jednoznaczną odpowiedź: przeszedł lub nie przeszedł, wraz z informacją o lokalizacji błędu.
Wczesne wykrywanie błędów składniowych XML zapobiega kaskadowym awariom w aplikacjach przetwarzających dane XML. Walidator działający w przeglądarce daje natychmiastową informację zwrotną bez konieczności instalowania narzędzi wiersza poleceń ani konfigurowania wtyczek IDE.
⚡
Natychmiastowe wykrywanie błędów
Wklej XML i uzyskaj wynik w mniej niż sekundę — z dokładną lokalizacją błędu. Bez czekania na potoki kompilacji ani konfiguracji narzędzi CLI.
🔒
Przetwarzanie z priorytetem prywatności
Całe parsowanie i walidacja odbywa się w przeglądarce przy użyciu API DOMParser. Twój XML nigdy nie opuszcza urządzenia i nie jest wysyłany na żaden serwer.
🎯
Precyzyjne raportowanie błędów
Zobacz dokładną linię i kolumnę, w której walidacja nie powiodła się, wraz z opisem błędu. Jest to szybsze niż czytanie śladu stosu z parsera w kodzie aplikacji.
📋
Bez konta ani instalacji
Otwórz stronę, wklej XML i sprawdź wynik. Bez formularzy rejestracyjnych, oprogramowania desktopowego ani rozszerzeń przeglądarki.
Zastosowania walidatora XML
Programowanie frontendowe
Waliduj pliki SVG i fragmenty XHTML przed osadzeniem ich w komponentach React lub Vue. Jeden niezamknięty tag w SVG może zniszczyć całe drzewo komponentów.
Programowanie backendowe
Sprawdzaj odpowiedzi SOAP, ładunki XML-RPC i kanały RSS/Atom z zewnętrznych API. Waliduj surową odpowiedź przed pisaniem logiki deserializacji, aby uniknąć debugowania wyjątków parsera w czasie działania.
DevOps i CI/CD
Sprawdzaj, czy pliki Maven pom.xml, .csproj lub skrypty budowania Ant są poprawnie uformowane po automatycznych edycjach. Błąd składniowy w konfiguracji budowania może zakończyć cały potok z niezrozumiałym komunikatem błędu.
QA i testowanie
Waliduj testowe pliki fixture XML i pliki oczekiwanych wyników przed uruchomieniem testów integracyjnych. Nieprawidłowo uformowane dane fixture powodują fałszywe negatywy, które marnują czas na debugowanie.
Inżynieria danych
Sprawdzaj eksporty XML z baz danych, rządowych portali otwartych danych i potoków ETL. Walidacja struktury przed pisaniem zapytań XPath lub transformacji XSLT zapobiega marnowaniu wysiłku na uszkodzone dane źródłowe.
Nauka XML
Studenci pracujący z samouczkami XML W3C lub XSLT mogą wklejać pliki ćwiczeniowe do walidatora, aby sprawdzić składnię. Komunikaty o błędach wskazują dokładnie na problem, co przyspiesza naukę.
Reguły poprawnego uformowania XML
Specyfikacja XML 1.0 definiuje ścisły zestaw reguł składniowych. Dokument musi spełniać je wszystkie, aby być uznany za poprawnie uformowany. Poniższa tabela zawiera każdą regułę, jej wymagania i poprawny przykład. Większość błędów walidacji wynika z naruszenia jednej z tych reguł.
Reguła
Wymaganie
Poprawny przykład
Single root element
Document must have exactly one root
<root>...</root>
Matched tags
Every opening tag needs a closing tag
<p>text</p>
Proper nesting
Tags must close in reverse order of opening
<a><b>...</b></a>
Quoted attributes
Attribute values must be in single or double quotes
<el attr="val"/>
Entity escaping
Reserved characters must use predefined entities
< > & " '
Case sensitivity
Tag names are case-sensitive: <A> is not </a>
<Book>...</Book>
No duplicate attributes
Each attribute name must appear once per element
<el a="1" b="2"/>
Valid XML declaration
If present, must be the very first line
<?xml version="1.0"?>
Poprawnie uformowany vs. ważny DTD vs. ważny względem schematu
Walidacja XML ma trzy poziomy. To narzędzie sprawdza pierwszy (poprawne uformowanie), który jest warunkiem wstępnym dla pozostałych dwóch.
Poprawnie uformowany
Spełnia reguły składniowe XML 1.0: jeden element główny, pasujące tagi, atrybuty w cudzysłowach, prawidłowe zagnieżdżenie. Każdy parser XML sprawdza to w pierwszej kolejności. Dokument, który nie jest poprawnie uformowany, nie jest w ogóle dokumentem XML.
Ważny DTD
Zgodny z Document Type Definition, który określa dozwolone elementy i atrybuty, ich kolejność i krotność. DTD są deklarowane inline lub poprzez odwołanie DOCTYPE. Walidacja DTD jest powszechna w systemach dziedzicznych i XHTML.
Ważny względem schematu (XSD / Relax NG)
Zgodny z XML Schema Definition (XSD) lub schematem Relax NG. Te schematy obsługują typy danych (integer, date, URI), przestrzenie nazw i złożone modele treści. Walidacja XSD jest standardem w usługach webowych SOAP, danych medycznych HL7 i integracji korporacyjnej.
Przykłady kodu
Waliduj XML programistycznie w różnych językach. Każdy przykład sprawdza poprawne uformowanie i zwraca komunikat błędu, jeśli dokument jest nieprawidłowy.
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
Często zadawane pytania
Jaka jest różnica między poprawnie uformowanym a ważnym XML?
Poprawnie uformowany XML spełnia reguły składniowe specyfikacji XML 1.0: jeden element główny, pasujące i prawidłowo zagnieżdżone tagi, atrybuty w cudzysłowach. Ważny XML idzie dalej, będąc zgodnym z DTD lub schematem XSD definiującym dozwolone elementy, atrybuty i typy danych. Dokument może być poprawnie uformowany, ale nieważny, jeśli ma poprawną składnię, ale narusza ograniczenie schematu.
Czy dokument XML może być ważny, ale nie poprawnie uformowany?
Nie. Poprawne uformowanie jest warunkiem wstępnym ważności. Jeśli dokument narusza jakąkolwiek regułę składniową XML (niezamknięty tag, atrybut bez cudzysłowów itp.), parsery nie mogą zbudować z niego drzewa, więc walidacja schematu nie może się nawet rozpocząć. Najpierw popraw błędy poprawnego uformowania, a następnie sprawdź zgodność ze schematem.
Jakie są najczęstsze błędy walidacji XML?
Pięć najczęstszych błędów to: niezamknięte lub niedopasowane tagi, nieeskejpowane ampersandy w treści tekstowej, wartości atrybutów bez cudzysłowów, brakujący element główny oraz nieprawidłowa wielkość liter w nazwach tagów (XML rozróżnia wielkość liter). Większość z nich jest spowodowana ręczną edycją XML lub konkatenacją ciągów w kodzie zamiast używania właściwego serializatora XML.
Czy walidacja XML to to samo co linting XML?
Pokrywają się, ale nie są identyczne. Walidacja sprawdza, czy dokument jest zgodny ze specyfikacją XML (poprawne uformowanie) lub schematem (DTD/XSD). Linting zazwyczaj idzie dalej, sygnalizując również problemy ze stylem: niespójne wcięcia, nieużywane deklaracje przestrzeni nazw lub nadmiarowe domyślne wartości atrybutów. Narzędzie xmllint z libxml2 łączy oba podejścia: --noout sprawdza poprawne uformowanie, a --schema dodaje walidację XSD.
Czym różni się walidacja XML od walidacji JSON?
XML ma bardziej rygorystyczną i złożoną gramatykę niż JSON. XML wymaga pasujących tagów otwierających i zamykających, obsługuje atrybuty, przestrzenie nazw, mieszaną treść (tekst i elementy razem) i ma wiele języków schematów (DTD, XSD, Relax NG, Schematron). Walidacja JSON sprawdza dopasowanie nawiasów klamrowych i kwadratowych, cytowane klucze i umieszczenie przecinków. JSON Schema istnieje, ale jest prostsze niż XSD. Dokument XML jest zazwyczaj 2–3 razy większy niż równoważny JSON dla tych samych danych.
Czy to narzędzie waliduje względem schematów XSD lub DTD?
To narzędzie sprawdza wyłącznie poprawne uformowanie: potwierdza, że XML spełnia reguły składniowe specyfikacji XML 1.0. Nie waliduje względem zewnętrznych schematów DTD ani XSD. Do walidacji schematu użyj xmllint --schema w wierszu poleceń lub lxml w Pythonie, który obsługuje zarówno XSD, jak i Relax NG.
Dlaczego mój XML nie przechodzi walidacji, choć wygląda poprawnie?
Najczęstsze niewidoczne przyczyny to: znacznik kolejności bajtów (BOM) przed deklaracją XML, zbłąkany znak po zamykającym tagu głównym, nieeskejpowany ampersand w treści tekstowej (użyj & zamiast &), lub prefiks przestrzeni nazw użyty bez wcześniejszej deklaracji. Skopiuj XML do przeglądarki szesnastkowej lub uruchom go przez xmllint --noout, aby uzyskać dokładne przesunięcie bajtowe błędu.