mySQL/ASP/UTF-8 - naša slova....problem...

ubih se rondajući po netu, forumima i ništa....ajd da pitam...:

baza mysql 5.1.60, MySQL connection collation: utf8_general_ci, prilikom importa .mdb u mysql pod import settings-Character set of the file stajalo je utf8. u mysql bazi vidim (sa Navicat-om) upisana slova šđčćž sve normalno. sve .asp stranice su postavljene na content="text/html; charset=utf-8". međutim kad gledam stranicu dobijam ? umesto ćčđ dok žš vidi normalno.

ima li neko nekakvu ideju? HVALA unapred.

p.s. unapred se izvinjavam ako rešenje već postoji na forumu, ja ga nisam uspeo naći.

Potpis

...da bi ponovo dosli, morate prvo da odete...
http://www.icb.rs

http://www.mysql.rs/2010/07/smece-u-bazi-po-ko-zna-koji-put/

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

pročitah i ništa mi nije jasno šta ja to trebam da uradim, podesim ili već šta da bih rešio moj problem... :)

moje stranice su classic asp ako to uopste ima veze sa ovim. da li je neka i koja intervencija potrebna nad bazom da bih konačno video pravilno sva naša slova?
u bazi su najnormalnije ispisana sva naša slova. nikakvo 'smeće' ili već šta.

hvala.

Potpis

...da bi ponovo dosli, morate prvo da odete...
http://www.icb.rs

da si procitao taj post od pocetka do kraja skontao bi da moras da imas 2 stvari ispravne, podatke u bazi i setovanja svog konektora. obzirom da ti navicat cita podatke ok znaci da ne valja tvoj konektor. onda posle 2 upita na google-u nadjes kako se za asp setuju parametri za mysql konektor

u konektor u asp-u treba da dodas parametar CharSet=utf8;

na primer

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

postavio sam u conn string 'utf8', ali sada ne vidim više niti jedno naše slovo na web stranici.

npr ovako ispisuje reč 'božićne' = 'božićne'

:) hvala unapred za pomoć!

Potpis

...da bi ponovo dosli, morate prvo da odete...
http://www.icb.rs

sada ponovo procitaj onaj tekst o smecu - posto je to ono sto izgleda imas u bazi (i proveri hedere na http strani)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

btw, ako nisi siguran sta ti je u bazi uradi

SELECT HEX(imepolja) FROM tabela;

pa vidi tacno sta pise unutra :)

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

po hexu ispada da su heroglifi umesto naših slova, tj smece....iako navicat vidi polje potpuno normalno sa našim slovima....potpuno sam zbunjen...sa ms access bazom nikada nisam imao ovaj problem...da li bi mozda import podataka iz ms accessa u mysql na neki drugi način (a ne sa alatom Bullzip Ms Access to Mysql) pomoglo? koji je najbolji način za migraciju podataka?

Potpis

...da bi ponovo dosli, morate prvo da odete...
http://www.icb.rs

e da, zanimljivo da mi search pretražuje pravilno sve, pa i čć a prikazuje ? :)

Potpis

...da bi ponovo dosli, morate prvo da odete...
http://www.icb.rs

Umesto



probaj



To je kodna strana za Win latinicu, i najbolje sljaka sa importima iz Access-a.
Probaj ponovo da importujes koristeci ovo podesavanje.

da bazu pre importa preko myphpadmina podesim (MySQL connection collation) na cp1250 a isto i u import settingsima?

Potpis

...da bi ponovo dosli, morate prvo da odete...
http://www.icb.rs

pazi kad ti tamo u onom postu o smecu sve pise, i kako da vidis dal je smece, i kako da to smece prebacis u pravilno sacuvanu datu i ... i ... i ...

navicat ne bi smeo da pravi takve greske, ali sve je moguce...

search ce da radi ako kao search term saljes isto smece

elem, da bi bio siguran da je u bazi smece proveri sta kaze HEX() .. za obicno slovo treba da imas 3 bajta a za akcentovana slova treba da imas 9 bajta u bazi, ako je tako onda ti je unutra smece te treba da ispostujes proceduru iz posta da to prebacis u validnu datu... ako ta procedura nije jasna, reci, sve ostalo je prilicno mlacenje prazne slame, a problem nije do servera vec do klijenta. Brdo klijenata radi po protokolu 10 godina starom, za 3.x i 4.0 mysql server i ocekuju da ti "znas" da sa novijim mysql-om koji podrzava karakter set i kolacije treba da explicitno postavis enkoding konekcije tako da dolazi do tog smeca ... bas zato je problem prezvakan vec 10000 puta po raznim forumima ukljucujuci ovog i nacin da se problem resi objasnjen takodje na brdo blogova, ukljucujuci i moj gde to sve pise i na srpskom ..

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/

A taj encoding za ovo sto tebi treba je cp1250

Postavi ga prilikom importa pa vidi sta ce da bude, jer je najverovatnije greska u tom alatu koji te podatke prebacuje.
Najsigurnije je da stavis i jedno i drugo na cp1250 (i na serveru i u aplikaciji koja importuje), mada i ako na serveru stavis utf8 opet neces imati problema..., najverovatnije je problem aplikacija koja importuje/puni podatke u server.

Znaci na njoj cp1250.
Pozdrav!

ne bas !!!

Encoding u kom je originalno data nije preterano bitan ako je klijent "normalan". Dakle ako ti imas .not konektor kome kazes da mysql-u saljes utf8 datu a on cita CP1520 datu za koju zna da je CP1520 on ce sam tu datu prekonvertovati iz CP1520 u UTF8, poslati mysql-u koji ce to spucati u UTF8 polje. Dakle poenta je da konektor zna "sta salje i kako", bez da ima ikakvih podrazumevanja.

Obzirom da konektor nije imao blage veze sta salje i sta cita on je u bazu poslao CP1520 (mozda, mada mi ž umesto ž deluje kao utf8 !!!) koristeci latin1 enkoding u konekciji...

Unicode ž je 0xC5 0xBE

0xC5 je Latin1: Å
0xBE je Latin1: ¾

Sto se potpuno poklapa sa ovim rezultatima. Dakle nema CP1520 nigde. .not konektor je prekonvertovao ulaznu datu iz cega god u UTF8 i poslao je mysql-u ali na zalost bez toga da je setovao enkoding na UTF8 vec je slao kao Latin1 te se u bazi naslo klasicno smece.

Za proveru HEX() bi za slovo ž iz baze vratio 0x00 0xC3 0x85 0x00 0xC2 0xBE

Potpis

arhimed
http://www.mysql.rs/ | http://elco.crsndoo.com/