a kezdő szkriptírók nem törődnek a kódolással. Ezért a webhelyeken néha szörnyű rendetlenséget találhat, amikor az adatbázisból származó adatokat egy kódolással kapjuk meg, az oldal egy másikban alakul ki, és a szerver a harmadik. ennek eredményeként, ha az oldal dekódolható, akkor legalább 2-szer. Szóval, miért történik ilyen probléma, és hogyan lehet legyőzni?
az orosz szegmensben leggyakrabban az úgynevezett Windows-kódolást találjuk. másképp nevezzük: windows-1251, cp1251 vagy akár ANS. a következő az utf-8. Az unicode nevet is megtalálhatja, de ez nem teljesen helyes, mivel az Unicode az egész csoport általános neve (utf-8, utf-16, utf-32). és egy nagyon népszerű ritkaság a koi8-r vagy egyszerűen koi-8 - az egyszer népszerű Linux-kódolás. Természetesen az orosz szegmensben is találkozhatunk valamivel, de ez inkább a szerző „kényeztetés”.
A fő különbség az utf-8 és mások között (elsősorban a windows-1251 és a koi8-r) az utolsó egybájt, és a kódolással reprezentálható maximális karakterek száma 256-ra korlátozódik. Magától értetődik, hogy ennek a szövegnek a teljes bemutatásához nem elég. és html esetében találtak megoldást - az úgynevezett mnemonika használatát. például:
© - & copy;
Amellett, hogy mindegyik karaktert egy karaktercsoport írja le, a kód olvashatatlanná válik, és a szöveggel végzett munka bonyolultabb lesz. ez az, ahol a multibyte utf-8 jön a mentésre. nagyon kényelmes a különböző ábécé betűit és a különböző szimbólumokat egy szövegben használni.
Így a kezdeti feltételek legkényelmesebb halmaza a következő: az adatbázis, a php szkriptek és a html oldalak / js parancsfájlok kódolása ugyanaz. Természetesen különbözőeket is használhat, de ebben az esetben fennáll a veszélye annak, hogy összezavarodik. nem számít, hogy melyik kódlapot használja. ha az oldal csak orosz nyelvű közönség számára készült, elég lesz a Windows-1251. egyébként az utf-8 lenne a logikus választás. az első lehetőség többé-kevésbé világos. A multibyte kódoláshoz bizonyos mozdulatokra lesz szükség.
Az utf-8 használatakor a szabványos jegyzettömb jegyzéke nem fog működni ! Az a tény, hogy a szerkesztő ebben a kódolásban egy fájl mentésekor hozzáad egy aláírást az elejéhez - 3 karaktert, az úgynevezett bomot (bájtjelzés), amely a fájl megnyitásakor használható a kódolás meghatározására. jobb választani egy másik szerkesztőt: Notepad2 vagy notepad ++ . a beállításokban meg kell választania, hogy aláírást nélkül mentse.
A következő fontos lépés az adatbázis használata. Nagyon kívánatos, hogy az alap / táblázat / szövegmező kódolása megfeleljen a kódolásnak (lehet cp1251 vagy utf-8, vagy valami más). ha az adatbázisból származó adatokat "zyuk" formájában kapjuk meg, a kapcsolat valószínűleg a kódolása eltér az adatbázisban tárolt adatoktól. A következő lekérdezés segít a helyzet leküzdésében (az adatbázishoz való csatlakozás után azonnal végrehajtható):
ha az oldal Windows-1251-et használ, meg kell adnia - cp1251.
általában nincs semmi nehéz. csak a szabványos php funkciókat úgy tervezték, hogy többszörös karakterláncokkal működjenek. de vannak szabványos könyvtárak, amelyek segítenek a helyesbítésben: iconv és mbstring . rendszeres kifejezések esetén van egy szükséges kapcsoló is, amely az u módosítóval aktiválódik.
Nos, az adatbázis adatai megszerzésre kerülnek, a szkriptek az összes szabály szerint vannak írva. A helyes cím elküldése és az oldal kódjának megjelenítése a felhasználó böngészőjében. így küldünk címet:
fejléc ('Tartalom típusa: text / html; charset = utf-8');
ha egybájtos kódolást használunk, akkor a charset értéke eltérő lesz - windows-1251 . Ezután a problémák nem maradhatnak.
Néhány legegyszerűbb példa az utf-8 használatára php-ben:
1. példa: ikonv, sorok száma
$ s = 'string'; # string in utf-8 $ cnt1 = strlen ($ s); # tartalmazza a $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8') értéket; # helyes érték, 6
2. példa: mbstring, a karakterek száma egy karakterláncban
$ s = 'string'; # string in utf-8 $ cnt1 = strlen ($ s); # tartalmazza a $ 12 cnt2 = mb_strlen ($ s, 'UTF-8') értéket; # helyes érték, 6
3. példa: rendszeres kifejezések, keresés és csere
$ s = 'String'; # sor az utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # csere nem történik meg $ s = preg_replace ('/ p / iu', 'd', $ s); # eredmény szó dokkoló
az i módosító az eset-érzéketlen keresést írja elő, és az u modifikátor elmondja a rendszeres kifejezésmotornak, hogy az utf-8 karakterláncokkal dolgozzon.
ha valaki azt mondja, hogy a php nem működik az utf-8-al, akkor rossz lesz. Már több éve végeztem az összes projektemet ebben a kódolásban, és egyáltalán nem volt probléma. A keresőmotorok már régóta használják ezt a csodálatos kódolást.
Szerzők
offline 11 óra
x64 (más néven andi)
Megjegyzések: 2846 Kiadványok: 395 Regisztráció: 2009-04-02
Szóval, miért történik ilyen probléma, és hogyan lehet legyőzni?