Mikä hajoittaa xhtml-tiedoston?

[April]

Teen työssäni pieniä nettisivuja harvakseltaan käsin teksturilla - kysynnän kasvaessa tilasin juuri Web Standard -paketin, mutta sitä odotellessa:

Mikä ihme hajottaa xhtml-tiedoston? Pohjalla on virheetön, tarkastettu tiedosto, mutta jos erehdyn ottamaan päivitettävästä tekstistä esim. sähköpostista kopion ja tallennan sen www-tiedostoon, koko sivun koodaus muuttuu ja se näkyy yhtenä aasialaisena kirjoitusmössönä netissä (erityisesti Firefoxilla), vaikka DTD on koskematon ja kyseisessä dokumentissa ei ole puututtu kuin pariin riviin. Argh!

Tallentamisen jälkeen dokumenttiin ilmestyy kauttaaltaan sulkumerkkejä ja koko dokumentin alkuun muutama ``-merkki.

Lisäksi validator ei tunnista esim. ä -merkkiä enää ollenkaan.

Teksturikin ilmoittaa tallennusvaiheessa, että ei ole enää mahdollista tallentaa tekstiä kuin Unicode (UTF-16)-muotoon, oikein herjan kanssa, kun yritin tallentaa päivitystä.

Tällä kertaa virhe aiheutui, kun tein eräälle harrastekerholle sivupäivityksiä. Lisäsin sinne mieheni teksturilla kirjoittaman tiedon copy pastella ja jälleen sama juttu. Kun en millään saa sivua korjattua, jotta se näkyisi eikä aikaa olisi tänään käydä sivua alusta asti rivi riviltä kirjoittamaan Vikaa kun ei saa korjattua poistamalla päivitettyjä rivejä, vaan vika jää pysyvästi kummittelemaan.

Olen käännellyt tieodostoa rtf:ksi ja pelkäksi tekstiksi ja tarkastanut teksturin oletusarvot yms. Koska vika ilmenee noin herkästi, kuvittelisin, että joku täällä tietäisi, mistä on kysymys... Sivun ennätin tallentaa päälle ja siirtää nettiin, ennen kuin huomasin, että taas mättää Joten siis se sivu on nyt julkisesti näkyvillä, kunnes jotain keksin. Safarilla vika ei välttämättä näy: Operalla ja Firefoksilla pahiten.

En haluaisi julkisesti lähettää töitäni tänne näkyville, mutta kovasti mielelläni lähetän sivun osoitteen vaikka yv:nä, jos jotakuta kiinnostaa tutustua ongelmaan, mikäli tämä ei muuten selviä. Melkoista tajunnanvirtaa tämä koko viesti, toivottavasti saa selvää, mitä yritän kysyä.

[Juhani L]

Teen työssäni pieniä nettisivuja harvakseltaan käsin teksturilla - kysynnän kasvaessa tilasin juuri Web Standard -paketin, mutta sitä odotellessa:

Millä teksturilla? Et kai vaan TeXturilla. Hae siinä tapauksessa vaikkapa TextWrangler, ja joutuin, hop hop.

Mikä ihme hajottaa xhtml-tiedoston? Pohjalla on virheetön, tarkastettu tiedosto, mutta jos erehdyn ottamaan päivitettävästä tekstistä esim. sähköpostista kopion ja tallennan sen www-tiedostoon, koko sivun koodaus muuttuu ja se näkyy yhtenä aasialaisena kirjoitusmössönä netissä (erityisesti Firefoxilla), vaikka DTD on koskematon ja kyseisessä dokumentissa ei ole puututtu kuin pariin riviin. Argh!

Työkulku on mahdoton, jos kolmiona on TeXturi, sähköposti ja html-sivut. Tiedät vamaan, miten html-sivuilla määritellään merkkikoodaus. Silloin on syytä käyttää html-sivujen editointiin sopivaa välinettä, vaikkapa TextWrangleria tai Tacoa.

Lisäksi validator ei tunnista esim. ä -merkkiä enää ollenkaan..

Miksi käytät esihistoriallisia entiteettejä? Jos koodaukseksi julistetaan UTF8 ja sitä myös käytetään, nämä ääkköshärpäkkeet on ehdottoman hyvä unohtaa.

[Matti Niemelä]

Ömh, sori en nyt jaksa lukea viestiäsi läpi, mutta tässä pääpointit:

Ongelma: Koska webbiserverit ainakin suomessa lähettää text/html -sivuille oletus-charsettinä iso-8859-1:sen, ei html-tiedoston meta-tagissa määritelty UTF8 koodaus paljon selaimia yleensä kiinnosta.

Korjaus: Käskytä sivun oikeaan headeriin UTF-8 enkoodaus. PHP:ssa tapahtuu esim näin:

Koodi: Valitse kaikki

<?php header("Content-Type: text/html; charset=UTF-8")?>

Tuo pitää tulla ennen kuin mitään lähetetään käyttäjälle.

Ongelma: Editori ja sen merkkikoodaus.

Korjaus: Käytä editoria joka muokkaa sivut aina UTF-8 muodossa. Itse suosittelen ehdottomasti ActiveState Komodo Edit 4.2:sta. PHP:n syntaksivärjäys ja fontti pitää ehdottomasti muuttaa paremmaksi, ja muutenkin ruksia pois niitä autocomplete ja autocheck toimintoja, mutta niiden jälkeen se on mäkkärille aivan loistoeditori (identtinen mäkillä ja winkkarilla).


Unohda se UTF-16 mistä taisit puhua, UTF-8 riittää kaikkeen ja vähään päällekin. Äläkä koodaa ääkkösiä millään HTML -entiteeteillä. Ääkköset sun muut näkyvät jenkkilässäkin oikein jos sivu on oikeasti merkattu UTF-8:ks.

Tietenkin esim linkin href-kentässä tulee &-merkin olla & jne, muuten tulee herjaa. Mutta se onkin eri asia kuin noiden ääkkösten säätäminen.


Nippelitietoa: Lähetätkö content-typenä text/html:n sijaan application/xhtml+xml:n? Nimittäin niin kauan kuin sivun content-type on text/html, selaimet tulkitsevat sivun olevan HTML 4.01:stä. (Näihin ei taas vaikuta se mitä pistät <head>:iin vaan se mitä pistät palvelimen lähettämään sen content-typenä.)

Ongelma tuossa on vaan se, että jos käytät application/xhtml+xml:ää, IE6 ja IE7 näyttää sivun pelkkänä XML-puuna. Joten unohda XHML, tee HTML 4.01 Strictiä. Keskity käytettävyyteen sun muuhun XHTML sijaan.


E: Jos sinulla ei ole mahdollisuus julkaista sivuja PHP:ta tukevalla servulla, mutta .htaccess -tiedosto toimii, voi sillä esim käskyttää palvelinta lähettämään .html -päätteiset tiedostot UTF-8 koodauksella.

[April]

Vaihdan siis TextWranglerin käyttöön (hopi hopi , nyt on) ja kun tallennan sitä kautta, niin varmistan oikean koodauksen save as -> options -> UTF-8 - niinkö?

Pakottaako se selaimet lukemaan ääkkösiä? Pitääkö sen lisäksi varmistaa vielä Cyberduckissa merkkimuunnoskin samaksi ennen kuin siirrän sivut palvelimelle? Syy, miksi olen käyttänyt entiteettejä, on ollut se, ettei ääkköset ole näkyneet iso-8859-1:stä huolimatta - vaan taisipa sekin syy juuri selvitä.

Tuota iso-8859-1:a olen käyttänyt, koska joka mahdollisessa paikassa suositellaan sitä: myös koulussa, kun opettelin sivujen tekoa. Olen jotenkin hämmentynyt. Luulin käyneeni ison 20 opintoviikon www-suunnittelun lisäpalikan graafikon koulutukseeni ja nyt huomaankin, että se oli palikkakoulutusta. Tai siis, kyllähän siellä asiaa tuli paljon - en vain ole itse osannut etsiä oikeanlaista tietoa ja olen toiminut tiedon sijasta olettamuksen pohjalta. No, alussahan tässä vasta ollaan eikä mikään ole mennyt pysyvästi pieleen.

En esimerkiksi tiennyt tai muistanut kuulleeni tuotakaan nippelitietoa content-typestä. Alunperin aloitin sivujen teon 4.01 transitionalilla, mutta olen nähnyt melkoisen vaivan viime kesän ja tämän syksyn aikana, kun olen päivittänyt osaamistani xhtml:n puolelle. Kaikilla foorumeilla hehkutetaan tällä hetkellä xhtml:n puolesta. Käynkö väärillä foorumeilla?

Koska tässä tuli melko paljon hyviä pointteja, uskaltaudun kysymään vielä, onko tässä käyttämässäni tiedoston alussa jotakin erityistä huomautettavaa (paitsi ettei Google ole kiinnostunut avainsanoista yms. meta-tiedoista)?

<!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" lang="fi" xml:lang="fi">

<head>

<title>xx</title>

<meta http-equiv="content-type" content="text/html; charset=iso-8859-1" />
<meta http-equiv="content-language" content="fi" />
<meta http-equiv="content-script-type" content="text/javascript" />
<meta http-equiv="content-style-type" content="text/css" />
<meta name="keywords" content="xx" />
<meta name="description" content="xx" />

<link rel="stylesheet" type="text/css" href="tyylitiedosto.css" media="all" />


</head><body>

[Juhani L]

Vaihdan siis TextWranglerin käyttöön (hopi hopi , nyt on) ja kun tallennan sitä kautta, niin varmistan oikean koodauksen save as -> options -> UTF-8 - niinkö?

Juuri näin.

Pakottaako se selaimet lukemaan ääkkösiä?

Ei pakota. Sen saa aikaan se, että trailerin content-type vastaa sivun sisältöä.

Pitääkö sen lisäksi varmistaa vielä Cyberduckissa merkkimuunnoskin samaksi ennen kuin siirrän sivut palvelimelle? Syy, miksi olen käyttänyt entiteettejä, on ollut se, ettei ääkköset ole näkyneet iso-8859-1:stä huolimatta - vaan taisipa sekin syy juuri selvitä.

Valitettavasti en tiedä, koska en käytä Cyberduckia vaan RBrowseria. Siinä ei ole mitään väliä millään täpällä, kunhan olen sivun tehnyt oikealla tavalla. Aina menee oikein, lähettipä sivuja minne päin tahansa ja olivatpa ne UTF-8:aa tai ISOLatin1:tä.

Tuota iso-8859-1:a olen käyttänyt, koska joka mahdollisessa paikassa suositellaan sitä: myös koulussa, kun opettelin sivujen tekoa. Olen jotenkin hämmentynyt. Luulin käyneeni ison 20 opintoviikon www-suunnittelun lisäpalikan graafikon koulutukseeni ja nyt huomaankin, että se oli palikkakoulutusta. Tai siis, kyllähän siellä asiaa tuli paljon - en vain ole itse osannut etsiä oikeanlaista tietoa ja olen toiminut tiedon sijasta olettamuksen pohjalta. No, alussahan tässä vasta ollaan eikä mikään ole mennyt pysyvästi pieleen.

En esimerkiksi tiennyt tai muistanut kuulleeni tuotakaan nippelitietoa content-typestä. Alunperin aloitin sivujen teon 4.01 transitionalilla, mutta olen nähnyt melkoisen vaivan viime kesän ja tämän syksyn aikana, kun olen päivittänyt osaamistani xhtml:n puolelle. Kaikilla foorumeilla hehkutetaan tällä hetkellä xhtml:n puolesta. Käynkö väärillä foorumeilla?

Kuka on opettanut, että pitäisi käyttää iso-8859-1:tä? Paljon parempi on käyttää aina UTF-8:aa: siinä näkyvät euron merkit ja kaikki ihmeelliset merkit oikein ja sillä tehdyt sivut tulevat kestämään tulevaisuudessa pitkään. Nykyään yleisesti käytettävät käyttikset ja selaimet tukevat kunnolla UTF-8-koodattuja sivuja. On enää todella harvoja käyttäjiä, jotka eivät saa koneellaan UTF-8-koodattuja sivuja auki. Heille kyllä tulee sitä ennen ongelmia jo monesta muustakin asiasta, mm. CSS-tuesta, Flahsista ja Java-skripteistä.

[Matti Niemelä]

Mailmamme ei kyllä IMO tarvi XHTML:ää vielä pitkään aikaan. Sen tuomat hyödyt ovat minimaaliset.

Okei, johan se nyt käytännössä vaatii täysin validin merkkauspuun (tagit suljettu oikein, ja tagit oikeissa paikoissa ylipäätään (<form><input /></form> on strictissä väärin, form-div-input-div-form olisi oikeemmin).

Mutta totuus on että se XHTML rakennetaan ihan yhtälailla aina väärin kuitenkin. Paras se on vaan käyttää 4.01 strictiä, tulee parasta. Ja UTF-8 tietenkin.

Pitää sanoa että tämä HTML+CSS puoli on kyllä se paskin ala opetella koulussa. Sitä kun opettavat ihmiset, jotka eivät ymmärtäneet ohjelmoinnin päälle uravalintojatehdessään ja täten jäivät opettamaan näitä, mistä muutenkin tietävät vain alkeet alasta.

Vaikka esim. XML tukee jossain määrin eri charsettejä, ei PHP5 DOM esim osaa juuri käsitellä kuin UTF-8:na niitä, vaikka kuinka käskee käyttämään latin1:stä. Mutta sen nyt taas on jo eri juttu.

Äyäy. En haluis joutuu opetteleen näit kaikkee uudestaan kyl enää Onneks ei tarvi.