Mistä johtuu, että ääkköset näkyvät sivulla oudosti, siis näin: "... sähköpostitse ..."?
Eihän pakko ole käyttää ä- ja ö-merkkejä, vaan ä:n ja ö:n pitäisi toimia, mutta miksi joskus moista sotkua esiintyy, ja miten asian voisi korjata?
Eihän pakko ole käyttää ä- ja ö-merkkejä, vaan ä:n ja ö:n pitäisi toimia, mutta miksi joskus moista sotkua esiintyy, ja miten asian voisi korjata?
Vastaukset 4
Vanhimmat
Sivulla on todellisuudessa käytetty UTF-8-koodausta, mutta selain on luullut sivun olevan ISO-8859-1-koodattu. Joko sivu ei ole ilmoittanut käyttämäänsä merkistökoodausta oikein tai sitten selaimen asetukset ovat pielessä.
Jos kyseessä on siis oma sivusi ja selaimessa ei ole vikaa, niin voit ilmoittaa käytetyn koodauksen meta-elementissä:
Toisaalta jos todella halusit käyttää ISO-8859-1-koodausta, niin siinä tapauksessa kannattaa muuttaa editorin asetuksia. (Tällöin myös meta-elementin content-attribuutin loppuun tulee luonnollisesti "charset=iso-8859-1".)
Lisäksi on vielä parempi, jos saat myös palvelimen lähettämään tiedon koodauksesta HTTP-vastauksen otsikkotiedoissa. Tämä johtuu mm. siitä että, palvelimen ilmoittama koodaus ohittaa meta-elementissä ilmoitetun koodauksen, jos kyseiset tiedot ovat ristiriidassa keskenään.
Kiitos.
Kyllähän selain näyttää sen mitä lähdekoodissa lukee, mutta kun lähdekoodissa jostain syystä lukee tuota siansaksaa, vaikka teksti on kirjoitettu normaalein ääkkösin. Onko siis fiksumpaa käyttää UTF-8:a vai Iso-8859-1:tä?
Palvelinta en pääse säätämään.
Ääkköset kyllä toimivat suoraan sellaisenaan molemmissa koodauksissa, joten entiteeteille ei pitäisi olla tarvetta. Tässä tapauksessa vaikuttaisi vähän siltä, että tiedosto on alun perin tallennettu UTF-8-koodattuna ja avattu uudelleen myöhemmin, jolloin editori on olettanut tiedoston olevan ISO-8859-1-koodattu. Luultavasti tässä vaiheessa ääkkösten tilalle on siis ilmestynyt tuota sekamelskaa. Kun lähdekoodi on tallennettu seuraavan kerran, on tiedostoon todella päätynyt merkkijonot ä ja ö merkkien ä ja ö sijaan. Eli loppujen lopuksi tuloksena on saatu ISO-8859-1-koodattu tiedosto, joka ei enää sisälläkään ääkkösiä ollenkaan.
Tämä on siis puhdasta arvailua, mutta jos edellä kuvattu tapahtumaketju todella toteutui, niin ongelma liittyy lähinnä käytettyyn editoriin. Esimerkiksi Crimson Editor luulee kaikkien tiedostojen olevan ISO-8859-1-koodattuja (pikaisen testailun perusteella). Eli aina kun UTF-8-koodattu tiedosto avataan Crimson Editorissa, täytyy päävalikosta valita Document -> Encoding Type -> UTF-8 Encoding, jotta homma toimisi. Tämän takia kannattaa käyttää editoria, joka osaa automaattisesti tunnistaa useita eri merkistökoodauksia. Itse käytän nykyään PSPadia.
Mitä tuohon "UTF-8 vs. ISO-8859-1" -kysymykseen tulee, niin tavallisen länsimaisen tekstin tapauksessa ei ole oikeastaan väliä, kumpaa koodausta käyttää. Suurin ero koodausten välillä on se, että UTF-8:n avulla voidaan esittää suoraan mikä tahansa Unicode-merkki (eli käytännössä mikä tahansa merkki maailmassa). ISO-8859-1:tä käytettäessähän joudutaan turvautumaan entiteetteihin tai numeerisiin merkkiviittauksiin, jos nettisivulla tarvitaan vähänkään erikoisempia merkkejä. Mutta jos sivu sisältää vain tavallista suomenkielistä tekstiä, niin ISO-8859-1-koodattu tiedosto vie jopa hitusen verran vähemmän tilaa, koska jokainen ääkkönen vaatii UTF-8-koodattuna kaksi tavua ja ISO-8859-1-koodattuna vain yhden. Koska ero lopullisessa tavumäärässä on kuitenkin yleensä hyvin pieni ja UTF-8:n käytöstä ei ole varsinaisesti mitään muuta haittaakaan, niin itse käyttäisin (ja käytän) UTF-8:aa.
Suurin hyöty UTF-8:sta saadaan siis silloin, kun yksi ja sama sivu sisältää tekstiä usealla eri kielellä (esim. länsimaisia ja itämaisia yhtä aikaa). Tämä pätee myös tilanteisiin, joissa lomakekenttiin saatetaan syöttää tietoa millä tahansa kielellä. Selaimethan lähettävät lomaketiedot takaisin palvelimelle käyttäen sitä koodausta, mitä itse sivullakin on käytetty. Tietoja käsittelevän skriptin kannalta on helpompaa, jos syötetty teksti saadaan jollakin suoralla tavalla koodattuna. Lisäksi UTF-8-koodattu teksti noudattaa hyvin selkeää bittikuviota, joten tarvittaessa voidaan varsin helposti ja luotettavasti tarkistaa, käyttikö selain todella UTF-8:aa tietojen lähettämiseen.
Jos taas jollakin ISO-8859-1-koodatulla sivulla olevalle lomakkeelle (esim. Suomi24:n keskustelupalstat) syötetään erikoisia merkkejä (esim. ЮІАѦѨѪѬѮѰѲѴѤ), niin ennen tietojen lähettämistä selain joutuu muuttamaan mainitut merkit numeerisiksi merkkiviittauksiksi (numeric character reference, NCR). Tämänkin sivun lähdekoodia vilkaisemalla voi todeta, että tiedosto todella sisältää NCR:iä oikeiden merkkien sijaan. Tästä aiheutuu ainakin muutama rasite:
- Tietoja käsittelevä ohjelma ei voi varmuudella tietää, viittaavatko NCR:t oikeisiin merkkeihin vai halusiko joku todella käyttää sellaisenaan hassuja numerosarjoja &-merkeillä ja puolipisteillä höystettynä (jälkimmäinen on toki harvinaista). Nettisivujen tekoa käsittelevillä foorumeilla tilanne on kuitenkin mahdollinen.
- Jos tiedoille halutaan tehdä muutakin kuin näyttää nettisivuilla (esim. lähettää sähköpostilla), täytyy NCR:t muuttaa oikeiksi merkeiksi jossain vaiheessa. Tällöin jouduttaisiin joka tapauksessa vaihtamaan koodausta.
- NCR:t vievät enemmän tavuja kuin suoraan UTF-8-koodatut merkit.
Luultavasti edellä mainituista syistä johtuen mm. Google, Wikipedia ja YouTube käyttävät UTF-8:aa sivustoillaan.
Niin, ja palvelimeen ei tarvitsekaan välttämättä koskea, sillä aika usein palvelimet eivät ilmoita mitään tietoa koodauksesta HTTP-vastauksessa. Tällöin voidaan siis turvallisesti käyttää pelkkää meta-elementtiä. Joka tapauksessa palvelimen tilanteen voi tarkistaa syöttämällä omien sivujen osoitteen vaikkapa seuraavalle työkalulle: http://cgi.w3.org/cgi-bin/headers (Olennainen kohta on tuloksissa näkyvä Content-Type-rivi.)
Vastauksesi on ainakin riittävän kattava. Vaihdoin merkistökoodauksen nyt UTF-8:ksi. Katotaan miten homma etenee.
Kiitos. :)