Phpdesigner kérdés: utf-8
A Php Designer szerkesztőt használom. Szeretnék utf-8-as kódolással dolgozni, hogy összhangban legyen a php átal szolgáltatott szöveg az sql-ével, de amikor egy egy php forrásfile-nál beixelem az unicode rublikát, a php nem értelmezi a scriptet. Mit nem értek? :-)
■ 
Unicode != UTF-8
Az UCS-2 a karaktereket két bájton tárolja.
Az UTF-8 az ASCII karaktereket (0-127 kódig) 1 bájton tárolja, aztán vannak karakterek, amiket 2 bájton, meg vannak amiket 3 bájton tárol. (És még vannak az újabb Unicode szabványban szereplők, amiket 4 bájton). A lényege, hogy amíg egy szöveg csak ASCII karaktereket tartalmaz, addig a szöveg ASCII karakterkódolása és az UTF-8 karakterkódolása megegyezik.
A PHP értelmező pedig nem ismeri az UCS-2 vagy UTF-16 kódolást, igazából ASCII-ban várja a programkódot. De az nem okoz problémát, ha UTF-8-ban van a programkód, mivel az UTF-8 úgy lett kitalálva, hogy a több-bájtos karakterek csak 128-255 tartományban lévő bájtokkal vannak kódolva, így nem fordul elő, hogy mondjuk egy é betű kétbájtos kódolásában a " karakternek az ASCII kódja szerepel, ami pl. bezavarhatna a sztringeknél.
A lényeg, hogy PHP esetén UTF-8 nevű kódolást kell keresni, amikor mented a fájlt.
Pontosítok
A következő viszont tényleg pontosabb.
Unicode tárol?
Te nem fogalmazol pontosan, amikor azt írod, hogy "Unicode a memóriában 2 bájton tárol". A memória is ugyanúgy bitek sorozata, ott is valamilyen karakterkódolással kell a karaktereknek kódolva lenniük.
Amit írtál linket, az is azzal van összhangban, amit én írok:
"A Unicode nem karakterek és byte-ok között teremt kapcsolatot, hanem karakterek és nemnegatív egész számok között"
Ehhez még annyit tennék hozzá, hogy a karakterkódolások pedig a nemnegatív egész számok és a byte-ok között teremtenek kapcsolatot.
A programok, amik Unicode elvek szerint működnek, a memóriában többnyire UCS-2 kódolással, tehát valóban karakterenként két bájton tárolják a sztringeket. Ilyen pl. a Java, Javascript, C#. Viszont a PHP nem ilyen! A PHP-ben igazából nincs is túl jó sztringfogalom, amit a PHP-ben sztringnek hívnak, azt a többi nyelvben igazából bájtok tömbjének lehet megfeleltetni. De ennek nincs sok köze ahhoz, hogy a program forráskódja milyen kódolásban is van.
Lemezre többnyire tényleg UTF-8-ban szokás menteni. De a szerkesztőprogram úgy látszik ebben az esetben éppenhogy nem UTF-8-ban mentette a fájlt, hanem UCS-2-ben, amivel a PHP értelmező nem tud mit kezdeni. És a szerkesztőprogram is kissé helytelenül "Unicode kódolásnak" hívja azt, amit valójában UCS-2-nek kéne hívni.
köszi
Ez egy xp alatt futó program. Elképzelhettő, hogy a windows alapértelmezett kódolását használja?
Könnyen elképzelhető.
Pl. a Windows-ba beépített Notepad a következőképpen működik - ahol szintén elég érdekesek a karakterkódolások nevei a mentés ablakban:
- ANSI: ezt választva az aktuális rendszerbeállításoktól függően kerül mentésre a fájl, tehát ha magyar a területi beállítás (itt most nem az operációs rendszer feliratainak a nyelvére gondolok, hanem arra, amit a Vezérlőpultban lehet beállítani), akkor Latin2-ben ment, de ha angol, akkor Latin1-ben. Mivel maga a szerkesztés Unicode alapokon történik, előfordulhat az az eset, hogy olyan karaktert írunk a szövegbe, ami az adott kódolásban nem ábrázolható. Pl. hullámvonalas õ betűt Latin2 kódolással nem lehet menteni, ekkor felajánlja hogy ANSI helyett UTF-8-ban mentsük inkább.
-UTF-8: ekkor UTF-8 kódolás.
-Unicode: ekkor UTF-16 (gyakorlatilag olyasmi mint az UCS-2, itt nem is tudom van-e értelme különbözőséget tenni).
-Unicode big-endian: ez is UTF-16, csak a karakterenkénti két bájt fordított sorrendben van.
És ha UTF-8-at, vagy Unicode-ot választasz, akkor a Notepad, de sok más szerkesztőprogram is úgynevezett BOM-ot, Byte Order Mark-ot rak a fájl elejére, amivel jelzi, hogy milyen kódolásban van a fájl, hogy későbbi megnyitáskor aszerint lehessen értelmezni. Ez persze megnyitás után a szerkesztésnél nem látszik. De ha egy olyan szerkesztőben nyitod meg, ami nem ismeri a BOM-ot, akkor látsz a fájl elején néhány karaktert.
Megnyitásnál pedig ha nincsen BOM, akkor megnézi, hogy értelmezhető-e UTF-8-ként (ugyanis nem minden bitsorozat jelent értelmes UTF-8 kódolást, ami viszont igen, az nagy valószínűséggel tényleg az). Ha értelmezhető UTF-8-ként, akkor UTF-8 szerint nyitja meg, különben ANSI-ként.
de hogyan
A vezérlőpulton a területi beállításoknál, a speciál fülre kattintva találok egy csomó kódolást, amiket ki és be lehet kapcsolni, van is utf-8, be is van pipálva, de pl. az elsőt nem lehet kikapcsolni, ami pedig latin.és még vagy tizet...
mi a hibajelenség?
Ha unikódba teszed, a php nem értelmezi, ugye? Hát akkor ez nem jó módszer.
Ha nem unikódban van, akkor gondolom az ékezetes karakterekkel van gond. De hol? ... csak SQL használat esetén? Simán PHP használatkor nem, ugye? Akkor nem lehet, hogy esetleg az SQL kódlapján kell macerálni?
a hiba
Mint kiderült, az utf-es kódolással nincs baja a PHP értelmezőnek.
Az unicode-dal van, de azt nem használok, ahogy Rici a második hozzászólásban tisztázta, nincs köze az utf-8-hoz.
Van textpad-om, ami ment utf-8-ban, működik is, csak kényelmetlen két szerkesztőt használni, még akkor is, ha külön nyelvi file-ban vannak a szövegek, elkülönítve a logikától.
Az sql-t, a formokat, a meta infókat stb-t már beállítottam.
Szóval apróság, de bosszantó.
Talán másik szerkesztőt kellene használnom, amelyik kiváncsi arra, milyen formátumban mentem a szövegeimet...
még mindig nem írtad le a hibajelenséget
... mert én phpdesigner 2005-öt használok, és nálam nincs semmilyen gond. Ha kiadsz php-n keresztül sql parancsot, amiben ékezetes cucc van, az nem működik?
sql
Rici: kösz. Annyira nem találtam beállítási lehetőséget, hogy írtam a fejlesztőknek. Ha válaszolnak, felrakom a megoldást, hátha más is kínlódik ezzel.
ki kell hámozni
Szóval ha jól értem: egy formba (pl textarea vagy input rész) beleír valamilyen ékezetes szöveget a user, ezt sql-be teszed és ez rögzül/jelenik meg hibásan?
Ha rögzítés előtt kiechozod, vagy a forrásba írsz ékezeteseket akkor normálisan jelenik meg?
Most nem értem: ha ez a hiba, akkor ennek mi köze van a php forrás kódolásához?
... vagy épp fordítva: a formba írt cucc jó, de a forrással paraméterként átadott cucc nem?
(nekem egyikfajta hibajelenség sincs, pedig nem állítgattam a phpdesigneren)
nem tudom miért működik Nálad...
Szóval ha jól értem: egy formba (pl textarea vagy input rész) beleír valamilyen ékezetes szöveget a user, ezt sql-be teszed és ez rögzül/jelenik meg hibásan?
Nem, az sql adatokat jól menti a formokból és jól kapon vissza őket. A probléma a nyelvi file-okkal van, ahol társításos tömbben helyeztem el a magyar nyelvű szöveget, s a php designer nem utf-8-ban menti.
Mint kiderült, jelenleg nincs megoldás erre ebben a programban, így a kérdésemre meg van a válasz: sehogy nem lehet megoldani ezzel a szerkesztővel.
Köszönöm a hozzászólásokat!
Ez nem a win dolga
Az operációs rendszer nem döntheti el egy program helyett, hogy az hogyan mentse a fájljait.
Ha a szerkesztőprogramban nincs ilyesmire lehetőség, akkor várhatsz a következő verzióra, vagy átállhatsz egy másik szerkesztőre.
a megfejtés
There is currently no support for save in you files in utf-8 format. I am working on adding this feature right now!
Best regards,
Michael Pham
Szóval másik szerkesztő .(
nekem miért jó