Az n billentyű átugrik az oldal navigációhoz. Ugrás a szöveg elejére.
Ez a dokumentum egy fordítás. Bármilyen ellentmondás vagy hiba esetén a legfrissebb angol nyelvű eredeti változatot kell mérvadónak tekinteni. A szerzői jog a W3C tulajdonát képezi, amint az alább látható.
Fordító: Dénes Kohn, Metaphraser - Translation Company
Célközönség: XHTML/HTML kódolóknak, script fejlesztőknek (PHP, JSP, stb.), CSS kódolóknak, XSLT fejlesztőknek, webes projekt vezetőknek és bárkinek aki próbál rájönni hogy miért van üres sor vagy más furcsa karakter az UTF-8-as weboldalán.
Amikor UTF-8-ba kódolt oldalt nézek, néhány böngészőben egy plusz sort vagy nemkívánt karaktert látok a weboldal vagy fájl tetején. Hogyan távolíthatom el ezeket
Ha UTF-8-ba kódolt fájllal van dolgunk, a megjelenítési problémákat okozhatja az UTF-8 jelzés (BOM) jelenléte, amit a böngésző nem ismer fel.
A BOM mindig a fájl elején van, ezért normális esetben a megjelenítési problémákra az oldal tetején számítunk. Azonban emellett üres sorokat is találhatunk ha olyan szöveget illesztünk be egy másik fájlból, ami UTF-8 jelzéssel kezdődik.
Van néhány teszt oldalunk és egy összesítésünk különféle böngésző verziókhoz, hogy láthassuk melyik hogyan kezeli ezt a problémát.
Ez a cikk segít eldönteni hogy az UTF-8 okozza-e a problémánkat. Ha nincs bizonyíték az UTF-8 jelzésre a fájl elején akkor máshol kell keresnünk a megoldást.
Néhány applikáció egy egyéni bájtkombinációt helyez el a fájl elején, így jelezve, hogy a szöveg a fájlban Unicode. Ezt a bájtkombinációt nevezi UTF-8 signature (UTF-8 jelzés/aláírás)-nek vagy Byte Order Mark (BOM)-nak. Néhány program - mint például egy szövegszerkesztő vagy egy böngésző - a BOM-ot extra sorként fogja megjeleníteni a fájlban, míg mások váratlan karakterként, mint például ez: .
Részletesebb információt a BOM-ról a jobb oldalon találhat.
A BOM egy Unicode karakter, ami az U+FEFF résznél található a kódban. Ez egy nulla szélességű sortörés nélküli köz, tehát általában nem látható.
Az UTF-16 és UTF-32 kódolásokban, hacsak nincs valami más alternatív jelzés, a BOM biztosítja a fájl tartalmának a megfelelő értelmezését. Minden karakter a fájlban 2 vagy 4 bájtos adatban van kifejezve és ezeknek a bájtoknak a sorrendje igen jelentős; a BOM jelzi ezt a sorrendet.
Az UTF-8 kódolásban a BOM jelenléte nem olyan lényeges, mint az UTF-16 és UTF-32 kódolásban, mivel ott nincs alternatív bájtsorrend egy karakterben.
Elsőként ellenőriznünk kell, hogy valóban van-e BOM a fájl elején.
Megpróbálhatjuk a tartalmunkban is keresni a BOM-ot, de ha a szerkesztőnk jól kezeli az UTF-8 jelzést, akkor feltehetőleg nem fogjuk látni. Egy szerkesztő, amely nem kezeli jól az UTF-8 jelzést, az a jelzést kifejező bájtokat mutatja az aktuális kódolásnak megfelelő karakterekkel. (A Latin 1 (ISO 8859-1) karakterkódolással a jelzés így fog kinézni: .) Egy bináris szerkesztővel, amely képes a hexadecimális bájtértékeket megjeleníteni, az UTF-8 jelzés így fog kinézni: EF BB BF.
Bizonyos szerkesztők kijelzik, hogy milyen kódolású a fájl, illetve, hogy jelen van-e az UTF-8 jelzés.
Ha nincs jelen, néhány szkript-alapú teszt (lásd alul) segíthet. Esetleg ki lehet próbálni ezt a kis web-alapú programot. (Ha feltehetőleg egy olyan fájl okozza a problémát, amit a PHP vagy más mechanizmus illeszt be, akkor a beillesztett fájl URI-jét kell beírni.)
Ha olyan szerkesztőnk van, ami az UTF-8 jelzést alkotó karaktereket is mutatja, akkor kézzel törölhetjük. Megvan az esély rá azonban, hogy a BOM ott van az elején, mivel nem láttuk.
Ellenőrizzük hogy a szerkesztőnk engedi-e meghatározni vagy az UTF-8 jelzés egy mentés közben lett hozzáadva. Az ilyen szerkesztők lehetőséget biztosítanak az eltávolításra oly módon, hogy behívjuk a fájlt és újra elmentjük. Például, ha a Dreamweaver észleli a BOM-ot, a Mentés Másként ablakban lesz egy opció arra, hogy a BOM-ot tartalmazva mentse el a fájlt. Győzödjünk meg róla, hogy nincs kipipálva és mentsük úgy el.
Az egyik előnye, ha szkriptet használunk, hogy gyorsan eltávolíthatjuk a jelzéseket, akár több fájlból is. Valójában a szkript automatikusan is futhat a folyamat egy részeként. Ha Perl-ben programozunk, használhatjuk ezt az egyszerű szkriptet, amit Martin Dürst készített..
Megjegyzés: Ellenőrizzük a jelzés eltávolításának hatását a folyamatunkban. Lehet hogy néhány része a fejlesztési folyamatnak épp erre az UTF-8 jelzésre támaszkodik. Szintén vegyük figyelembe, hogy a Latin karakteres oldalak nagy része látszólag jól néz ki, de esetenként az ASCII tartományon kívűl eső karakterek (U+0000 - U+007F) helytelenül lehetnek kódolva.
Néhány szövegszerkesztő, mint például a Windows Notepad automatikusan hozzáadja az UTF-8 jelzést bármilyen fájlhoz, amit UTF-8-ban mentünk el.
Egy UTF-8 jelzés a CSS fájl elején néha az első néhány szabály meghiúsulását okozhatja egyes böngészőkben.
Néhány böngészőben az UTF-8 jelzés jelenléte azt váltja ki a böngészőből, hogy az összes szöveget UTF-8-nak értelmezi, az ellentétes kódolás meghatározásától függetlenül.
Mondja el nekünk mit gondol! (Angol).
Angolról fordítva: 2007-07-17. A lefordított verzió utolsó módosítása: 2009-08-14 18:19 GMT
A dokumentum módosításainak a történetéhez keresse ezt az i18n blogban: qa-utf8-bom
Copyright © 2003-2009 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.
Új források