Przyjrzałem się temu zaganieniu bliżej, ponieważ sam natrafiłem na mały "problem", podczas przeoczenia bowiem jak sie później okazało spowodowane to bylo moim niedopatrzeniem (odradzam prace po nocach do rana:D).
Dla wszystkich stęsknionych rozwiązania zagadnienia, ę,ą,ś,ź,Ś,� itp na nazwa.pl podaję niżej co i jak podczas przenoszenia należy wykonać. Naprawdę nic się nikomu nie stanie, jeśli zadba o podstawowe zasady "higieny pracy" z bazami, jeśli można się tak wyrazić.
Otóż, jeśli posiadamy bazę danych, w której jest kodowanie np. latin2, to w przypadku wpisywania znaków w innym kodowaniu będzie ok, ale problem się pojawi jeśli sie zechce przenieść bazę na inny serwer i się zaczną płacze i lamenty (:)) w zasadzie całkowicie nieuzasadnione, gdy się zachowa takie samo kodowanie podczas (uwaga!) zapisu do pliku dumpa.
Dla unaocznienia porobiłem zrzuty ekranu phpmyadmina ode mnie z serwera, oraz w nazwa.pl gdzie też wgrałem bazę:
tutaj jak widać są takie ustawienia, zanim dokonuję jeszcze zrzutu bazy danych:
no i tutaj również takie same, zanim dokona się uploadu (wgrania) dumpa bazy ze starego serwera (wyżej)
a tutaj się odfajkowuje structure i data, czyli struktura tabel oraz dane (uwaga! wlasnie struktura i jej kodowanie gra istotną role)
no a tutaj jeszcze dokonałem zrzutu ekranu aby pokazać jak wyglada baza zaimportowana i porownywanie znakow, które jest ustawione na utf-8 (tak jak powinno, poniewaz wyżej też tak mieliśmy)
Podsumowując:
Należy sprawdzić w jakim kodowaniu jest stara baza danych i w takim samym kodowaniu wykonac dumpa i w takim samym kodowaniu wgrać_baze_danych_ze_starego_serwera.sql
Dla powyższego przykładu podam jak wygląda blednie wygladajacy dump struktury tabel dla tabeli losowo wybranej nr. 1 w paczce mambo.sql:
a tak to powinno wyglądać - na dole ma być charser=utf8, zatem będzie to wyglądać tak:
CREATE TABLE IF NOT EXISTS `mos_akobook` (
`gbid` int(10) NOT NULL auto_increment,
`gbip` varchar(15) NOT NULL default '',
`gbname` varchar(20) NOT NULL default '',
`gbmail` varchar(60) default NULL,
`gbloca` varchar(50) default NULL,
`gbpage` varchar(150) default NULL,
`gbvote` int(10) default NULL,
`gbtext` text NOT NULL,
`gbdate` varchar(20) default NULL,
`gbcomment` text,
`gbedit` enum('y','n') NOT NULL default 'n',
`gbeditdate` datetime default NULL,
`published` tinyint(1) NOT NULL default '0',
`gbicq` varchar(20) default NULL,
`gbaim` varchar(20) default NULL,
`gbmsn` varchar(20) default NULL,
PRIMARY KEY (`gbid`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=5 ;
W każdym razie powodzenia wszystkim życze, na pewno jak zachowacie odrobinę ostrożnosci nie trzeba będzie,
ani ręcznie zmieniać znaków zapytania na polskie znaki ą, ś, ć, ę, ł (:)) itp itd, ani pózniej skrobać się w głowę
dlaczego kiedy zapisuje coś w edytorze na stronie po polsku ę, ą, ś, ł, wyskakują Ci znaki zapytania :) Sposób na rozwiązanie tego
"problemu" jaki przedstawiłem powyżej, jest jednym z najszybszych i najprostszych.
Mam nadzieje, ze ten krótki artykuł komuś pomoże, pozdrawiam i powodzenia
Autorem artykułu jest vj_. Jeśli chcesz możesz rozpowszechniać ten kurs dalej i umieszczać go tylko i wyłącznie na swojej stronie internetowej, jedynym warunkiem jest umieszczenie linka zwrotnego do strony z kursem, albo strony głównej serwisu vj.e.pl
