Käyttis Windows XP
Sivu:
<!DOCTYPE html> <html> <head> <title>test</title> <meta http-equiv="Content-Type" content="text/html;charset=UTF-8"> </head> <body> äöä </body> </html>
Testattu selaimilla
Mikään edellämainituista selaimista ei näytä ääkkösiä oikein, vaan korvaa jokaisen �- merkillä. Mistähän johtuu, ja miten saisi korjattua? Kiitos :)
Lisäys: Ja tiedän, että teillä muillä näkyy oikein, olen googlannut jo hyvän tovin :D Mutta toivoisin, että joku osaisi heittää, että miksi juuri minulla ei toimi. Foxin asetuksissa UTF-8 merkistönä, selain itse tosin englannin kielellä.
Lisäys: Okei ongelma on laajempi kuin ajatelin. Toisilla tiedostoilla toimii, toisilla ei, päätteestä riippumatta. Joku ongelma apachessa vamaan..
Ongelma korjaantuu kirjoittamalla tiedosto oikealla merkistöllä. Toisin sanoen tallentaessasi tiedostoasi valitse tekstinkäsittelyohjelmasi valikosta jokin merkistö, joka sisältää aakkoset. Vasta tämän jälkeen voit perehtyä siihen, mitä kirjoitat itse tiedostoon sen merkistöstä.
Määrittäessäsi metassa merkistöksi UTF-8 olethan myös tallentanut kaikki tiedostot koodauksella UTF-8 (without BOM)?
Voit aina vaihtaa tiedoston päätteeksi .php ja lisätä alkuun tämän koodin:
Hei kiitos, en tullutkaan itse ajatelleeksi tuota :) Kokeilen näitä vinkkejä heti maanantaina, kun pääsen niihin tiedostoihin taas käsiksi :P
Othnos kirjoitti:
Määrittäessäsi metassa merkistöksi UTF-8 olethan myös tallentanut kaikki tiedostot koodauksella UTF-8 (without BOM)?
Tuossa on selitys noin 100,1 %:n todennäköisyydellä. Tekstin on kirjoitettu esimerkiksi Notepadilla ja tallennettu oletusasetuksia käyttäen. Silloin tallennusmuoto on windows-1252, ja kun selainparka yrittää tulkita dataa UTF-8:n mukaisena, se löytää tavuja, jotka eivät voi esiintyä UTF-8:ssa ainakaan siinä kontekstissa missä esiintyvät. Tämän se ilmaisee �-merkillä, joka siis tarkoittaa virheellistä merkkidataa (eri asia kuin merkkien puuttuminen fontista).
Asian voi tarkistaa valitsemalla selaimen View- tai Näytä-valikosta merkistökoodauksen ja asettamalla sen windows-1252:ksi, joka voi kulkea esimerkiksi nimellä ”Länsimainen (Windows)”.
Tiedoston tallentaminen UTF-8-muodossa auttaa tällöin. Nykyisin ei ole mitään erityistä syytä jättää tavujärjestysmerkkiä eli BOMia pois, koska se toimii hyödyllisenä indikaattorina siitä, että data on UTF-8:aa. Jos siis on vaihtoehdot ”UTF-8” ja ”UTF-8 (without BOM)”, kannattaa valita edellinen.
Tästä kaikesta riippumatta palvelin voi heittää peliin omat nappulansa. Jos palvelin lähettää Content-Type-otsakkeessa charset-tiedon, se jyrää kaiken muun yli. Tätä sitten voi tai ei voi muuttaa (riippuu palvelimen ylläpidon tekemistä asetuksista) .htaccess-tiedostolla. Otsakkeet saa näkyviin esimerkiksi Chromessa painamalla F12-näppäintä, valitsemalla Network-kohdan ja sen sisällä Headers-välilehden.
Yucca kirjoitti:
Nykyisin ei ole mitään erityistä syytä jättää tavujärjestysmerkkiä eli BOMia pois, koska se toimii hyödyllisenä indikaattorina siitä, että data on UTF-8:aa. Jos siis on vaihtoehdot ”UTF-8” ja ”UTF-8 (without BOM)”, kannattaa valita edellinen.
Paremminkin voisi sanoa, ettei ole mitään erityistä syytä käyttää BOMia. Standardissa sanotaan "Use of a BOM is neither required nor recommended for UTF-8, but may be encountered in contexts where UTF-8 data is converted from other encoding forms that use a BOM or where the BOM is used as a UTF-8 signature."
Yucca kirjoitti:
Nykyisin ei ole mitään erityistä syytä jättää tavujärjestysmerkkiä eli BOMia pois.
Olet aivan väärässä. PHP-koodissa BOM aiheuttaa lukuisia ongelmia.
Metabolix kirjoitti:
Yucca kirjoitti:
Nykyisin ei ole mitään erityistä syytä jättää tavujärjestysmerkkiä eli BOMia pois.
Olet aivan väärässä. PHP-koodissa BOM aiheuttaa lukuisia ongelmia.
Puhe oli HTML-tiedostoista. Kysymys ei maininnut PHP:tä puolella sanallakaan.
Jos ruvetaan puhumaan ohjelmista yleensä, niin mikä tahansa merkki voi aiheuttaa ongelmia jossakin. Jos jollakin ohjelmalla, jolla generoidaan HTML-dokumentteja, ei voi generoida niitä muodossa, jossa UTF-8-muotoinen data alkaa BOMilla, niin se on syytä noteerata ohjelman puutteeksi ja rajoitukseksi. Sama pätee, jos BOMilla alkava PHP-tiedosto aiheuttaa PHP:lle ongelmia.
Eikö konsistenttiys sitten ole mikään syy? Mitä järkeä on tunkea bommia html-tiedostoihin - joita tuskin kukaan edes käyttää enää yhtään missään - kun php ei kuitenkaan sitä salli? No ei yhtään mitään järkeä!
En tiedä, mitä se Jukka taas äskeisessä viestissään ajatteli, mutta minusta tekninen rajoite, johon ei itse voi vaikuttaa, on erittäin hyvä syy olla käyttämättä bom-merkkiä.
Eikä bom-merkin ongelmointi php:n kanssa ole varsinaisesti mikään bugi vaan toivottua käytöstä. Php ei voi koskaan tietää, onko tiedoston alussa oleva bom tarkoitettu lähettäväksi selaimelle vai pitäisikö se filtteröidä pois. Se ei siis voi tehdä sille mitään. Vika on siis loppupeleissä koodarin, kun meni käyttämään bomia tilanteessa, jossa sitä ei olisi saanut käyttää.
The Alchemist kirjoitti:
Eikä bom-merkin ongelmointi php:n kanssa ole varsinaisesti mikään bugi vaan toivottua käytöstä.
No ei se nyt "toivottua käytöstä" ole, mutta kunnollinen UTF8-tuen puute nyt vaan on PHP:n ominaisuus jonka kanssa täytyy elää jos PHP:n valitsee.
Itse käytän Notepad++ ja latin1, joten tallennan aina oikein. :D
Aihe on jo aika vanha, joten et voi enää vastata siihen.