zainstalowałem ostatnio najnowszego mysql'a i nie wiedzieć czemu w phpmyadminie pojawila sie nowa kolumna, we właściwościach / strukturze pola o nazwie "Metoda porównywania napisów", wszędzie o wartości "latin1_swedish_ci", nie mam pojęcia co to jest, a gdy chcę wpisać jakieś polskie znaki w phpmyadminie to zostają one zamienione na "?"

macie w ogole jakieś pojęcie jak to rozwiązać, bo ja nie! tak więc proszę o pomoc, ponieważ nie moge nic robić ze stroną....

wielkie dzięki

Sprawdź czy na stronie głównej phpmyadmin masz ustawione: "Language: Polish (pl-iso-8859-2)"

hehe, tak jasne, tutaj problem tkwi w czym innym, w mysql'u, tylko nie wiem co poustawiac

przyłączam się do problemu, na głównej stronie mam
Language: (pl-utf-8)
innego polskiego nie ma.
Ale właśnie zastanawia mnie jak w temacie, że wszystkie tabele mają róbrykę "Metoda porównywania napisów" w której kodwanie jest "latin1_swedish_ci"

Czemu tak jest? Wcześniej tak nei było...
A po przywróceniu swerwisu z kopii wszędzie mam "?" znak zapytania zamiast polskich znaków.

Czy można/trzeba zmienić te kodowanie "latin1_swedish_ci" na inne i na jakie?
I co to jest te pole "Metoda porównywania napisów" ?

Może ktoś pomóc, wyjaśnić??

Z góry dziękuję

zmarnowałem nad tym prawie cały dzień i.... doszedłem do wniosku ze zainstaluje sobie phpmyadmina 2.5.7 i działa wszystko okej

probowałem ustawiać zmienne $cfg['DefaultLang'], $cfg['Lang'] w pliku konfiguracyjnym ale bez rezultatów.







Tak przy okazji to moj pierwszy post więc witam wszystkich :-)

a poza tym, że zainstalowałeś nowe, to do jakich wniosków doszedłeś

Jeżeli instalujesz MySQL 4.1 na windzie to przy instalacji powinieneś wybrac jako domyślne kodowanie latin2 (czyli odpowiednik iso-8859-2) potem prawdopodobnie istnieje możliwość zmiany tego w jakimś pliku konfiguracyjnym (nie wiem nie patrzyłem).
Wtedy w phpMyAdmin domyślnie metoda porównywania napisów czyli kodowanie, którego używa baza przy wyszukiwaniu danych to latin2 i już nie masz krzaczków ani "?". Ja przy MySQL 4.1.12 używam phpMyAdmin 2.6.2-pl1.

Żeby zaimportować plik sql ze starszych wersji MySQL zakodowanych w iso-8859-2 trzeba przy polu pliku ustawić Zestaw znaków dla pliku: latin2 inaczej będziesz miał w bazie krzaczki.

Jeżeli chodzi o wybór języka w phpMyAdmin to nie ma to żadnego związku z kodowaniem w bazie poza utf-8 nie ma tam nic innego polskiego nie wiem dokładnie jak to działa w każdym razie przy wybranym interfejsie phpMyAdmin na utf-8 i przy domyślnym kodowaniu bazy na latin2 wszystko działa dobrze

Ten serwer jest w necie, ustawione jest tak:

System porównań dla połączenia MySQL: utf8_general_ci
System porównań (w tabeli): latin1_swedish_ci

I w tym momencie jak dodaje jakies polskie znaki przez phpmyadmin to wyskakują praktycznie same znaki zapytania...

Pomóżcie!

hmm zainstalowałem starszy skrypt phpadmina, raz ze działa dobrze dwa ze mi sie bardziej podoba stary skrypt.


Wg problem tkwi nie w mysqlu tylko w phpMyAdminie. Imho znaki ktore trafiają do bazy zależą od kodowania jakie jest ustawione w phpMyAdminie, a ze w 2 wersjach 2.6.0 i bodajze 2.6.3 jakimś cudem nie mozna ustawic kodowania znaków phpMyadmina na iso-8859-2 tylko możliwe jest wybranie któregos kodowania UTF8, dlatego MySql zamienia znaki na "?".

Już doszedłem o co chodzi...

W MySQL'u trzeba wybrać:

System porównań dla połączenia MySQL: utf8_general_ci
System porównań (w tabeli): latin1_swedish_ci

Natomiast w skryptach po łączeniu się za bazą trzeba dodać:

[PHP] pobierz, plaintext 
<?php
mysql_query ("SET NAMES latin1");
?>
[PHP] pobierz, plaintext 

Moze jeszcze pojawić sie problem z dodawaniem w phpmyadmin.... to wtedy wystarczy zrobic skrypt w php i ładnie dodaje... żeby byly polskie znaki... Chyba tylko "ź" nie działa...

W pliku my.ini w windows w katalogu [dysk:\windows] pod pod linux'em musisz poszuakc bo nie pamietam

musisz ustawic na:

# The MySQL server
[mysqld]
default-character-set=latin2

[client]
default-character-set=latin2

Ponadto dla kazdej kolumny mozesz zmienic sytem porownan dla danej tabeli poprzez edycje jej i zmiane na odpowiednia wartosc

Witam.

Ja również borykam się z problemem kodowania polskich ogonków w MySQL. Podłapałem myśl yvana, że to phpMyAdmin jest winien i zrobiłem mały test.

Mając plik *.sql wyeksportowany przez phpMyAdmin2.6.0-pl2 z bazy MySQL 4.0.x, zaimportowałem go z konsoli komendą "source /ścieżka/do/pliku/*.sql;" (wcześniej w konsoli wydajemy komendę "mysql", co wywoła znak zachęty MySQL'a) do bazy MySQL 4.1.12.

Okazało się, że w bazie danych (przeglądanej przy pomocy phpMyAdmin) polskie znaki nie są już przedstawiane jako pytajniki, ale za pomocą innych znaków - nieogonków. Oto niektóre z nich: ³ - ł, ± - ą, ê - ę, ¶ - ś, æ - ć, ñ - ń ...
Natomiast w przeglądarce jest wszystko w porządku, tam gdzie mają być polskie znaki, są polskie znaki.

I teraz pojawia się kolejny problem: co się stanie, gdy wyeksportujemy powyższą bazę z MySQL 4.1.12 do pliku? W moim przypadku pojawiły się krzaczki nowego rodzaju, które po zaimportowaniu z powrotem oczywiście takie zostały i źle się wyświetlają.

Podsumowując, import z konsoli, omijający phpMyAdmin, nie jest to dobre rozwiązanie.
Pokazuje jednocześnie, że rzeczywiście phpMyAdmin bierze udział w problemie polskich znaków.

Pozdrawiam

Ostatnio pojawilo sie wiele problemow z kodawaniem. Nowe wersje mysql i phpmyadmin wprowadzily troche zamieszanie. Nie inaczej jest u mnie. Mam strone i ponad 60 tabel w bazie na jakims serwerze. Wyekportowalem baze, ale po imporcie jej przez adminow pozostaly krzaki - generalnie: stringi pozostaly w kodowaniu utf-8 (unicode) a dluze teksty zapisane binarnie w latin2. Dziwna sprawa, admini serwerka powiedzieli, ze to nie ich wina...dlugo myslalem, co by tu zrobic, podeslalem im cala baze skonwertowana za pomoca Pajaczka. Gdy wrzucalem pojedynczo rekordy przez phpmyadmina przy zestawie znakow dla pliku utf-8 - wszystko bylo ok. Niestety tak duzego pliku nie moge sam wgrac ze wzgledu na zrywanie polaczenia, itp (30 MB) - jedyny sposob, to podrzucenie go adminom...niestety sa tak zje*** ze nie zrobili tego przez 3 dni...strona lezy 5 dni offline Teraz nawet nie wiem, czy to by zadzialalo - jesli laskawi byliby ta baze wrzucic....wszystkich tabel i pol nie ma co poprawiac za pomoca select, update - latwo sie pomylic, albo cos przeoczyc, moze ktos wie, jak automatycznie wszystkie pola ze wszystkich tabel potraktowac jakas funkcja ?

Dla wszystkich majacych podobny problem: ustawienie w bazie powinno byc na latin2, przez to, ze bylo na utf-8 zle sie wyeksportowalo, porownywanie napisow na latin2_general_ci....
Jesli juz masz zly plik z baza - mozna sprobowac go przekonwertowac za pomoca Pajaczka lub programu Gżegżółka. Mam tez gotowa funkcje - dzialajaca (po testach), zamieniajaca te krzaki:

[PHP] pobierz, plaintext 
<?php
 
function utf82iso88592($tekscik) {
	 $tekscik = str_replace("xC4x85", 'ą', $tekscik);
	 $tekscik = str_replace("xC4x84", 'Ą', $tekscik);
	 $tekscik = str_replace("xC4x87", 'ć', $tekscik);
	 $tekscik = str_replace("xC4x86", 'Ć', $tekscik);
	 $tekscik = str_replace("xC4x99", 'ę', $tekscik);
	 $tekscik = str_replace("xC4x98", '', $tekscik);
	 $tekscik = str_replace("xC5x82", 'ł', $tekscik);
	 $tekscik = str_replace("xC5x81", 'Ł', $tekscik);
	 $tekscik = str_replace("xC5x84", 'ń', $tekscik);   
	 $tekscik = str_replace("xC5x83", 'Ń', $tekscik);
	 $tekscik = str_replace("xC3xB3", 'ó', $tekscik);
	 $tekscik = str_replace("xC3x93", 'Ó', $tekscik);
	 $tekscik = str_replace("xC5x9B", 'ś', $tekscik);
	 $tekscik = str_replace("xC5x9A", 'Ś', $tekscik);
	 $tekscik = str_replace("xC5xBC", 'ż', $tekscik);
	 $tekscik = str_replace("xC5xBB", 'Ż', $tekscik);
	 $tekscik = str_replace("xC5xBA", 'ź', $tekscik);
	 $tekscik = str_replace("xC5xB9", 'Ź', $tekscik);
	 return $tekscik;
} 
 
?>
[PHP] pobierz, plaintext 

Od razu mowie, ze script nie jest mojego autorstwa i znaleziony w I-necie, jedyna zmiana jaka dokonalem, to wstawienie polskich znakow zamiast ich dziesietnych odpowiednikow, bo z tym tez byly problemy....

Jesli ktos moze podac sposob jak ta funkcja potraktowac wszystkie pola z wszystkich tabel (albo tylko stringi), prosze o rozwiazanie.

Mam nadzieje, ze mimo wszystko komus moje rozwazania sie przydadza

Witka


Dzieki za podsunięcie pomysłu ze starszym phpmyadminem, bardzo mi pomógł i paru siwych włosów oszczędził

problem miałem taki sam na serwerze kupionym kilka dni temu (nie wiem czy wypada/wolno podawać co to za firma) -

phpmyadmin tam zainstalowany nie miał do wyboru opcji języka pl-iso-8859-2 i po imporcie bazy wcześniej wyeksportowanej z poprzedniego serwera (i sprawdzonej grzegżółką oraz PL-Konwerterem, że jest w 100% ISO) miałęm właśnie ? zamiast pl znaków.

Próbowałem nawet podmieniać URL (a właściwie końcówkę) tak żeby wymusić znaki w iso-8859-2, przy imporcie wybierałem zestaw latin2 dla pliku itd... Po wyeksportowaniu bazy z tego nowego serwera programy do konwersji głupiały podawały mi raz zestaw znaków utf-8 raz AtariST (to PL-Konwerter, który nie widzi utf) , raz ISO (to kED)...

Co dziwne u mnie również pomogło wgranie 'swojego' phpmyadmina 2.5.7 - w nim od razu miałem właściwy lang ustawiony, import bazy powiódł się i pl znaczki są poprawnie zakodowane. Niemniej system porównań jest wszędzie ustawiony na latin1_swedish_ci i nie bardzo wiem czy nie niesie to jakichś konsekwencji późniejszych... dodałem już dane do tej bazy za pomocą interfejsu www (oscommerce) i jest ok...

Na koniec jeszcze raz dzięki .

Aby korzystać z polskich znaków w standardzie iso-8859-2 w środowiku pod windą należy :
1) w konfigu Apache wyrzucić linie AddDefaultCharset ISO-8859-1
2) system porównań dla bazy i tabel ustawić na latin2_general_ci
3) w kodzie php, odrazu po połączeniu z bazą wykonać dwie komendy (tak jak zwykłego SQL'a)

[SQL] pobierz, plaintext 
SET CHARACTER SET latin2;
SET collation_connection = latin2_general_ci;
[SQL] pobierz, plaintext 

4) w samym headerze strony oczywiscie charset = iso-8859-2


W ten sposób dla sesji z mysql mamy ustawione odpowiednie kodowanie , pozwalająe na używanie PL znaków przy wyświetlaniu i dodawaniu danych.

witam! nowy jestem
dzieki za skrypt. pół dnia straciłem.

To moj pierwszy post tutaj, wiec witam!

Czy jesli mam wykupiony serwer, czyli nie mam tego wszystkiego u siebie na localhoscie, to tez moge przeinstalowac phpMyAdmina? A jesli tak, to jak to zrobic? (Wybaczcie, ale jestem blondynka i po prostu sie na tym nie znam ).

Właśnie zmieniłem firmę hostingową i miałem ten sam problem ...
Synaps ... sposób działa rewelacyjnie i sprawdza się nienagannie

Nevermore ... jeśli nie masz dostępu do źrodła samego phpMA to tylko admin może go przeinstalować.

Natomiast ty możesz zamontować sobie własnego: http://www.phpmyadmin.net lub http://sourceforge.net/projects/phpmyadmin

Pozdrowionka

Spoko, juz sobie poradzilam. Wszystko jest tu! (Post dzola).

Skopiuje tutaj, gdyby ktos mial podobny problem. Sprawdzilam na sobie, procedura w 100% skuteczna:

Także borykałem się z tym problemem, U siebie mam MySQL 4.1 oraz phpMyAdmin 2.6.0pl3. Na serwerze zaś MySQL jest w wersji 4.0.24 i pojawiał się problem z kodowaniem polskich znaków podczas eksportowania tabeli.
Po paru eksperymentach doszedlem do wniosku, że problem tkwi w kodowaniu pliku eksportowanego. Kodowanie to UTF8, gdy tymczasem mamy ustawione w bazie latin2. To co wystarczy zrobić to otworzyć ten plik *.SQL w Wordzie (tak tak), wybrać kodowanie UTF8 podczas otwierania. Potem zaznaczyć cały tekst i skopiować go do... notatnika (nie pamięta informacji o kodowaniiu ) a on nam zapisze już w latin2 (czyli nasze upragnione ISO ).
Sprawdzone również dla phpMyAdmin 2.7.0 (które BTW ma opcję eksportu do wcześniejszej wersji MySQL - ale wciąż pozostaje porblem z kodowaniem)

Witam wszystkich,
podobny problem mam i walczylem z nim pol roku temu ale skorzystalem z

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

przy każdym łączeniu i o sprawie zapomniałem.

Teraz mnie znowu naszło i walcze 3ci dzień, stwierdziłem, że po kiego wała za każdym razem upychać takei zapytanie, w dodatku mam troche klas których niechce mi się całych rozgrzebywać po to żeby powciskać w 5ciu miejscach to zapytanie.
No i probuje ustawić po ludzku tego MySQLa, już mi się wydawało, że się udało konsolowe(winxp) mysql i mysqld maja poustawiane

i śmigają elegancko, globalne i sesujne zmienne wszystkie na latin2 jak trzeba, tylko przy laczeniu sie php , dla sesyjnych mam:


co ciekawsze globalne wsyzstkie na latin2.

Ktoś może pomóc, doradzić oco moze chodzić?
pozdrawiam

PS probowalem rowniez ustawiac z init_connect w my.ini dla [mysql][mysqld][client] ale php widzi te zmienne jako calkiem puste

a jak wykonać takie polecenie"

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

dla jednej tabeli?

a tak w ogóle jak biorę taką kwesię to wyskauje mi komunikat typu

[SQL] pobierz, plaintext 
Unknown character SET latin2
[SQL] pobierz, plaintext 

czy biorę w cudysłów czy bez te latin2 zawsze ten sam komunikat

ja mam z deczka inny problem, zainstalowalem serwa i kodowanie bylo nieciekawe, zamiast polskich czcionek to w bazie ?

mam php4, MySQL 4.1.10, phpMyAdmin 2.6.4-pl4

dodalem latin2 do mysql, ale phpmyadmin dalej krzaczyl, dodalem latin2 do clienta i wszystko jest pieknie w mysql, edycja w phpmyadmin dziala dobrze znaczki dobre sa, natomiast php ciagnie zle to i zamiast ogonkow sa ?, mimo, ze w bazie, z ktorej pobiera jest dobrze.

czyli cos nie tak z kodowaniem php, bo np. tutaj nawet sortuje po literach S, Ś, tyle, że php nie wyświetla ich poprawnie

co to może być??

hmm odświeże ten temat bo tak go czytam i ja np dalej mam lipe z tym w sql wszystkie tabele i kolumny tabeli mają ustawione kodowanie na latin2_gerne_ci (czy jakoś tak się pisze ) a mimo to jak dodaje dane do bazy i jak je odczytuje to są same krzczaki. w bazie jak przez phpmyadmina dam żeby pokazał zawartość to mam [blob -8bitów] ale jak dam edytuj to dane są poprawnie zapisane czy może mi ktoś pomóc i powiedzieć co zrobić żeby to wszystko zadziałało ładnie i nie było tych krzaczków bo to wygląda nadzwyczaj nieładnie ;/

proponuje zajrzec do manuala mysqla , zlote rady z nieba nie spadna a tam wszystko jest opisane i o character setach i collacjach

tez mam z tym problem ale wina lezy prawie na 90% po stronie phpma bo na konsoli wszystko gra.

Co do source, to proponuje raczej wklejac niz tego uzywac bo przy ktorejs wersji ta komende walilo kodowanie mimo dobrych ustwien.

Pewne jest to ze baza musi dzialac na latin2, domyslne collation to latin2_general_ci i zadne inne do latin2 dla polakow nie pasuje.

Caly problem tak na prawde jest banalny
1. Eksportujecie baze danych ze starszego phpmyadmina.
2. Tworzycie nowa baze danych na serwerze na ktorym chcecie ja umiescic (w phpmyadmin)
3. Importujecie baze danych klikajac na przycisk (SQL) i na tej zakladce na dole zaznaczacie "System kodowanie znaków dla pliku:" na: "latin2" - domyslnie jest UTF8 - ale koniecznie musicie to zmienic na latin2.
4. klikacie na "wykonaj"
5. i po problemie, MUSZA BYC polskie znaki

Hej, chyle czola!!
Naczytalem sie jak dziki po wszystkich forach o tej tematyce jak uporac sie z tym problemem, a tu masz, takie banalne rozwiazanie!!

DZIALA! Aczkolwiek dla innych rada. Kopiowanie plikow z baza wiekszych niz 3 MB moze sprawic komputerkowi powazne problemy, warto pomyslec nad ta opcja zanim sprobujecie skopiowac 10 MB baze ;-)

Pozdrawiam,
Kaczor

Rozumiem że ten kod php będzie wykonywany za każdym razem. Jak to wpływa na wydajność?

Wydajność spadnie o całe 0,0002 sekundy. Boże zatrzymaj świat bo ja wysiadam

Jeśli nie chcecie za każdym razem dodawać tego kodu php do stron sprobójcie w swój plik my.cnf wrzucić coś takiego:

Hej,

Ja sobie wrzucilem w bazie utf8_general_ci ktore wg mnie powinno glownym z naszego p.widzenia systemem porownan. Caly mysql chodzi na utf-8.

I teraz jak do Anielki uzyskac polskie fonty w PMA Wszystko co sie dalo w ustawieniach ustawilem na UTF-8 i dupa z tego

@NuLL:
PMA - strona główna - ustawienia:
Language: Polish (pl-utf-8)
System kodowania znaków dla MySQL: UTF-8 Unicode (utf8) <- to jest nieustawialne z poziomu interfejsu, może w configu? nie wiem...
System porównań dla połączenia MySQL: utf8_general_ci

Baza:
System porównań: utf8_general_ci

Tabela:
System porównań: utf8_general_ci

Pole VARCHAR w tabeli:
System porównań: utf8_general_ci

wpisując dane za pośrednictwem PMA - wszystkie znaki są OK
pobierając dane za pośrednictwem php - wszystkie znaki są OK
dodawanie danych przez php - wszystkie znaki OK

w pliku php:

[PHP] pobierz, plaintext 
<?php
header('Content-type:text/html; charset=UTF-8');
// po mysql_connect i mysql_select_db
mysql_query('SET CHARACTER SET utf8');
?>
[PHP] pobierz, plaintext 

kodowanie pliku php: UTF8

przy takich ustawieniach u mnie wszystkie znaki widzę poprawnie w PMA i przez php.
moze ewentualnie

[PHP] pobierz, plaintext 
<?php
ini_set('default_charset', 'UTF-8');
?>
[PHP] pobierz, plaintext 

coś pomoże, chociaż jeżeli chodzi o MySQL to chyba nie...

pozdr.

Mój plik my.ini:


I za każdym razem po połączeniu z bazą danych (w skryptach php) muszę dawać

[PHP] pobierz, plaintext 
<?php
$query = 'SET NAMES latin2';
$result = mysql_query($query);
?>
[PHP] pobierz, plaintext 

Nie da się tak zrobić, żebym nie musiał w każdym skrypcie tego pisać?

Miałem ostatnio troche podobny problem, a mianowicie po exporcie bazy poleceniem

miałem w tym pliku znaki zapytania zamiast polskich znaków. I nie były to polskie znaki inaczej zakodowane - mysqldump zamienił bezpardonowo wszystkie polskie znaki na zwykły znak zapytania (kod 0x3f). Oczywiście o imporcie takiego pliku nie ma co rozmawiać bo wiadomo, że to z góry przegrana walka.

W moim przypadku pomogło ustawienie kodowania przy exporcie na... latin1, a przy imporcie (już z pliku z normalnie zakodowanymi znakami) na latin2. To rozwiązało problem polskich znaków.
Całość wyglądała tak:

- export


- import


Generalnie ważne są dwie rzeczy:
1) aby plik został poprawnie wyexportowany, innymi słowy aby polskie znaki były zakodowane w jakimś (mniejsza z tym jakim bo to ma znaczenie dopiero przy imporcie) kodowaniu, a nie zamienione na zwykły znak zapytania, bo wtedy wszystkie polskie znaki zamieniają swój kod na 0x3f i już ich nie odzyskamy.
2) aby plik został zaimportowany z właściwym kodowaniem zależnym od kodowania pliku.

Pomijam tutaj ustawienia mysql-a i kodowania samej bazy bo to już indywidualna kwestia każdego administratora.

Mam nadzieję że komuś to pomoże i zaoszczędzi trochę czasu i nerwów przy przeprowadzce i odzyskiwaniu danych z kopii zapasowej bazy.
Pozdrawiam.

postanowiłem odświeżyć temat, jako że sam miałem podobny problem...
a że sobie poradziłem, to dam kilka wskazówek, które sam zauważyłem...

w moim przypadku konkretnie była to przesiadka z mysqla < 4.0 na 4.1, w sumie bez mojej wiedzy (sharehosting)

z samą stroną problemów nie było (konkretnie chodzi o forum phpbb), problem pojawił się przy próbie przejścia na nowy serwer... oczywiście nowy phpmyadmin pozmieniał kodowanie przy eksporcie bazy, a jako że w bazie były przechowywane dane w iso 8859-2 (latin2), a baza była ustawiona na latin1, to przy eksporcie powstało zupełnie nowe kodowanie, bo pomieszane utf8 z latinem... z tym sobie co prawda nie poradziłem, musiałem zamieniać ręcznie (tu pewnie pomogłaby instalacja starego phpmyadmina, jak ktoś już opisywał)

ale kontynuując... bawiłem się trochę i zepsułem sobie tabelę phpbb_posts_text, którą musiałem wrzucić na nowo na serwer... i tu mam kilka rad

jeśli macie już ściągniętą bazę, gdzie są prawidłowo kodowane polskie litery... w tym przypadku opisuję sytuację z polskimi znakami w iso 8859-2 (latin2) i bazie 4.1 ustawionej pod latin1 (default pod latin1, porównania pod latin1-swedish-ci)

przede wszystkim, jeśli macie taką sytuację, że kodowanie znakód jest w innym systemie (ale poprawnie zapisane w pliku bazy), a baza ustawiona pod inną - NIE ZWRACAJCIE UWAGI NA POLSKIE ZNAKI WYśWIETLANE W PHPMYADMINIE - gdyby nie to, już dawno miałbym problem z głowy, a tak ciągle myślałem, że coś jest nie tak najlepiej zrobić sobie prosty skrypt wyciągający przykładowo jeden wiersz z polskimi literami (koniecznie z dodanym meta charsetem)

bazę można spokojnie wrzucać przez phpmyadmina (nawet nowego), trzeba tylko ustawić odpowiednie kodowanie - trzeba tylko zauważyć, że odpowiednie kodowanie nie oznacza kodowania znaków w pliku!
jeśli macie taką sytuację jak ja, polskie znaki w latin2, baza w latin1, to mimo, że kodowanie znaków jest w latin2, przy uploadzie pliku wybieracie latin1 - i tu właśnie polskie znaki w phpmyadminie będą źle wyświetlane, ale na stronie będzie ok

trzeba zaznaczyć jeszcze jedną rzecz - ta sytuacja opisana jest dla serwera, który ma default charset na latin1, jeśli serwer ma to ustawione na latin2, trzeba dodać do skryptu 'set names latin1', jeśli nie chcemy konwertować każdej komórki do latin2

sytuacja jest podobna w przypadku używania własnych skryptów, jeśli dane zapisujemy w latin2 w bazie ustawionej na latin1 i serwer jest ustawiony na default latin2, to i tak musimy użyć po połączeniu do bazy zapytania 'set names latin1'


i jeszcze jedna wskazówka, odnośnie konwersji znaków, a właściwie nie konwersji samych znaków, tylko informacji o kodowaniu dla mysqla dla komórek...

przykładowo, mamy tabelę `tabela`, komórkę `tekst` char(60) - znaki w niej zapisane są w iso 8859-2 (latin2), ale metoda porównań jest latin1-swedish-ci (a co za tym idzie, character set latin1), chcemy zmienić character set na latin2... i tu był właśnie mój pierwszy błąd, rozwiązanie znalezione - po kilku godzinach szukania w necie... w manualu...

otóż przy konwersji tego rodzaju, nigdy NIE ROBIMY tak:

ALTER TABLE tabela MODIFY tekst char(60) character set latin2

w tym przypadku pojawią nam się najprawdopodobniej znaki zapytania i polskich liter nie przywrócimy, bo są to po prostu znaki zapytania, żadne nierozpoznane kodowanie

ROBIMY TAK:
najpierw konwersja do typu binarnego, żeby nie stracić danych:

ALTER TABLE tabela MODIFY tekst binary(60)

i dopiero zmiana kodowania:

ALTER TABLE tabela MODIFY char(60) character set latin2

(dla typu text zmieniamy na blob)

trzeba jeszcze zaznaczyć, że w tym przypadku znaki w bazie pozostają dokładnie takie jak były, nie jest to konwersja samego tekstu, tylko informacji dla mysqla o kodowaniu, jeśli w ten sposób zmienimy bazę, która miała znaki w bazie w latin2 a używaliśmy jej dla serwera, który miał default latin1, to będzie trzeba teraz dodać do skryptu "set names latin2"

mam nadzieję, że ten post (trochę długi wyszedł) komuś pomoże

Ja wszystko (prawie) co się da mam na latin2:
(pma-282)
jeżyk polski
System kodowania znaków dla MySQL: UTF-8 Unicode (utf8)
System porównań dla połączenia MySQL: latin2_bin
Metoda porównywania napisów (baza): latin2_bin
Metoda porównywania napisów (tabela): latin2_bin

w pliku my.ini
[mysql] i [mysqld] latin1

Wszystko jest ok dla skryptów w iso-8859-2 i wysłaniu zapytania "SET CHARSET latin2;" Problemy występują tylko dwa:
1. Po dodaniu czegoś w PMA wyświetla właśnie się tylko [Blob x bajtów]. Jeżeli zmienię pole do latin1_swedish_ci (jedynie gdy nie ma polskich znaków, inaczej mysql wywala błąd) to pma poprawnie wyświetla dane.
2. Nadal nie wiem jak eks/im ~portować dane z latin1_swedish_ci do latin2bin. Bo i tak nie wiem czy da rezultat zmienianie ręcznie każdego pola i tabeli dla forum phpBB.

OT. Straszny fake z tymi kodowaniami. Mam pomysł nauczmy się wszyscy angielskiego i zlikwidujmy inne języki - a'la "Misie ratują przed ogonkami"

dzisiaj przy okazji testowania konwersji phpbb > smf przyszedł mi na myśl jeszcze jeden pomysł i co najlepsze się sprawdził a co jeszcze lepsze, jest z tym mniej roboty...

sytuacja opisywana dla bazy, w której przechowywane są dane z polskimi znakami w iso-8859-2, ale charset w bazie > 4.1 jest ustawiony na latin1...

1. robimy eksport z phpmyadmina - może być z nowego (ewentualnie mysqldump)

2. jeśli eksportowaliśmy z jakiegoś nowszego phpmyadmina prawdopodobnie mamy teraz w pliku krzaki w miejsce polskich liter, dlatego robimy konwersję (np. programem gżegżółka pod windowsem, czy iconv pod linuxem), ustawiamy konwersję z utf8 na latin1 (iso-8859-1) (nie na latin2 - dlatego, że kodowanie w bazie ustawione było na latin1 i baza konwertując na utf8 właśnie to bierze pod uwagę)

3. mamy teraz zrzut bazy, w którym polskie znaki są w iso-8859-2, ale przy wrzucaniu tego na serwer baza znowu będzie myślała, że wrzucamy w latin1 i pojawią się znaki zapytania... otwieramy plik zrzutu bazy w dowolnym edytorze (byleby miał funkcję zamiany) i zamieniamy ciąg 'latin1' na 'latin2' - teraz przy wrzucaniu bazy będzie zgodność znaków w pliku z ustawieniem charsetu dla tabel/pól

oczywiście jeśli jest szansa, że w bazie będą teksty zawierające słowo latin1 (pewnie w bazie forum php.pl jest tego cała masa ), to możemy trochę rozszerzyć szukany tekst, ostatecznie zmieniać wpisy ręcznie ważne, żeby wpisy przy tworzeniu tabel były zmienione na latin2 (collation przy zamianie też będzie zmieniony na latin2_general_ci - nie musi być latin2bin)

4. wrzucamy bazę na serwer w dowolny sposób, przez source, czy phpmyadmina (przy wrzucie przez phpmyadmina kodowanie dla pliku ustawiamy na iso-8859-2)

po tej operacji można bezproblemowo przejść na utf8 nawet z poziomu bazy, wystarczy zmienić charset dla bazy na utf8 i znaki powinny się przekonwerterować na utf8 (ale tego nie testowałem, więc mogę się mylić)

Poradziłem sobie. ~WereWolf mam pytanie, czy da się eksporotwać bazę, aby były w niej polskie znaki? Ma ktoś taki skrypt?

A może ktoś zna jakiś software (tzn. jakiś program pod Windowsa/Linuxa) do tego?

Błędy chyba o których tu się mówi to głównie sprawka phpMyAdmina ?

tak i nie... a właściwie nie...
jest to głównie błąd przy upgradzie MySQL'a z wersji <= 4.0 na >=4.1, bo tu weszła nowa komórka w opisie tabeli, a właściwie dwie: charset i collate

i tu się pojawia problem, bo o ile dla stron, które na to nie zwracają uwagi, to nawet dane zapisywane/odczytywane jako latin2, ale dla ustawienia tabeli latin1 działają normalnie...

za to nowy phpmyadmin już te dane bierze pod uwagę i żeby w nim wszystko działało dane zapisane w bazie z typem ustawionych danych musi się zgadzać, inaczej nawet jeśli na stronie, która wykorzystuje tą bazę, wszystko jest ok - to w phpmyadminie (i przy eksporcie danych) będą krzaki

jeśli baza była updatowana bez domyślnego ustawienia na latin2, trzeba wykonywać te kroki, które podałem (przynajmniej tak mi się wydaje), ewentualnie tak jak pisałem wcześniej (i co jest napisane w manualu) konwertować każdą komórkę bazy z latin1 na latin2 (albo do utf8, co jest teoretycznie przynajmniej, bardziej prawidłowe), ale koniecznie z międzykonwersją na binary/bob, bo inaczej pojawią się znaki zapytania


i jeszcze jedno... to nie jest tylko wina phpmyadmina, jeśli kodowanie znaków w bazie nie zgadza się z faktycznie używanym, to nawet baza eksportowana przez mysqldumpa będzie miała krzaki i trzeba zrobić to samo co wyżej...


P.S. oczywiście można napisać jakiś prosty skrypt konwertujący bazę z latin1 na latin2, czy utf8 z międzykonwersją... ja podałem po prostu kroki jakie trzeba wykonać


P.P.S. jeszcze jedno... krzaki po eksporcie pojawiają się tylko jeśli dane w bazie != ustawieniu charset dla komórek/bazy, jeśli już poradzimy sobie z przekonwertowaniem bazy np. z latin1 na latin2, to po eksporcie dane będą poprawne, tyle, że w przypadku nowego phpmyadmina znaki będą zawsze w utf8 (ale mogę się mylić), przy mysqldumpie chyba można wybrać kodowanie...

No właśnie - nie ma gdzieś w konfigu phpmyadmina, aby zmienić te kodowanie na iso-8859-2? Jeśli nie, to w ramach nauki napisze sobie skrypt konwertujący z utf na iso, a co będę ściągał jakiegoś gotowca

przyznam szczerze, że ja testując to co pisałem, używałem praktycznie tylko phpmyadmina zainstalowanego domyślnie na serwerze (serwery wirtualne), a co za tym idzie nie miałem dostępu do konfiga... raz zrobiłem wyjątek, przy testowaniu starszej wersji...

w każdym razie, jeśli chodzi o konfig, to faktycznie jakieś ustawienia są (default collation, default charset), ale trzeba by potestować metodą prób i błędów jakie ustawienie by zadziałało (podejrzewam, że zależy to też od ustawienia default character setu dla serwera itp.), bo mam dziwne przeczucie, że jeśli dane w bazie nie odpowiadają ustawieniu charsetu dla bazy, to znowu przy eksporcie pojawią się znaki zapytania... chyba metoda konwersji pliku po eksporcie jest pewniejsza

Mi się udało to załatwić bez problemu.
Wszystko jest na utf8_polish_ci
I raz dałem zapytanie: SET NAMES latin2
Eksportuje i imprortuje bez problemów. Zawsze z UTF-8. Tylko jeżeli mam baze zimportowaną ze starszego phpmyadmina to podczas importu zmieniam na latin1.

Jedyne co jest nie tak to, że w phpMyAdminie nie mam polskich znaków, a krzaki....

Udało sie komuś załatwić to, aby wszystko chodziło bez problemów łącznie z phpmyadminem?

U mnie w tej chwili na swiezo zalozonej bazie tez jest utf8_polish_ci i wszystko ladnie sie wyswietla takze w tym badziewiu, ktorego nazwy nie przytocze, zeby sie nie denerwowac. Ale to tak ladnie pieknie jest pewnie tylko dlatego, ze jeszcze nie musialam tej bazy uploadowac z backupu.

jeśli w phpmyadminie masz krzaki, to znaczy, że masz ustawione złe kodowanie... tzn. przykłądowo, ustawienie collation i charset na latin1, a faktycznie przetrzymujesz w bazie dane kodowane pod latin2...

żeby w phpmyadminie widzieć znaki poprawnie, ustawienie kodowania dla bazy i dane zawarte w komórkach muszą się zgadzać...

WereWolf, wszędzie mam utf8_polish_ci, baza, tabele, komórki, wszystko.

Czyli jak powienienm to ustawić?

a jakie dane trzymasz w bazie? tzn. w jakim kodowaniu?

Jakie dane? Hmmm... Dane są wprowadzane z formularzy ze strony. Wszystko jest ustawione na utf8_polish_ci, wiec to chyba ten typ...

no właśnie niekoniecznie...

kodowanie danych wprowadzanych z formularzy na stronie zależy od ustawień kodowania przeglądarki (i/lub charsetu ustawionego w meta-danych na stronie)

przykładowo jeśli na stronie używasz kodowania iso-8859-2, to w takim właśnie kodowaniu dane są przesyłane do bazy... wtedy nic dziwnego, że w phpmyadminie widzisz krzaczki, bo kodowanie danych nie zgadza się z ustawieniami w bazie...

a jeśli na stronie faktycznie używasz kodowania w utfie, to nie mam innego pomysłu...

Czyli w takiej sytuacji mam zmienić kodowanie strony na utf? Ale wtedy trzba coś kombinować przy wpisywaniu znaków?

Czy zmienić kodowanie bazy na jakieś inne, a jeżeli inne to jakie?