Walidator XML względem XSD
Sprawdź dokument XML względem schematu XSD i zobacz, który element narusza którą regułę.
To narzędzie działa na serwerze. Walidacji względem XML Schema przeglądarka nie potrafi wykonać, więc twój dokument i schemat są wysyłane tutaj do sprawdzenia, a potem odrzucane. Nie są przechowywane ani logowane i nigdy nie trafiają do adresu URL. Jeśli dokument jest poufny, uruchom zamiast tego xmllint lokalnie — to ten sam silnik.
Wklej dokument i XSD, z którym ma być zgodny. Dostajesz werdykt, a dla każdej naruszonej reguły element, wiersz i ograniczenie — nie tylko słowo „nieprawidłowy”.
Jak to działa
Mogą zawieść trzy rzeczy i każda jest zgłaszana osobno, bo każda oznacza co innego. Dokument może nie być poprawnie sformułowanym XML-em — wtedy nic nie zostało sprawdzone. Schemat może nie być użytecznym XSD — wtedy również nic nie zostało sprawdzone. Albo oba zostały odczytane, a dokument naruszył regułę — i to jedyny przypadek, w którym „nieprawidłowy” mówi coś o twoich danych.
Walidację wykonuje libxml, ten sam silnik, który stoi za niemal wszystkimi narzędziami XML, więc odpowiedź zgadza się z tym, co powie twój build. Jego komunikaty diagnostyczne są pokazywane tak, jak przychodzą, po angielsku, bo wymieniają element i ograniczenie, a parafraza byłaby zgadywaniem, co miał znaczyć komunikat, którego nie napisaliśmy.
To narzędzie działa na serwerze i jest jedynym takim w serwisie. Żadna przeglądarka nie potrafi walidować względem XML Schema; nie ma do tego API. Twój dokument i schemat są wysyłane, sprawdzane i odrzucane: nigdy nie są zapisywane na dysku, nigdy nie trafiają do logów i nigdy nie są umieszczane w adresie URL.
Dwie rzeczy są odrzucane od razu. Dokument lub schemat deklarujący DTD albo encję, bo DTD może kazać parserowi czytać pliki z serwera. Oraz schemat, który importuje lub dołącza inny plik, bo nic nie jest tu pobierane: dałoby się zastosować tylko część, a częściowe sprawdzenie przedstawione jako pozytywne to najgorsza odpowiedź, jakiej może udzielić walidator.
Przykłady
| Przypadek | Dane wejściowe | Wynik |
|---|---|---|
| Wartość niewłaściwego typu | <price>cheap</price> | Element 'price': 'cheap' is not a valid value of the atomic type 'xs:decimal'. |
| Brakujący wymagany atrybut | <book><title>V</title><price>1</price></book> | Element 'book': The attribute 'id' is required but missing. |
| Brakujący element podrzędny | <book id="b1"><title>V</title></book> | Element 'book': Missing child element(s). Expected is ( price ). |
Najczęściej zadawane pytania
Czy mój dokument opuszcza przeglądarkę?
Tak, i to jedyne narzędzie w serwisie, w którym tak jest. Walidacja względem XML Schema nie jest czymś, co potrafi przeglądarka, więc dokument i schemat są wysyłane tutaj, sprawdzane i odrzucane. Nie są przechowywane, nie trafiają do logów i nie są umieszczane w żadnym adresie URL. Jeśli to nie do przyjęcia dla twojego dokumentu, zwaliduj go na swoim komputerze: xmllint robi to samo tym samym silnikiem.
Dlaczego mój schemat został odrzucony, bo importuje inny?
Ponieważ nic nie jest skądkolwiek pobierane: ani z sieci, ani z systemu plików. Schemat rozłożony na kilka plików dałoby się tu zastosować tylko w połowie, a walidator, który sprawdza połowę reguł, a potem mówi „prawidłowy”, daje odpowiedź gorszą niż żadna. Połącz pliki albo zwaliduj na swoim komputerze, gdzie ten drugi plik istnieje.
Dlaczego DOCTYPE jest odrzucany?
Ponieważ DTD może zadeklarować encję wskazującą na plik na serwerze, a to najstarszy znany sposób, by zamienić parser XML w czytnik plików. Ładowanie encji jest tu również wyłączone, więc odrzucenie tej konstrukcji to drugie zabezpieczenie, a nie jedyne; ale tak czy inaczej dokument sprawdzany względem XSD nie potrzebuje DTD.
Dlaczego komunikaty o błędach są po angielsku?
Pochodzą z libxml, a nie z tego serwisu. Przytaczają nazwy twoich elementów i ograniczenie, które nie zostało spełnione — czyli to, czego potrzebujesz — a tłumaczenie ich oznaczałoby parafrazowanie komunikatów, których nie napisaliśmy; pomyłka w którymś z nich kosztuje więcej niż przeczytanie go po angielsku.
Która wersja XML Schema?
XSD 1.0, bo tę implementuje libxml. Asercje XSD 1.1 i warunkowe przypisywanie typów nie są obsługiwane, więc schemat 1.1, który ich używa, zostanie zgłoszony jako nieczytelny, zamiast zostać po cichu sprawdzony bez tych reguł.
Mój schemat zaczyna się od encoding="utf-16" i został odrzucony. Dlaczego?
Ponieważ ta deklaracja opisuje plik, a to, co dociera do tej strony, to tekst wysłany przez twoją przeglądarkę, czyli UTF-8. libxml uwierzył deklaracji i odmówił odczytania schematu. Teraz deklaracja kodowania jest pomijana zawsze, gdy nie wskazuje UTF-8, a wynik o tym informuje. To samo z encoding="ISO-8859-1" było wcześniej gorsze, bo nie powodowało błędu: każdy znak diakrytyczny był po cichu zniekształcany, a dokument był potem walidowany względem tekstu, którego nikt nie napisał.
Warto wiedzieć
- Działa na serwerze. Twój dokument i schemat są wysyłane, sprawdzane i odrzucane: nie są przechowywane, nie trafiają do logów i nie da się ich udostępnić w adresie URL. Wszystkie pozostałe narzędzia w tej kategorii działają w przeglądarce; to nie może, bo żadna przeglądarka nie waliduje względem XML Schema.
- Werdykt pochodzi z libxml, podobnie jak treść wszystkich komunikatów diagnostycznych. Tylko XSD 1.0.
- Wyświetlanych jest najwyżej pięćdziesiąt problemów. Dokument, który narusza regułę tysiąc razy, zwykle narusza ją z jednego powodu.
Źródła
Wszystkie narzędzia z kategorii Kod