Kuinka vahvistaa xhtml?

Kirjoittaja: Niquelao Resource Desk · Päivitetty 28. syyskuuta 2026

XHTML:n validoiminen tarkoittaa sen tarkistamista, että dokumentti noudattaa kahta sääntökerrosta: XML-syntaksia ja sen ilmoitettua DTD:tä tai skeemaa. XHTML 1.0 on HTML 4.01:n uudelleenmuotoilu XML-muotoon, joten asiakirja voi olla hyvin muotoiltu mutta virheellinen, kuten silloin, kun <a target="_blank"> esiintyy XHTML 1.0 Strictissä.

XHTML:n validointi on tarkistusta siitä, että asiakirja noudattaa samanaikaisesti kahta sääntökerrosta:

XML-syntaksisäännöt: oikein sisäkkäiset tagit, attribuutit lainausmerkeissä, kaikkien elementtien pakollinen sulkeminen (mukaan lukien tyhjät, kuten <br />), yksi juurielementti, yhtenäinen ilmoitettu koodaus jne.
DTD-säännöt tai ilmoitettu skeema: mitä elementtejä ja attribuutteja on olemassa, missä kontekstissa ne voivat esiintyä ja mitkä arvot ovat sallittuja. Tässä ovat XHTML 1.0:n (Strict, Transitional, Frameset), XHTML 1.1:n, XHTML Basicin ja XHTML Modularizationin klassiset DTD:t.

Asiakirja voi olla hyvin muotoiltu XML ja silti virheellinen: jos esimerkiksi käytät <a target="_blank"> XHTML 1.0 Strictissä, syntaksi on moitteeton, mutta target-attribuuttia ei ole kyseisessä DTD:ssä. Tämä ero hyvin muotoillun ja validin välillä on yleisin hämmennyksen syy, kun joku näkee virheen eikä ymmärrä miksi.

On myös kätevää muistaa, että XHTML 1.0 on W3C:n määrittelemä HTML 4.01:n uudelleenmuotoilu XML-muotoon. Nykyään sen käytännön arvo on kaksijakoinen: se palvelee vanhoja projekteja, joita tarjoillaan edelleen muodossa application/xhtml+xml tai text/html, ja se toimii henkisenä kurina puhtaan merkinnän kirjoittamiseen. Jos haluat täydellisen normatiivisen kontekstin XHTML:n validoinnista, W3C:n XHTML 1.0 -spesifikaatio on ensisijainen lähde.

Vaivan arvoiset validaattorit (ja milloin käyttää mitäkin)

Ei ole olemassa yhtä “oikeaa” validaattoria. Valinta riippuu siitä, validoitko fragmenttia, tuotantosivua, koko sivustoa vai asiakirjaa, joka on jo XHTML5:tä.

Työkalu	Mitä validoi	Ihanteellinen	Päärajoitus
W3C Markup Validation Service (validator.w3.org)	XHTML 1.0/1.1, HTML4, HTML5	Yksittäinen validointi URL:n, tiedoston tai suoran syötteen kautta	Moderni “Nu Html Checker” priorisoi HTML5:ttä; vanhat DTD:t vaativat manuaalisen valinnan
Nu Html Checker (vnu)	HTML5 ja XHTML5	Uudet projektit, paikallinen validointi ja CI	Ei validoi XHTML 1.x:n klassisia DTD:itä
Paikalliset validaattorit (vnu.jar, tidy)	Konfiguraation mukaan	Automatisointi, pre-commit, putkistot	Vaatii Javan tai binäärien asennuksen; alkuasetukset
xmllint	XML-muotoilu ja validointi DTD/XSD-tiedostoa vastaan	Puhtaan XML-kerroksen tarkistus	Ei tunne HTML-kohtaisia sääntöjä skeeman ulkopuolella
Selainlaajennukset / IDE	Reaaliaikainen merkintä	Välitön palaute kirjoituksen aikana	Käyttävät usein vanhentuneita tai puutteellisia moottoreita

W3C Markup Validation Service

Se on edelleen lähtökohta niille, jotka pohtivat, miten XHTML validoidaan. Se tukee kolmea tilaa: Validate by URI, Validate by File Upload ja Validate by Direct Input. Klassisessa XHTML:ssä temppu on Document Type -pudotusvalikossa: jos asiakirja ilmoittaa oman DTD:nsä DOCTYPE-määritelmän kautta, validaattori kunnioittaa sitä; jos ei, sen on pakotettava manuaalisesti.

Aiheeseen liittyvä: — Superposición de IA que promete cumplimiento WCAG en 48 horas.

Yksityiskohta, josta monet eivät tiedä: moderni W3C-validaattori luottaa Nu Html Checkeriin, joka ymmärtää HTML5:ttä ja XHTML5:tä, mutta käsittelee vanhoja DTD:itä pienemmällä prioriteetilla. XHTML 1.0 Strictissä se toimii edelleen, mutta on suositeltavaa varmistaa, että tulos heijastaa odottamaasi DTD:tä eikä löysää tulkintaa.

Nu Html Checker (vnu)

Tämä on validaattori, jota W3C itse käyttää sisäisesti. Se on saatavilla verkkopalveluna, JAR-suoritettavana tiedostona ja Docker-kuvana. Sen suuri etu on, että voit ajaa sen paikallisesti ja jatkuvassa integraatiossa, mikä on olennaista suuren sivuston ylläpidossa. Kun XHTML tarjoillaan muodossa application/xhtml+xml, vnu havaitsee sisäkkäisyys- ja attribuuttivirheet, jotka suvaitsevainen HTML-validaattori päästäisi läpi.

xmllint

Jos huolesi koskee puhdasta XML-kerrosta – esimerkiksi siksi, että luot XHTML:ää XSLT-malleista – xmllint on korvaamaton. Komennolla --noout --valid documento.xhtml se tarkistaa hyvin muotoilun ja validiteetin viitattua DTD:tä vastaan. Se on nopea, skriptattava eikä riipu verkosta.

Katsomisen arvoinen: — Widget de accesibilidad con plan gratuito para empezar hoy mismo.

Validointi editorissa

VS Coden laajennukset, IDE-pluginit ja komentorivityökalut tarjoavat välitöntä palautetta. Ne ovat käteviä, mutta jäävät usein jälkeen standardien suhteen. Käytä niitä ensimmäisenä puolustuslinjana, ei koskaan ainoana varmistuksena.

Kuinka validoida XHTML vaihe vaiheelta

1. Ilmoita DOCTYPE ja koodaus oikein

DOCTYPE määrittää, mitä sääntöjä vastaan asiakirja validoidaan. XHTML 1.0 Strictille:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="fi" lang="fi">
<head>
  <meta http-equiv="Content-Type"
        content="application/xhtml+xml; charset=UTF-8" />
  <title>Kelvollinen esimerkki</title>
</head>

Kaksi klassista virhettä tässä: xmlns-attribuutin unohtaminen (pakollinen XHTML:ssä) ja meta-elementissä ilmoitettu koodaus, joka ei vastaa varsinaista tiedostoa. Validaattori havaitsee molemmat, mutta jälkimmäinen näkyy joskus vain vioittuneina merkkeinä.

2. Tarkista hyvin muotoilu (well-formedness) ennen validiteettia

Ennen kuin taistelet DTD:n kanssa, varmista, että XML on hyvin muotoiltu. xmllint --noout archivo.xhtml kertoo tämän sekunneissa. Jos se epäonnistuu tässä, mikään DTD-validaattori ei auta: sulje ensin tagit, korjaa sisäkkäisyys ja eskappaa entiteetit (&, <, >).

3. Validoi DTD:tä vastaan

Kun asiakirja on hyvin muotoiltu, aja se W3C-validaattorin tai vnu:n läpi. Tarkista paitsi kuinka monta virhettä on, myös minkä tyyppisiä ne ovat. Yksittäinen sisäkkäisyysvirhe voi aiheuttaa kaskadin toissijaisia virheitä, jotka häviävät, kun ensimmäinen korjataan.

4. Validoi koko sivusto, ei vain etusivua

Yleinen virhe on validoida vain pääsivu ja olettaa muiden olevan kunnossa. Mallit, komponentit ja dynaamisesti luodut sivut sisältävät usein virheellistä merkintää. Automatisoi: käy läpi tärkeimmät URL-osoitteet skriptillä ja aja vnu jokaiselle vastaukselle.

Aiheeseen liittyvä: — El estándar de la industria para testear accesibilidad durante el desarrollo.

5. Integroi validointi työnkulkuusi

Manuaalinen validointi ei skaalaudu. Lisää putkistoosi validointivaihe (pre-commit-koukku, build-tehtävä tai CI-työ), joka epäonnistuu, jos uusi virhe ilmenee. Näin virheellinen merkintä ei koskaan päädy tuotantoon.

Virheiden tulkinta: ne, joita näet uudestaan ja uudestaan

“end tag for X omitted, but OMITTED end tags are not allowed”: tyypillistä <li>, <p> tai <td> elementeille, joita ei ole suljettu. XHTML:ssä kaiken on oltava suljettuna.
“there is no attribute X”: attribuuttia ei ole DTD:ssäsi. Tavallisia tapauksia: target, name joissakin elementeissä, data-*-attribuutit XHTML 1.0:ssa (ei klassisessa DTD:ssä).
“element X undefined”: käytetään elementtiä, jota DTD ei tunne, usein HTML5-merkinnän kopioimisen seurauksena XHTML 1.0 -asiakirjaan.
“character data is not allowed here”: tekstisisältöä kohdassa, jossa DTD odottaa vain elementtejä, tai eskappaamaton &.
“reference to entity X for which no system identifier could be generated”: nimetyt HTML-entiteetit, joita ei ole määritelty XML:ssä (esimerkiksi   ilman määrittelyä). Käytä puhtaassa XHTML:ssä   tai määrittele entiteetti.

Kultainen sääntö XHTML:n validoinnissa: korjaa ylhäältä alas. Ensimmäinen virhe on yleensä syy; seuraavat ovat sen seurauksia.

XHTML5: vivahteet, jotka muuttavat säännöt

Jos tarjoilet XHTML5:ttä — HTML5-syntaksin mukaisesti serialisoitua XHTML:ää — säännöt muuttuvat. DTD:tä ei enää ole: yhteensopivuus määritellään WHATWG HTML -spesifikaatiossa ja W3C:n HTML-spesifikaatioissa. Oikea validaattori on Nu Html Checker, ei klassinen DTD-validaattori.

Jos olet ostoksilla: — La Certificación profesional que acredita tu experiencia en accesibilidad.

Käytännön eroja XHTML:n validoinnissa:

data-*-attribuutit ovat valideja XHTML5:ssä, eivät XHTML 1.0:ssa.
DOCTYPE on yksinkertaistettu muotoon <!DOCTYPE html>.
Validointi tehdään HTML5:n conformance checkeria vastaan, joka on joissakin kohdissa sallivampi ja toisissa tiukempi (esimerkiksi tiettyjen vanhentuneiden elementtien käytössä).

Valinta XHTML 1.0:n ja XHTML5:n välillä ei ole vain tekninen: jos projektisi on uusi, XHTML5 vnu-validoinnilla on järkevin polku. Jos ylläpidät vanhaa DTD-pohjaista järjestelmää, pysy XHTML 1.0:ssa ja validoi sitä sen DTD:tä vastaan.

Validointi ja saavutettavuus: kaksi eri kerrosta

Yleinen virhe on uskoa, että validi asiakirja on automaattisesti saavutettava. Ei ole. Validointi tarkistaa syntaksin ja skeeman yhdenmukaisuuden; saavutettavuus arvioidaan W3C:n WCAG-ohjeiden perusteella, joka kattaa havainnoitavuuden, käytettävyyden ja yhteensopivuuden avustavien teknologioiden kanssa.

Tästä huolimatta päällekkäisyyttä on: virheellinen merkintä tarkoittaa yleensä puutteellista rakennetta (huonosti sisäkkäiset otsikot, rikkinäiset listat, lomakkeet ilman oikeita tunnisteita), ja tämä vaikuttaa saavutettavuuteen. Järkevä strategia XHTML:n ja muiden asiakirjojen validoimiseksi on validoida ensin (poistaa rakenteellinen kohina) ja auditoida saavutettavuus sen jälkeen työkaluilla kuten axe, Lighthouse tai manuaalisilla tarkistuksilla. Validointi on välttämätön ehto, mutta ei riittävä.

Yleisimmät virheet XHTML:n validoinnissa

Kun opit validoimaan XHTML:ää, vältä näitä yleisiä virheitä:

Validoi vain etusivu. Ongelmallinen merkintä on yleensä sisäisissä malleissa.
Ignoraa koodaus. Huonosti määritelty charset tuottaa haamuvirheitä.
Sekoita hyvin muotoiltu ja validi. Ne ovat eri kerroksia; ratkaise ne järjestyksessä.
Käytä väärää validaattoria. vnu XHTML5:lle, DTD XHTML 1.x:lle.
Korjaa kaskadivirheitä lukematta ensimmäistä. Hukkaat aikaa ja korjaat oireita.
Ei automaatiota. Manuaalinen validointi ei kestä toista sprinttiä.
Oletus, että validi = saavutettava. Ne ovat eri standardeja, joilla on eri tarkoitus.

Keskeiset kohdat

XHTML:n validointi koostuu kahdesta kerroksesta: XML-muotoilusta (well-formedness) ja ilmoitetun DTD:n tai skeeman noudattamisesta.
W3C Markup Validation Service ja Nu Html Checker (vnu) ovat viitetyökaluja XHTML:n validoimiseen; xmllint kattaa puhtaan XML-kerroksen.
XHTML 1.0/1.1:lle käytä DTD-validointia; XHTML5:lle käytä vnu:ta ja unohda klassiset DTD:t.
Korjaa virheet ylhäältä alas: ensimmäinen aiheuttaa yleensä seuraavat.
Automatisoi validointi putkistoosi; manuaalinen tarkistus ei skaalaudu.
Validi ei ole synonyymi saavutettavalle: ne ovat toisiaan täydentäviä standardeja, eivät vastaavia.

Lähteet ja lisälukemista

XHTML — Wikipedia: Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup…
XHTML Basic — Wikipedia: XHTML Basic is an XML-based markup language designed for simple user agents with limited computing power, such as early mobile phones, PDAs, pagers, and set-top…

Usein kysytyt kysymykset

Mikä on ero hyvin muotoillun ja validin XHTML:n välillä?

Hyvin muotoiltu dokumentti noudattaa XML:n syntaktisia sääntöjä: suljetut tagit, oikea sisäkkäisyys ja attribuutit lainausmerkeissä. Validi dokumentti kunnioittaa lisäksi ilmoittamaansa DTD:tä tai skeemaa: käyttämällä vain sen kontekstissa sallittuja elementtejä ja attribuutteja. Voit saada hyvin muotoillun mutta invalidin asiakirjan, esimerkiksi jos käytät attribuuttia, jota ei ole olemassa XHTML 1.0 Strictissä.

Onko XHTML:n validoinnilla vielä merkitystä vuonna 2024?

Kyllä, kahdesta syystä. Ensinnäkin monet vanhat projektit tarjoilevat edelleen XHTML:ää ja niiden on pysyttävä valideina, jotta ne eivät rikkoudu XML-tilassa. Toiseksi validointi on kurinalaisuutta, joka havaitsee rakenteellisia virheitä, jotka vaikuttavat saavutettavuuteen ja ylläpitoon. Jos projektisi on uusi, se todennäköisesti käyttää HTML5:ttä tai XHTML5:ttä, mutta validointitapa on silti arvokas.

Mitä validaattoria minun pitäisi käyttää XHTML5:lle?

Nu Html Checker (vnu), joka on saatavilla verkkopalveluna, suoritettavana JAR-tiedostona ja Docker-kuvana. Se on sama moottori, jota moderni W3C Markup Validation Service käyttää, ja se ymmärtää HTML5-syntaksin ja sen XHTML-serialisoinnin. Älä käytä klassisia DTD-validaattoreita XHTML5:lle: ne eivät tunnista data-*-attribuutteja tai muita HTML5-ominaisuuksia.

Miksi W3C-validaattori antaa virheitä, joita en ymmärrä?

Koska monet virheet ovat seurausta edellisestä. Virheellinen sisäkkäisyys voi aiheuttaa kymmeniä toissijaisia viestejä. Oikea strategia on korjata ensimmäinen virhe, validoida uudelleen ja toistaa prosessi. Myös se voi olla syynä, että validaattori soveltaa DOCTYPE:ssä ilmoitettua DTD:tä; jos tuo DTD ei ole se, mitä odotit, virheet vaikuttavat mielivaltaisilta.

Voinko validoida XHTML:ää komentoriviltä?

Kyllä. Jos mietit, kuinka XHTML tarkistetaan CLI:n kautta, xmllint --noout --valid archivo.xhtml tarkistaa rakenteellisen oikeellisuuden ja validiteetin DTD:tä vastaan. HTML5/XHTML5:ssä vnu.jar archivo.xhtml tekee samoin. Molemmat vaihtoehdot ovat ihanteellisia integroitaviksi rakennuskomentosarjoihin, pre-commit hookkeihin tai jatkuviin integrointitöihin, joissa manuaalinen validointi ei skaalaudu.

Onko validi XHTML-sivusto automaattisesti saavutettava?

Ei. Validointi tarkistaa syntaktisen ja skeeman yhdenmukaisuuden; saavutettavuus arvioidaan WCAG:n perusteella, joka kattaa muun muassa kontrastin, näppäimistön navigoinnin, vaihtoehtoisen tekstin tai semanttisen rakenteen. Asiakirja voi olla täysin validi ja silti saavuttamaton. Validoi ensin ja tarkista saavutettavuus sen jälkeen: ne ovat toisiaan täydentäviä kerroksia.

Sertifikaatti en accesibilidad (CPACC/WAS)

La Certificación profesional que acredita tu experiencia en accesibilidad