mysql + sumniki

fantje / deklice / strokovnjaki ... pomagajte mi:)

1. selim se na drugi server in imam problem pri bazah ... baze so precej "zjebane" namrec imam pomesano vse od latin1swedishci / utf8slovenianci / latin1generalci ... sedaj pa ko se selim bi zelo rad vse spravil na utf8 in utf8generalci ... vendar ko poizkusam to naresti imam hieroglife namesto pravilnih crk ... predvsem sumniki oz samo sumniki mi delajo probleme ... imate kaksno idejo kaj storiti oz. kako to prestaviti? ... dam za pivo, vecerjo, karkoli samo da resim to zadevo ... so pa 3 strani problematicne ...:)




2. zanima me a te tabele v bazi lahko izbrisem aaggregatetemp1182870600 / taggregatetemp1200588960 in n podobnih imenov? ... zapisi 0 / bytes 0 ...




3. najlepsa hvala za pomoc

2.) Glede tabel ...

http://www.vbulletin.com/forum/showthread.php?p=1506511

1.) Za baze pa, hmm lahko si vse shraniš v SQL file pa potem z beležko popraviš znake in nabore, ali pa če si spišeš/najdeš php skripto, ki bi šla vse tabele skozi in popravila charsete in seveda vsebino polij.

fantje / deklice / strokovnjaki ... pomagajte mi:)

1. selim se na drugi server in imam problem pri bazah ... baze so precej "zjebane" namrec imam pomesano vse od latin1swedishci / utf8slovenianci / latin1generalci ... sedaj pa ko se selim bi zelo rad vse spravil na utf8 in utf8generalci ... vendar ko poizkusam to naresti imam hieroglife namesto pravilnih crk ... predvsem sumniki oz samo sumniki mi delajo probleme ... imate kaksno idejo kaj storiti oz. kako to prestaviti? ... dam za pivo, vecerjo, karkoli samo da resim to zadevo ... so pa 3 strani problematicne ...:)




2. zanima me a te tabele v bazi lahko izbrisem aaggregatetemp1182870600 / taggregatetemp1200588960 in n podobnih imenov? ... zapisi 0 / bytes 0 ...




3. najlepsa hvala za pomoc

Jaz ne bi preveč kompliciral. Prenesi bazo v excel, in poženi Search & Replace :) "čudnih" znakov bi moral imeti natanko 6 (ŽČŠžčš) kar ti ne bo vzelo veliko časa za zamenjavo.

To bi jaz naredil :) odvisno kaj ti je lažje.

Zakaj pa ravno Excel ?

A nebo vredu če shrani v .sql pa odpre z kakšnim text editorjem in zamenja to kar mu ni všeč. :)

pri excelu boš vejerno imel probleme, zaradi kodne tabele, vsaj meni se je to zdaj ravno dogajalo, kosem podatke iz HTML-ja metal v bazo. Zato je vejerno najboljše kakšen text urejevalnik, ki ti omogoča nastavitev kodne tabele (charseta, upam da prav prevajam). Jaz uporabljam wordpad2 za to.

P.

Še toliko bolj zanimivo zakaj je Bakterija to predlagala ? :)

Res, z Excelom so problemi. Jaz delam z Notepad2.

Še toliko bolj zanimivo zakaj je Bakterija to predlagala ? :)

Meni normalno deluje izvoz v excel in nato nazaj v bazo, res pa je da se da narediti tudi drugače.

kaj maš pa za en charset v bazi?

Mogoče tudi jezik nastavljen v Excelu?

samc me je prosil, da mu pomagam pri selitvi, danes sem si vzel cas in eno domeno, ki tece na phpLD, sva ze resila. Za vsak primer, ce bo se kdo kdaj imel tak problem, vam povem kje ta je in kako ga lahko resite.

phpLD sem sicer danes prvic videl od blizu, pa ne vem, kdo je kriv za tabele v latin1 charsetu, phpLD ali cpanel, nisem raziskoval kako poteka instalacija, predvidevam pa, da bi znal biti kriv kar phpLD. Vsekakor pa naslednjic ob instalaciji preverite, ce imate tabele z definiranim charsetom utf8 in ne latin1 ali celo kaj tretjega.

Problem je namrec v tem, da ocitno tisti, ki so phpLD napisali, predvidevajo, da je v MySQL nastavljen default client encoding utf8, pa se jim ocitno nikakor ne ljubi tega zagotoviti ob vsaki povezavi na streznik (vsaj v verziji 3.2.0, ki jo uporablja samc).

Problem lahko resite tako, da nastavite default client encoding na utf8, vendar v tem primeru tvegate, da se bo zmesalo kaksni drugi skripti, pa se verjetno vas vecina nima ravno dostopa do konfuguracij MySQL streznika. Ta moznost torej skoraj v vsakem primeru odpade.

Druga moznost je rocni update skripte, naslednji del kode v datoteki init.php:

if ($db->Connect(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME))

{

   $db->SetFetchMode(ADODB_FETCH_ASSOC);

   $phpldSettings = read_config($db);

}

spremenite v:

if ($db->Connect(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME))

{

   **$db->Execute("SET NAMES 'utf8'");**

   $db->SetFetchMode(ADODB_FETCH_ASSOC);

   $phpldSettings = read_config($db);

}

S tem zagotovite, da streznik ve, da se z vami/skripto (clientom) pogovarja v utf8 character setu (za vedozeljne malo vec branja).

S tem sicer se nismo resili problema podatkov, ki so v napacnih tabelah zapisani v napacnem charsetu. Naredili bomo mysql dump, za katerega bomo poskrbeli, da se bo client na streznik priklopil z encodingom latin1, kar bo povzrocilo, da bomo dobili v dumpu sicer pravilno utf8 kodirane stringe, ki so bili pac zapisani v latin1 tabelah. Zakaj je imel samc probleme s prenosom? Dump je delal iz phpMyAdmina, kjer je pravilno nastavil client encoding na utf8, kar je seveda povzrocilo, da je streznik mislil, da mora iz latin1 character seta podatke pretvoriti v utf8, kar se prej ob streznikovi predpostavki, da se pogovarja s clientom, ki se pogovarja v enakem character setu, seveda ni dogajalo in je skripta navidezno celo pravilno delovala.

Dump sem izvedel takole:

mysqldump --default-character-set=latin1 -u <username> -p <databasename> > phpld.sql

Tisti --default-character-set sicer ni ravno potreben, ker je ravno zaradi latin1 character seta nastal problem, pa vseeno.

Naslednja stvar, ki sem jo naredil, je ta, da sem povsod, kjer bi dump zelel spet kreirati tabele in polja s charsetom latin1, spremenil v utf8, takole:

sed -e 's/latin1/utf8/g' phpld.sql > phpld-utf8.sql

Tukaj smo se sicer lahko zafrknili, ker se lahko tudi v stringih kje nahaja niz 'latin1', pa predvidevajmo, da se ne, drugace bi morali malo bolj motoviliti.

Datoteko phpld-utf8.sql prenesemo na nov streznik in jo uvozimo, takole:

mysql -u <username> -p <databasename> < phpld-utf8.sql

V tej dump datoteki se nahaja ena vrstica, ki poskrbi, da mysql client nastavi pravilni client encoding. Ta vrstica je naslednja:

/*!40101 SET NAMES utf8 */;

Nekaj podobnega smo srecali ze pri "hackanju" phpLDja, kajne? Tisti !40101 je nek MySQLov extension za komentarje, ki povzroci, da se stvari znotraj komentarja vseeno izvedejo kot SQL koda, ce je verzija streznika vecja ali enaka verziji za znakom !, v nasem primeru je to 4.1.1.

Tole ni ravno univerzalni recept za vse probleme s charseti v MySQLu, je pa mogoce vsaj nek material za razumevanje in razmisljanje.

Naslednja je domena z vBulletinom, porocam o izsledkih in resitvah v naslednjih nekaj dneh :)