Törmäsin WPn teemaa asentaessa mielenkiintoiseen ongelmaan. Internet Explorer8 näyttää sivun keskityksen erilailla eli väärin vasemmalle kuin Mozilla Firefox. Oikein olisi keskelle.
Tiedän, että IE on aina ongelmallisempi, mutta kuitenkin yhä yleisin selain. Ja sen, että koodeissa on joitakin selaimia varten esim kulmapyöristyksissä omia ohjeitaan. Mutta koskaan en ole vielä tällaista kekitysasiaa tavannut. Sivustoillani esiintyneet erilaisuudet eri selaimissa ovat ollet aina virheitä koodissa. Kun ne on korjattu, niin näkymät ovat samanlaisia.
Miten nyt periaatteessa on tällainen php sivuston erot eri selaimissa. Ovatko ne yleisiä vai poikkeuksia? Tietysti kovin kiinnostavaa olisi tietää, mistä päin voisi ruveta etsimään koodin tarkistusta, että keskitys toimisi IEssäkin. Kysytty on teeman tekijältäkin, mutta tiedusteluihin vastataan yleensäkin verkkaisesti, jos aina oleenkaan.
Tässä yksi koesivuistani:
http://neptunet.co.cc/wordpress
Mainittakoon, että koesivulla on erilaista tekstien kokeilua, joka ei ole validia. Virhe eri johdu niistä, koska sama on toisessa kohteessa ja eri serverillä ihan puhtaalta pöydältä.
Poista UTF-8 BoM (byte order mark) sivun alusta. Eli tallenna ilman sitä.
Sen lisäksi että se sotkee vähän muitakin selaimia, niin IE pomppaa quirksmodeen eikä standardimoodiinsa.
Tarkoitatko tätä kohtaa:
content="text/html; charset=UTF-8" />
Siinä ei ole BoM merkintöjä ennestään.
BOM eli byte order mark on tiedoston alussa oleva tavusarja (UTF-8:n tapauksessa kolme tavua), jota tekstieditorisi ei näytä mutta joka voi sekoittaa selaimet. Saat sen pois valitsemalla tiedostoa tallentaessasi tallennusmuodon, johon se ei sisälly. Tuon sivun alussa on peräti kolme BOMia peräkkäin, nämä luultavasti tulevat eri PHP-tiedostoista, joita includella liitetään mukaan.
Neptun kirjoitti:
Tarkoitatko tätä kohtaa:
Metatagi ei ole byte-order mark. BoM on tiedoston eka merkki, joka ei yleensä näy editoreissa. Säädä tekstieditoris asetuksista niin, että sitä ei tallenneta.
OK kiitos, tuolla selviän eteenpäin kokeilemaan jos keksin, miten saan tehtyä suodatettuja tiedostoja. Nehän on valmiita paketteja ja tiedostoja, jotka on lähetetty FTP:llä (WinSCP) pelvelimelle. Sillä voi poistaa esim. UTF-8 merkinnät, mutta olisiko se oikein? Kokeilussa olevat tekstitiedostot ovat sitten eri asia. Luuletteko, että riittää teeman sivujen muokkaus, vai pitääkö koko WP käsitellä. Minkä näköinen se merkki eli tavut on eli voiko niitä manuaalisesti etsiä ja poistaa?
Tuota, parasta olisi jos tekstieditorisi ei tekisi niitä ylipäätään, ja tämä ominaisuus pitäisi löytyä Muistiota lukuunottamatta kaikista tekstieditoreista.
Vika on tullut vain sellaiseen tiedostoon, jota olet itse muokannut. Tämmöisen voit bongata helposti esim. tiedoston muokkauspäivämäärästä.
Juu, nyt pääsen jyvälle tuollaisen mahdollisesta syntymisestä, mutta en valitettavsti vielä sen korjaamisesta: Kaikki teeman tiedostot on kaverini lokalisoinut ja sitten antanut edelleen mulle. Ts. tuo neuvomasi keino etsiä muokattuja ei nyt tunnu oikein varmalta. Onko muuta keinoa? Mulla on esim. Expression Web, jolla voisi ehkä nähdä ja korjata niitä kun tietäisi hiukan enemmän millaista lintua metsästää. Omassa käytössä on monta Muistiota monipuolisempaa, kun tietää vain miten säätää vai eivätkö ne tarvitse mitään erityistä säätöä?
Useimmat tekstieditorit eivät oletusarvoisesti tee kyseistä merkkiä, Muistio on ainoa tuntemani, joka tekee.
Voit korjata tiedostoja tällä PHP-skriptillä:
<?php
function poista_utf8_bom($tiedostonimi) {
$data = file_get_contents($tiedostonimi);
if (substr($data, 0, 3) == "\xEF\xBB\xBF") {
file_put_contents($tiedostonimi, substr($data, 3));
}
}
poista_utf8_bom("tiedosto.php");Skripti ei muuta tiedostoa, jos se on jo kunnossa, joten voit huoletta käsitellä vaikka kaikki tekstitiedostot sillä.
Kyseinen BOM-merkki on muuten seuraavissa suluissa: (). Kuten luultavasti huomaat, mitään ei näy, paitsi jos selain ei tunnista merkkiä ja näyttää siitä riemusta jonkin muun merkin (usein �). Jos UTF-8-tiedostoa tulkitaan virheellisesti ISO-8859-1-enkoodattuna, siitä tuleekin kolme merkkiä: ().
Kiitoksia kovasti. Tänään myöhemmin aloitan korjailun. Katselin etusivua ja sen koodeja Expression Webillä. Olivat minusta aivan samantapaisia kuin IE8 Lähdekoodi-näytössä eli mitään erityistä en huomannut. Paitsi että EW huomautteli monen rivin kohadalla, että siinä on lopetusmerkki liikaa. Tuskin kuitenkaan menen niitä muuttamaan.:-)
Muistiosta kiinnostaa, että tekeekö se sen merkin jotenkin automaattisesti, vai onko se jo ennestään olemassa jos esim tehdään Muistiolla lokalisointia alkuperäisiin?
Printtasin ohjeesi varmuuden vuoksi ja hämmästelin, että käyttämäni tekstinkäsittely - tässä Atlantis - asetti kysmysmerkin tuohon sulkujen väliin ja neliömerkin tilalle. Sulkujen välissä tässä foorumiruudussa ei näy mitään. Lienee OK, mutta erikoinen juttu.
Muistio tallentaa sen aina kun tiedoston tallentaa UTF-8:na.
Itse käytän SciTeä, josta löytyy File-valikosta > Encoding viisi eri vaihtoehtoa:
- 8-bit
- UCS-2 Big Endian
- UCS-2 Little Endian
- UTF-8
- UTF-8 Cookie
Tässä 8-bit on Windowsin oletusmerkistö (Windows-1252), sitten nuo kolme valintaa tallentavat Unicodea lisäten tiedoston alkuun byte-order markin ja UTF-8 Cookie on tämä nettisivujen kanssa käytettävä vaihtoehto, joka ei tallenna BoMia tiedoston alkuun. Haittapuoli on se, että joudun itse aina käymään näpräämässä UTF-8 Cookien päälle, koska automaattitunnistusta ei ole. Toisaalta ohjelma on muutoin sopiva omaan käyttööni. Joissakin toisissa ohjelmissa on varmasti asiaa ajateltu tätä paremminkin.
Mielenkiintoinen lisäpiirre: Kun otin esille korjattavat teematiedostot, niin niiden alussa, jotka katsoin, on juuri tuo mainitsemasi "Jos UTF-8-tiedostoa tulkitaan virheellisesti ISO-8859-1-enkoodattuna, siitä tuleekin kolme merkkiä: ()." Niiden alussa näkyy juuri tuo. Tulkitseeko Atlantis tekstinkäsittely ne nyt ISO-8859-1-enkoodattuna?
Koska merkki nyt näkyy, niin kokeilen sen poistoa ensiksi. OK?
Asennan myös neuvomasi SciTen, kokeillaan ja treenataan.
Lisäys:
HURAA! Pelkästään tuo helppo poistotoimenpide auttoi. Nyt sivut on keskitetty ja samalla poistuivat myös etusivun pienet kohdisturvirheet sekä sisällön tekstivirheet, joiden kuvitelin johtuvan ei-validista kokeilusta. Hieno juttu, hyvät neuvot ratkaisivat, niistä kovasti kiitollinen!
BOM virhettä ei muualla sivuillani voi ollakaan, koska en käytä Notepadia ja Atlantis ja muut eivät näköjään sitä asenna. Tässähän oikein kiinnostuu
koodauksen alkeista!
Selitetään vielä tämän asian taustaa hieman. Info voi mennä hieman yli tai sitten ei, mutta ainakin se nyt on tässä.
Vanhoissa tekstitiedostoissa ei ollut minkäänlaista merkintää siitä, mitä merkistöä ne käyttävät. Siispä eri järjestelmillä tallennetut eri merkistöjen tekstitiedostot eivät olleet katseltavissa eri järjestelmällä. DOS:lla tallennettu ääkkösiä sisältänyt tekstitiedosto ei esimerkiksi näkynyt ääkkösten kanssa Windowsissa eri merkistön takia.
Sitten tuli Unicode. Unicodessa määriteltiin yksi merkki kertomaan tavujen järjestys tekstitiedostossa. Tällä tavoin tuli teknisesti helposti mahdolliseksi tunnistaa että kyseessä oli Unicode-tekstitiedosto ja se voitiin avata siten, että merkit näkyivätkin aina oikein. Valitettavasti kaikkiin tilanteisiin tämän merkin lisääminen ei ollut optimaalista, mm. HTML-sivut ovat olleet ongelmallisia. Lisäksi HTML-sivuissa on jo omat keinonsa tunnistaa käytettävä merkistö (palvelimen ilmoittama merkistö sekä sivussa itsessään oleva metatagi; XML-prologi on myös mahdollinen, mutta toistaiseksi pääosin käyttökelvoton IE:n takia XHTML-tiedostoissa). Tämänkin takia BoM oli "turha" HTML-tiedostojen kohdalla.
Näiden vaihtoehtojen lisäksi on mahdollista varmistaa, ovatko kaikki tekstitiedostossa olevat merkit käypää UTF-8:aa. Tämä selviää niistä merkeistä, joiden Unicoden merkkiarvo (code point) on 128 tai isompi, koska tällöin tavuja täytyy käsitellä, jotta varsinainen merkkiarvo saadaan selville tekstitiedostosta. Mikäli näihin merkkeihin ei törmätä, niin sitten tiedosto voi olla myös jokin perinteisempi merkistö kuten ISO-8859-1, pelkkä ASCII tai vaikka DOSin jotain merkistöä. Jos taas tulee virhe, niin sitten tiedostosta tietää että se on varmasti jotain muuta kuin UTF-8:aa. Tätä tunnistusmenetelmää näkee lähinnä irkkiohjelmissa, mutta olen myös omiin ohjelmistoihini alkanut lisäillä merkkivalidaattorin, jottei tietokantaan voi yrittää tallentaa epäkelpoja merkkejä ja siten mahdollisesti paljastu tietoturva-aukkoja.
Kyllä tuo selvitti asiaa ja sen taustaa. Käytännön tasolla kaverini ihmettelee ja on ilmeiseti vähän loukkantunut kun virhe on tullut, vaikka hän on käyttänyt ohjelmointiin erikoistunutta Notepad++ ohjelmaa. En osannut muuta sanoa kuin että ehkä kannattaa tarkistaa sen asetukset.
Onkohan näissä vaativissa wysivyg editoreissa kuten Experssion Webissä merkkivalidaattori kun se tunnistelee muutenkin koodauksen vikoja?
Todennäköisesti niissä ei ole, koska niihin kirjoitettu sisältöhän tulee ns. luotetulta käyttäjältä. Sen sijaan PHP-maailmassa käyttäjän dataan ei pidä luottaa, se pitää varmistaa ettei sieltä satu tulemaan jotain odottamatonta. Käytännössä netin kautta voi tulla mitä tahansa häiriköintiä. Sen takia tieto täytyy pakottaa aina tiettyyn muottiin.
Notepad++:lla tosiaan kannattaa vaan kattoa, että se tallentaa UTF-8:aa ilman BoMia, ei pitäisi olla sen suurempi häikkä.
PHP-tiedoissa BoMeista on muuten se haitta, että jos se löytyy tiedostosta, niin PHP-parseri puskee sen ulos. Ja sitten saadaakiin surullisen kuuluisaa "headers are already sent" -virheilmoitusta :) Vastaavia ongelmia muissakin tapauksissa.
Mielenkiintoista. Voiko tuohon merkkivalidaattoriin ja sen käyttöön tutustua jossakin hiukan tarkemmin?
Tutustu mieluummin UTF-8-enkoodaukseen. Kun sisäistät siitä perusasiat, tiedätkin jo melkein kaiken. Ei tuossa merkkien validoinnissakaan ole kyse mistään sen kummemmasta, tarkistetaan vain, että tiedosto sisältää kelvollista UTF-8-dataa.
Merrin BOM-selostus on hieman ontuva. Ideanahan on siis merkitä 16-bittisessä enkoodauksessa, kummassa järjestyksessä tavut ovat (eli onko luku kirjoitettu vasemmalta oikealle vai oikealta vasemmalle). UTF-8:n kanssa BOMia ei yleisesti katsota tarpeelliseksi, koska sitä luetaan joka tapauksessa tavu kerrallaan, jolloin järjestyksestä ei ole epäselvyyttä. Toki sen läsnäolosta voi varsin luotettavasti tunnistaa tekstitiedoston UTF-8-enkoodatuksi, mutta tähän on muitakin, tiedosto varsinaiseen sisältöön liittyviä keinoja.
Metabolix: BoM esiintyy myös 32-bittisessä tiedostossa, näitä vain näkee aniharvoin 16-bittisen ollessa yleisesti riittäväksi koettu. Ja toisaaltahan Unicode tarvitsee teoriassa "vain" 21-bittiä kaikkien merkkiarvojensa esittämiseen. UTF-8:n ja UTF-7:n kohdalla BoM on tosiaan hyödyllinen vain tunnistamiseen.
Merri kirjoitti:
Metabolix: BoM esiintyy myös 32-bittisessä tiedostossa
Tiedän kyllä tämän, mutta kuten itsekin sanoit, 32-bittiset tiedostot ovat harvinaisia, joten en katso niiden mainitsemista tarpeelliseksi. Lisäksi niissä järjestys voitaisiin käytännössä aina triviaalisti havaita sisällöstä, koska luvun merkitsevin tavu jää kaikissa merkeissä nollaksi.
Merri kirjoitti:
Jos taas tulee virhe, niin sitten tiedostosta tietää että se on varmasti jotain muuta kuin UTF-8:aa.
Voihan kyseessä olla teoriassa muukin virhe, esimerkiksi yksittäinen virhe tiedonsiirrossa tai vioittunut levy.
Örm, tuo on niitä tapauksia joissa täytyy lähteä siitä, että se on vaan sellainen asia jolle ei voi mitään. Jos tiedostossa on muusta syystä virhe, niin sitten se on voi voi, se on käyttäjän ongelma ja sillä selvä.
Yritän tällä hetkellä vieläkin ymmärtää, mikä BoM-selityksessäni oikeastaan ontui, joten kerrataan hieman eri sanoin. BoM = merkki tiedoston alussa, jonka lukemalla tietää minkä muodon Unicodea teksti on. Eikä se ole eksklusiivi UTF-16:lle, mikä on mitä sinun viestistäsi tulee mieleen. Sinänsä se ei edes kerro missä järjestyksessä tavut ovat, vaan se nimenomaan vain kertoo sen enkoodauksen.
Merri kirjoitti:
Örm, tuo on niitä tapauksia joissa täytyy lähteä siitä, että se on vaan sellainen asia jolle ei voi mitään. Jos tiedostossa on muusta syystä virhe, niin sitten se on voi voi, se on käyttäjän ongelma ja sillä selvä.
Itse pitäisin kyllä huonona ohjelmaa, joka päättää että tiedostoa ei voi käsitellä lainkaan UTF8-koodattuna sen takia, että jossain on tullut esimerkiksi yhden bitin virhe ja tulkitsisi siksi, että se ei ole UTF8-tiedosto.
Merri kirjoitti:
BoM = merkki tiedoston alussa ... Sinänsä se ei edes kerro missä järjestyksessä tavut ovat, vaan se nimenomaan vain kertoo sen enkoodauksen.
Öh, no en asiasta tiedä, mutta olettaisin että UFT16 ja UTF32 tiedostoissa se nimenomaan kertoo onko sanan tavut merkitsevin ekana vai vikana. Jos näin ei ole, niin eipä typerämpää nimeä (Byte order Mark) olisi voinut keksiä sille.
Tulee kovasti flametettu olo, mutta...
UTF-8 -tunnistuksen ideana on, että sen sijaan että näytettäisiin tiedosto käyttäen järjestelmän oletusmerkistöä (esim. Windows-1252), niin tarkistetaan voiko tiedoston näyttää UTF-8:na. Näin vaikkapa ihan normaalissa tekstieditorissa. Netin puolella taas syötetystä tekstistä on hyvä muutenkin varmistaa tiedon oikeellisuus, esim. jos systeemi olettaa kaiken tiedon olevan validia UTF-8:aa niin tämä asia on erittäin hyvä myös varmistaa. Jos siellä on virhe, niin sitten siellä on virhe, viallinen merkki/tavu vaikka pudotetaan pois ja sillä selvä. Ei se ole tämän kummempaa!
Se että BoM on nimeltään Byte order Mark, niin se on voi voi. Et ole ensimmäinen joka on sen nimeä kritisoinut. Fakta on että BoM voi löytyä minkä tahansa Unicode-koodatun tiedoston tai tekstistreamin alusta riippumatta enkoodauksesta.
Merri kirjoitti:
Sinänsä se ei edes kerro missä järjestyksessä tavut ovat, vaan se nimenomaan vain kertoo sen enkoodauksen.
Ei, vaan se nimenomaan kertoo tavujen järjestyksen. UTF-16 on kohtalaisen merkittävä enkoodaus, ja sitä nyt sattuu olemaan kahta lajia (kuten tietokoneita muutenkin): little-endian ja big-endian. Enkoodaus siis sinänsä on täsmälleen sama, mutta teknisistä syistä nuo kahden tavun mittaiset merkkikoodit ovat eri järjestyksessä. Siispä toisessa merkki U+FEFF enkoodautuu tavuiksi FE FF ja toisessa tavuiksi FF FE. Enkoodauksen tunnistamiseen on tässä kaksi tapaa: BOMin käyttö (jolloin puhutaan yleisesti UTF-16-enkoodauksesta) tai järjestyksen kertominen erikseen dokumentin ulkopuolella (jolloin voidaan puhua erikseen UTF-16LE- ja UTF-16BE-enkoodauksista). Vastaava pätee myös UTF-32-merkistöön.
Toki sitä voi käyttää myös yleisenä Unicode-tunnisteena, mutta tästä on harvoin mitään iloa: yleensä UTF-8-tiedosto on helppo tunnistaa muutenkin, ja monissa tilanteissa (kuten nyt PHP:n kanssa) ylimääräiset merkit aiheuttavat jopa ongelmia.
Niin, ja samainen merkki on myös käytössä UTF-8, UTF-7 ja UTF-32 -yhteyksissä. Ei sitä huvikseen sinne tiedoston alkuun tallennella, silloin kun se sinne tallennetaan.
Merri kirjoitti:
Ei sitä huvikseen sinne tiedoston alkuun tallennella, silloin kun se sinne tallennetaan.
No UTF-8 ja UTF-7 tapauksissa voisi melkein sanoa että enemmän tai vähemmän huvikseen se tallennetaan, kun kumpikaan ei sitä varsinaisesti tarvitse (ja joskus siitä on jopa ihan haittaa). UTF-32 tapauksessa käsittääkseni sillä on tuo minun ja Metabolixin aikaisemmin mainitsema funktio, kuten UTF-16:llakin.
Jos vaikka tallentaa UTF-8:lla tavallisen tekstitiedoston alkuun, niin se on erittäin hyvä että se on siellä, ainakaan tiedostoa ei sitten yritetä näyttää väärällä merkistöllä.
Haitta tulee vain niissä tapauksissa, kun merkistö tiedetään jo muilla tavoin. Silloin se on erikseen kielletty.
Merri kirjoitti:
Haitta tulee vain niissä tapauksissa, kun merkistö tiedetään jo muilla tavoin.
Jos esimerkiksi PHP-tiedoston alkuun lykkää tuon, niin se aiheuttaa helposti "headers already sent" virheen, eikä tämä nyt ole ainoa esimerkki joka tulisi mieleen. Eli kyllä siitä monennäköistä haittaa voi tulla.
... luetaan sitä keskustelua.
Merri kirjoitti:
Jos vaikka tallentaa UTF-8:lla tavallisen tekstitiedoston alkuun, niin se on erittäin hyvä että se on siellä, ainakaan tiedostoa ei sitten yritetä näyttää väärällä merkistöllä.
Kyllähän se on tästä huolimatta myös aivan validi ISO-8859-1-tiedosto. Toisin sanoen BOM ei vieläkään ole kuin suuntaa-antava vihje, joita UTF-8-tiedostosta on muutenkin saatavissa.
Jos tähän väliin voi sanoa, niin otetaan ohjelmaan UTF-8 enkoodaukseen tutustuminen, katsotaan netistä ja kirjastosta. Mulla onkin haaveena, että jonakin päivänä pystyisin itse tekemään esim. Wordpress teeman. Noin päällisinpuolin tarkasteltuna ei se miltään mahdottomuudelta tunnu ollenkaan, mutta pelisääntöjä täytyy tietää vielä lisää. Näyttää myös siltä, että monet niistä ovat helppoja kopoita joistakin edellisistä, mikä ei ole oma tavoite. Kuitenkin niin, että pyörää ei yrittäisi keksiä uudelleeen.
Omanlaisensa teeman tekeminen on aina haaste, inspiraatioita on aina kiva haeskella netistä. Yksikin varsin erottuva blogi on http://ma.tt/ – pääosin simppeli siellä, missä enempää ei tarvita, muutoin suht näyttävä. Omat graafiset taidot eivät ihan riitä noin hulppeaan lopputulokseen, mutta joitakin perusjuttuja voi napsia asettelusta.
Esimerkki on näyttävä. Teeman itse tekemisessä on mielestäni kyse miten sen persoonallinen ulkonäkö saadaan vastaamaan sisällön tarjontaa. En näe sitä pelkästään upean tai erikoisen näköisen projektin tekemisenä, vaan visuaalisena taustana esiteltäville asioille. Tietysti, jos on kyse esim muotoilusta, taiteesta, musiikista jne niin hyvinkin erikoiset ja näyttävät ovat juuri oikeata visuaalista taustaa.
Expression Webissä on ominaisuuksia, joilla voi ehkä yrittää teemoja tehdä. Kun opaskirjakin on, niin pitäisi joskus tutkia.
Aihe on jo aika vanha, joten et voi enää vastata siihen.