Krzaczki, krzaczki i jeszcze raz krzaczki Opcje

[Indeo]

Odkąd sięgam pamięcią mam problem z polskimi znakami przy komunikacji z mysql. Głównie dotyczy to migracji danych między serwerami. Czy ktoś mi może powiedzieć na co zwracać uwagę przy eksportowaniu/importowaniu danych aby dane we właściwy sposób zostały załadowane do docelowej bazy tak, żeby na stronach wyświetlały się poprawnie znaki narodowe?


Mam serwer A ze starą stroną oraz
serwer B, gdzie chcę wszystko przenieść

Exportuję dane z serwera A. Oglądam dane w notatniku - polskie znaki są zapisane w postaci krzaczków, w definicji tabel dopisane jest "DEFAULT CHARSET=latin2"

Importuję dane na serwer B. Na stronie krzaczory. W skrypcie serwisu logującym sie do bazy dopisuję wykonanie zapytania

[SQL] pobierz, plaintext 
SET names latin2
[SQL] pobierz, plaintext 

Krzaczory nadal. To samo robię z utf8 i nadal krzaczory (troche inne)

Loguję się z poziomu wiersza poleceń. Używam różnych "set names xxx". Za każdym razem widzę w wynikach krzaczory podczas gdy wydaje mi sie, że powinny się wyświetlać polskie znaki.


Co jest grane? Co robię źle?

[sf]

Po pierwsze robisz na pałę, zamiast zrozumieć na czym to polega.

W jakim kodowaniu masz zrobioną kopię bazy danych ?
W jakim kodowaniu jest utworzona nowa baza danych ?
W jakim kodowaniu importujesz bazę danych jeśli korzystasz z phpmyadmin ?

Mogę tylko wróżyć, ale jak dla mnie to pierwsza baza najprawdopodobniej miała np. kodowanie latin1, a Ty np tam ładowałeś latin2 lub utf-8 i teraz przy eksporcie może pojawić się syf. Jeśli nie umiesz się połapać to po prostu komuś to zleć, pewnie za 50 pln ktoś się znajdzie, a jak sam chcesz to zrobić to ustal gdzie masz jakie kodowanie.

Acha i notatnik nie jest narzędziem programisty.. zaopatrz się w edytor, który obsługuje różne kodowania.

[Indeo]

Pewnie, że robię na pałę, bo po 5 różnych podejściach nie wiem już czego próbowałem a czego nie
Po pierwsze - czy kodowanie pliku eksportu zależy od serwera z którego pochodzi? Zapewne tak. A może zalezy od dumpującego programu?? Serwer miał kodowanie utf8.
Serwer docelowy też ma kodowanie utf8. Import wykonuję z wiersza poleceń - chyba trudniej o bardziej kompetentne narzędzie? Po imporcie na stronie - krzaczory. Jedyna sytuacja, w której import się udał to import phpmyadminem ze wskazaniem, że importowany plik sql ma kodowanie utf8. Dziś w taki sposób sie udało. Choć phpmyadmin wydaje sie słabym narzędziem do manipulacji dużymi plikami. Co następnym razem? Nie wiem. Domyslam się, że powodem dlaczego import z poziomu wiersza poleceń sie nie udał był brak zdefiniowanego kodowania pliku sql (phpmyadmin sie pytał).
Konwertowanie pliku gżegżółką na niewiele się zdało, bo niezależnie od kodowania i tak konsola pakowała do bazy krzaki.
Co ciekawe - po przekonwertowaniu pliku .SQL z kodowania utf8 na ISO 8859-2 (Europa Środkowa) , gżegżółka plik zaczęła rozpoznawać plik jako Windows 1250 (Europa Środkowa) i ochoczo zaproponowała mi przekodowanie na ISO 8859-2 (Europa Środkowa)
Przerażony oczyma wyobraźni widzę te 3 GB danych z serwera w firmie z tysiącami dokumentów w polach typu blob jak ulegają transformacji, po której już nie tyle, że są krzaczory ale szlag trafia wszystkie binarne dane.

Zatem:
1) jak poinformować konsole, że plik ma określone kodowanie?
2) skoro sprawy kodowania są tak istotne przy migracji danych to dlaczego w pliku eksportu nie ma jednoznacznej informacji o sposobie kodowania pliku tak żeby nie trzeba było go odgadywać? (konsola widać w ogóle nie fatygowała się sprawdzaniem kodowania pliku) tym bardziej frustrujące, że skoro migracja danych ma miejsce między instancjami tego samego programu to twórcy mogliby się wysilić. To tak jakby msword w wersji 10.0 nie umiał otworzyć pliku worda w wersji 6.0, bo nie wiedział jaka to wersja

Co ciekawe w pliku my.ini mam zapis:
default-character-set = utf8

Może za bardzo ironizuję, ale chciałbym poznać zasadę jak się to odbywa.

[Cezar708]

Hmm, a mogę zapytać w jaki sposób Ty widzisz te `krzaczory`? Czy dane oglądasz poprzez phpMyAdmina, czy może poprzez własną aplikację? A może i apache jest nowy?

Kiedyś miałem podobny problem z migracją danych ale okazało się, że serwer miał w httpd.conf ustawione DefaultCharset utf8 i to mi wszystko się przez to krzaczyło.

Pozdrawiam

[Indeo]

Krzaczki generalnie widzę na stronie. Po połączeniu z bazą daję

[SQL] pobierz, plaintext 
SET names latin2
[SQL] pobierz, plaintext 

, bo bez tego są krzaczory. Inne strony na moim serwerze działają poprawnie - np. świeżo zainstalowany joomla, czy phpbb. Dane zawsze oglądam z wielu stron - głównie w wierszu poleceń lub MYSQL-Front'em (świetny program , projekt został zabity przez producenta mysql i odżył jako sql-front, ale poprzedni program był lepszy) Wiem, że sposób wyświetlania na stronie może być uwarunkowany konfiguracją apache i php. Ale ta strona naprawdę poprawnie działała tylko chciałem odświeżyć dane biorąc je z "oryginału" znajdującego się na innym serwerze i wtedy już wyskoczyły krzaczory. Na obecną chwilę jedyny sposób w jaki jestem w stanie wrzucić dane i wyświetlić je poprawnie to użyć phpmyadmina (zamiast konsoli, której zawsze używam) i dopisanie do skryptów łączących się z bazą "set names latin2" (bez tego nadal są krzaczory).

Pytanie brzmi: jak zrobić to za pomocą konsoli (wiersza poleceń). A najlepiej jak to zrobić tak, aby nie musieć dodatkowo dopisywać tego "set names latin2"