Drupal költöztetés után ... ő és ű hibák

Sziasztok!

Hirtelen nem tudom, hogy melyik kategoriába volna a helye, de ... ide szúrom be.

A probléma: Egy Drupal alapon futó oldalt költöztettem az egyik szerverről a másikra. Minden rendben is van (kisebb zökkenők után), csak az a gond, hogy az új helyen az ő és ű betük helyett (és csak azok helyett) csak egy-egy kérdőjel jelenik meg.

Ha böngésző kódolásán kezdek állítgatni, akkor csak romlik a helyzet ...

Van valakinek ötlete, hogy mit kellene "megpiszkálni"?

(természetesen az előző helyen minden rendben volt)

Szer

Hozzászólások

tipp: az új helyen az adatbázis más kódolást használ, mint a régin, így a spec karakterek kódja nem egyezik meg a régin, ezért kaptál egy ilyen problémát..

Nézd meg, hogy az előző adatbázis milyen kódolással tárolta az adatokat, és hogy a mostani hogy tárolja..
____________________________________
Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Üllj le és kuss legyen!"..

Igen, én is valami kódolási problémára gyanakodtam.

A kérdés az, hogy hogy tudom megnézni az adatbázis kódolását? (az első helyről származő adatbázisban nem látok semmi erre utaló nyomot, az újban van egy olyan sor , hogy ") ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;", ... így gondolom, hogy latin1-ről van szó)

Próbáltam, hogy amikor feltöltöm az adatbázist, akkor utf-8-at választok, de ... az adatbázisban akkor is a latin1 kiírás jelenik meg.

Ezen én tudok valamit változtatni, vagy ez szerverfüggő?

Sajnos nem oldotta meg a problémát. Márha ha jól csináltam: a régi helyről letöltött adatbázisban a CHARSET=latin1 keres/csere CHARSET=utf8-re. S ezt a - modosított sql filet töltöttem fel az új helyre.

Az eredmény: továbbra is az ő és ű helyett csak egy-egy kérdőjel szerepel :-(

(mindenképp kösz', hogy foglalkoztok a problémámmal!)

Az SQL script kódolása lényegtelen, ez a tárolás módját adja meg. Volt már nekem UTF-8-as MySQL-em latin 2-es gépen. Természetesen az exportált stuff latin 2-es volt.

De egyet lehet még tenni:


$ iconv -f latin2 -t utf8 < exported.sql > newsql.sql

De ez szvsz halott és szenteltvíz esete. Azért egy próbát megér.

Ha latin2-es a dump és latin1-es az új adatbázis, akkor próbáld ki úgy hogy latin1-re alakítod. Komolyan. A PHP és a mysql párbeszéde a kódolás tekintetében nem tökéletes. Gentoo alatt volt erre egy megfelelő PHP patch. Lehet, hogy azóta már bement a mainstream-be is. De a mysql az minden konverziót meg tud csinálni. Szóval szerintem ha latin1 az új adatbázis, akkor - még ha furán hanzik is - alakítsd át a dump-ot latin1-re és úgy töltsd fel.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

nem eleg azt atirni, amugy meg 5os drupal ugy emlekszem, hogy mar eleve valami utf8talanitott verzioban tarolja adatbazisban a stringeket (jol meg is szoptam, mikor szokas szerint nekialltam konvertalni), szoval nem lenne szukseg se a charset, se a kodolas konvertalasara.
ha 4es vagy regebbi drupal, akkor viszont lehet, hogy meg adott charsettel volt siman benne a szoveg a db-ben, akkor viszont kelleni fog egy iconv is a dumpra.

Tyrael

Valoszinuleg a helyzet az, hogy latin1es kodolassal tarolod az adataidat a mysql szerveren, de a dumpban a kodolas latin2. Emiatt szerintem hagyd a latin1-eket latin1-en, es adj meg a dump elejere egy "set names latin2" -t, es igy probald betolteni. (persze atirhatod a latin1-et utf8ra, a lenyeg az, hogy azt is meg kell mondani, hogy az adatok, amiket betolsz, azok milyen kodolassal szerepelnek.)