Przenoszenie bazy MYSQL - problem z kodowaniem znaków

[kamil_w]

Tworzyłem stronę w Joomli korzystając z movAMPa i wszystko działało pięknie. Stronę ukończyłem, więc przerzuciłem pliki na serwer. Pół sukcesu.
Teraz tak:
1. Przechodzę do panelu PHPmyadmin w movAMPie screen (http://wojcik.neostrada.pl/mysql-problem/stary1.png)
2. Przechodzę do baz danych i wybieram bazę z moją stronką screen (http://wojcik.neostrada.pl/mysql-problem/stary2.png)
3. Po otwarci bazy danych wybieram z menu "Eksport"... screen (http://wojcik.neostrada.pl/mysql-problem/stary3.png)
4. ... i eksportuję do pliku z ustawieniami jak na załączonym obrazku screen (http://wojcik.neostrada.pl/mysql-problem/stary4.png)

OK. Mam już plik "moja_baza.sql" więc biorę się za importowanie zawartości na serwer
1. Przechodzę do panelu PHPmyadmin na serwerze docelowym screen (http://wojcik.neostrada.pl/mysql-problem/nowy1.png)
2. Przechodzę do baz danych i wybieram bazę do której będę importować dane screen (http://wojcik.neostrada.pl/mysql-problem/nowy2.png)
3. Po otwarci bazy danych wybieram z menu "Import"... screen (http://wojcik.neostrada.pl/mysql-problem/nowy3.png)
4. i importuję bazę z wcześniej utworzonego pliku podając do niego ścieżkę i wciskając "Wykonaj" screen (http://wojcik.neostrada.pl/mysql-problem/nowy4.png)

Efekt końcowy? Krzaczki zamiast polskich znaków (http://wojcik.neostrada.pl/mysql-problem/efekt-koncowy.png)

Pomyślałem sobie - Gżegżółka XP pomoże. Odpaliłem więc Gżegżółkę XP, wrzuciłem do niej plik "moja_baza.sql" i dałem "Rozpoznanie"

Efekt? - Kodowanie: nieznane, EOL: LF (Unix)

Otworzyłem więc w/w plik w Notepad++ i zauważyłem, że kodowanie jest ustaiowne na UTF8 (bez BOM). Wybrałem więc z menu "Konwertuj na UTF8" i zapisałem plik.
Wczytałem ponownie plik w Gżegżółce i w rozpoznaniu wyszło:
Kodowanie: Unicode UTF8, EOL: LF (Unix)

Więc teoretycznie powinno być OK.
Przechodzę więc tak jak wyżej ->phpMyAdmin -> Baza danych -> Import. Wybieram przekonwertowny plik i daję "Wykonaj".
W efekcie otrzymuję taki komunikat screen (http://wojcik.neostrada.pl/mysql-problem/komunikat-bledu.png)

Przechodzę więc do głównej strony phpMyAdmin i na liście "System porównywań dla połączeń MYSQL" zmieniam utf8_general_ci na utf8_unicode_ci i wracam do importowania danych. W efekcie otrzymuję identyczny komunikat.

Nie wiem czego jeszcze mogę spróbować. Proszę o pomoc.

[zwiastun]

Czemu teoretycznie powinno być OK?
Teoretycznie i praktycznie: baza jest kodowana w utf-8.
Importuj ja do już założonej bazy, kodowanej w utf-8, wskazując w phpMyAdminie, że plik źródłowy jest kodowany w utf-8. To wszystko, co trzeba

[kamil_w]

Teoretycznie, bo praktycznie jak widać to nie działa. ;/

Jak widać na załączonych obrazkach na bazie danych, do której importuję tabele widnieje utf8_general_ci. Choć jest coś czego nie rozumiem. Wcześniej w tej bazie znajdowały się kolumny ze starej strony, która działała pod PHP-Fusion kodowanym na ISO8859-2. Czyli coś tu nie gra. Baza była kodowana w utf8_general_ci a zawartość strony i bazy w iso859-2 i wszystko śmigało. Ale jakim prawem, to nie wiem ;|

[Jola]

Witam,

Baza była kodowana w utf8_general_ci a zawartość strony i bazy w iso859-2 i wszystko śmigało. Ale jakim prawem, to nie wiem ;|Prawo jest takie, że nadrzędną dyrektywą kodowania znaków jest metoda porównywania napisów ustawiona dla konkretnej kolumny. Jeśli kolumna ma ustawioną metodę porównywania napisów na latin2, to wszystko inne może być ustawione inaczej a i tak właściwie będzie współpracować ze stroną w kodowaniu iso8859-2.
Błąd, o którym piszesz wynika chyba ( na 99%) z nie do końca prawidłowego konwertowania pliku na utf8.
Prawidłowe przekonwertowanie daje taki efekt, że po utwarciu pliku w kodowaniu utf8 nie wyświetlają się krzaczki.
Ale pliku nie widziałam, więc mogę się mylić. :)
Pozdrawiam

[kamil_w]

Problem rozwiązany. Weksportowany plik musiałem odpalić w Notepad++, przekonwertować go do UTF8, odpalić w gżegżółce i w niej przekonwertować do iso8859-2 a potem znów do utf8. Tak przerobiony plik otworzyłem ponownie w Notepadzie++, usunąłem komentarze i na zasadzie kopiuj - wklej przerzuciłem zawartość do SQL'a.
Strasznie to pokręcone, ale jakoś się udało. Jeszcze raz wielkie dzięki dla Joli za pomoc i cierpliwość, która bardzo mi pomogła w rozwiązaniu tego problemu.

[muzyk138]

Problem rozwiązany. Weksportowany plik musiałem odpalić w Notepad++, przekonwertować go do UTF8, odpalić w gżegżółce i w niej przekonwertować do iso8859-2 a potem znów do utf8. Tak przerobiony plik otworzyłem ponownie w Notepadzie++, usunąłem komentarze i na zasadzie kopiuj - wklej przerzuciłem zawartość do SQL'a.
Strasznie to pokręcone, ale jakoś się udało. Jeszcze raz wielkie dzięki dla Joli za pomoc i cierpliwość, która bardzo mi pomogła w rozwiązaniu tego problemu.

Mam podobny problem gdyż chcę przenieść bazę danych z jednego serwera na drugi. Opiszę jak to wygląda.
Na starym serwerze mam bazę danych, gdzie sortowanie połączenie z serwerem jest: utf8_general_ci, natomiast metoda porównywania napisów to: latin1_swedish_ci.
Dalej robię import do pliku sql, gdzie podczas importu wybieram kodoanie znaków pliku: utf-8. Plik zapisany na dysk.

Dalej wchodzę na nowy serwer i nową bazę danych, ustawiam tam połączenie z serwerem na utf8_general_ci i metodę porównywania napisów na latin1_swedish_ci, czyli żeby było tak samo, następnie importuję wcześniej eksportowany plik ze starej bazy i na stronie nie ma polskich znaków tylko krzaczki, gdzie może być problem

[adam.lachut]

Problem może być w różnych wersjach bazy danych - być może na nowym serwerze Joomla nie rozpoznaje że serwer bazy danych obsługuje UTF.
Sprawdź to rozwiązanie:
http://forum.joomla.pl/showthread.php?84509-Krzaki-Joomla/page2

A.