Problem z kodowaniem w MySQL, szystkie polskie znaki zamiejają sie w ? Opcje

[Dynuel]

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ą(IMG:http://forum.php.pl/style_emoticons/default/sad.gif) ....

wielkie dzięki

[son]

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

[Dynuel]

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

[Lemik]

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ę (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[yivan]

zmarnowałem nad tym prawie cały dzień (IMG:http://forum.php.pl/style_emoticons/default/blink.gif) i.... doszedłem do wniosku ze zainstaluje sobie phpmyadmina 2.5.7 i działa wszystko okej (IMG:http://forum.php.pl/style_emoticons/default/rolleyes.gif)

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

Kod

/**
* Language and charset conversion settings
*/
// Default language to use, if not browser-defined or user-defined
$cfg['DefaultLang'] = 'en-iso-8859-1';

// Force: always use this language - must be defined in
//        libraries/select_lang.lib.php
// $cfg['Lang']     = 'en-iso-8859-1';

// Default charset to use for recoding of MySQL queries, does not take
// any effect when charsets recoding is switched off by
// $cfg['AllowAnywhereRecoding'] or in language file
// (see $cfg['AvailableCharsets'] to possible choices, you can add your own)
$cfg['DefaultCharset'] = 'iso-8859-1';

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

[Lemik]

a poza tym, że zainstalowałeś nowe, to do jakich wniosków doszedłeś(IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) (IMG:http://forum.php.pl/style_emoticons/default/snitch.gif)

[NoiseMc]

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 post edytował NoiseMc 10.08.2005, 00:13:29

[gladiror]

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!

[yivan]

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 "?".

[gladiror]

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...

Ten post edytował gladiror 11.08.2005, 13:08:33

[dvc]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[dmrr]

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

[Reigon]

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 (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

[palik]

Witka


Dzieki za podsunięcie pomysłu ze starszym phpmyadminem, bardzo mi pomógł i paru siwych włosów oszczędził (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) (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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) .

[Synaps]

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.

[sevencats]

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

[Nevermore]

To moj pierwszy post tutaj, wiec witam! (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) ).

Ten post edytował Nevermore 19.11.2005, 19:28:52

[Nosfi]

Właśnie zmieniłem firmę hostingową i miałem ten sam problem ...
Synaps ... sposób działa rewelacyjnie i sprawdza się nienagannie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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

[Nevermore]

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

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

Witam!
Napisałem o tym już na forum phpbb by Przemo!
Brak polskich znaków występuje na serwerach z nowymi wersjami MySQL oraz phpMyAdmin.
Aby mieć polskie znaki zamiast znaków zapytania należy:
1. Wgrać w całości bazę danych na serwer, jeżeli baza już jest to ok.).
2. Ustawić w phpMyAdmin:
- język: Polish (pl-utf- 8)
- system porównań dla połączenia MySQL: utf8_general-ci
- dla konkretnej tabeli - metoda porównywania napisów: utf8_general-ci
3. Generalnie chodzi o polskie znaki w tabeli phpbb_post_text oraz phpbb_topisc (tabele odpowiedzialne za treść postów oraz ich tytuł) Oczywiście można zmienić wszystkie tabele np. odpowiedzialne za tematy for, użytkowników itp.).
4. W pliku sql gdzie mamy cały zrzut bazy danych odszukujemy zrzuty w/w tabel. Tworzymy nowy plik o nazwie post_text (oczywiście nazwa dowolna) i kopiujemy do niego z pliku sql dane tabeli phpbb_post_text. TYLKO DANE BEZ STRÓKTURY TABELI. Analogicznie do każdej tabeli nowy plik.
5. Otwieramy taki plik w edytorze pozwalającym na konwersje znaków (polecam EdHTML). Ustawiamy taki sposób kodowania aby polskie litery miały ogonki (ISO-8859-2).
6. Teraz nadszedł czas na zmianę na utf-8 (znaki Unicode). W opcjach programu wybieramy znajdź/zmień ewentualnie zastąp. W polu "znajdź" wpisujemy np. ą a w polu "zmień na" wpisujemy & # 261; (bez spacji) Klikamy OK i wszystkie ą zostają zmienione.
Kody polskich znaków w systemie Unicode znajdziecie m.in na http://www.kurshtml.boo.pl/skrypty/unicode.html
7. W ten sposób zmieniamy wszystkie polskie znaki na znaki Unicode.
Przykład: Zdanie z polskimi znakami: "Już będą wyświetlane prawidłowo."
Po naszej zmianie wygląda: Ju& #380; b& #281;d& #261; wy& #347;wietlane prawid& #322;owo.
8. Wchodzimy do phpMyAdmin, czyścimy tabelę w której chcemy dokonać zmian i za pomocą zakładki SQL wrzucamy (kopiujemy) zawartość naszego pliku (już ze znakami Unicode). Ważne aby przed przystąpieniem do uzupełniania tabeli wyczyścić ją a nie nadpisywać.
9. Przeglądając zmienioną tabelę widzimy już w niej znaki Unicode a na naszym forum są już polskie znaki!
Działa w 100%. Sprawdzałem na dwóch serwerach na których właśnie po przejściu na nowe wersje
programów na forach występowały znaki zapytania.

[Aztech]

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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) ) a on nam zapisze już w latin2 (czyli nasze upragnione ISO (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) ).
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)

[tomalec]

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

Kod

character-sets-dir="../MySQL/share/charsets/"
default-character-set=latin2

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

Kod

character_set_client: latin1
character_set_connection: latin1
character_set_database: latin2
character_set_results: latin1
character_set_server: latin2

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

Ten post edytował tomalec 7.01.2006, 22:35:53

[Lemik]

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 (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

[Gumiak]

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 (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

co to może być??

Ten post edytował Gumiak 16.02.2006, 15:13:42

[Spanner]

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 (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) ) 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 (IMG:http://forum.php.pl/style_emoticons/default/sad.gif) 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 ;/

[falkor]

proponuje zajrzec do manuala mysqla , zlote rady z nieba nie spadna a tam wszystko jest opisane i o character setach i collacjach (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)

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.

[towpawel]

Caly problem tak na prawde jest banalny (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg)
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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

(IMG:http://forum.php.pl/style_emoticons/default/offtopic.gif) (IMG:http://forum.php.pl/style_emoticons/default/guitar.gif)

Ten post edytował towpawel 24.03.2006, 16:49:17

[kaczorek]

Także borykałem się z tym problemem

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

[Jarod]

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 

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

[em1X]

Wydajność spadnie o całe 0,0002 sekundy. Boże zatrzymaj świat bo ja wysiadam (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

[tomekp]

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:

character-set-server=latin2
collation-server=latin2_general_ci
character-set-client-handshake=0

[NuLL]

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 (IMG:http://forum.php.pl/style_emoticons/default/winksmiley.jpg) uzyskac polskie fonty w PMA (IMG:http://forum.php.pl/style_emoticons/default/questionmark.gif) Wszystko co sie dalo w ustawieniach ustawilem na UTF-8 i dupa z tego (IMG:http://forum.php.pl/style_emoticons/default/sad.gif)

[siemakuba]

@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.

[Jarod]

Mój plik my.ini:

[client]

port=3306
default-character-set=latin2

[mysql]

default-character-set=latin2


[mysqld]

port=3306
basedir="D:/Files/MySQL/MySQL Server 5.0/"
datadir="D:/Files/MySQL/MySQL Server 5.0/Data/"
default-character-set=latin2
n create new tables when
default-storage-engine=INNODB
#sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"

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ć?

[KG-]

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

Kod

mysqldump -u uzytkownik --password="haslo" --opt nazwa_bazy > zrzut.txt

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

Kod

mysqldump -u uzytkownik --password="haslo" --default-character-set=latin1 --opt nazwa_bazy > zrzut.txt

- import

Kod

mysql -u uzytkownik --password="haslo" nazwa_bazy --default-character-set=latin2 < zrzut.txt

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.

Ten post edytował KG- 12.09.2006, 08:46:14

[WereWolf]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował WereWolf 22.08.2006, 06:26:17

[Coolmax]

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" (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif)

[WereWolf]

dzisiaj przy okazji testowania konwersji phpbb > smf przyszedł mi na myśl jeszcze jeden pomysł i co najlepsze się sprawdził (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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 (IMG:http://forum.php.pl/style_emoticons/default/biggrin.gif) ), to możemy trochę rozszerzyć szukany tekst, ostatecznie zmieniać wpisy ręcznie (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) 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ć)

Ten post edytował WereWolf 25.08.2006, 20:34:20

[Coolmax]

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

Ten post edytował Coolmax 26.08.2006, 14:00:44

[intol]

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 ?

[WereWolf]

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ć (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)


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...

Ten post edytował WereWolf 26.08.2006, 18:31:22

[Coolmax]

...
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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[WereWolf]

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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

[koskitos]

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?

Ten post edytował koskitos 8.11.2006, 22:54:18

[Nevermore]

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.

[WereWolf]

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?

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ć...

[koskitos]

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

Czyli jak powienienm to ustawić?

[WereWolf]

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?

[koskitos]

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

[WereWolf]

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...

[koskitos]

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?

[WereWolf]

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?

jeśli wszystko na stronie działa normalnie, to nie musisz nic kombinować, jedynym błędem będą właśnie krzaki w phpmyadminie, dane wprowadzane przez phpmyadmina też mogą być później źle wyświetlane na stronie...

w praktyce, żeby wszystko działało jak należy, na stronie powinno być dokładnie takie samo kodowanie, jakie są ustawienia dla bazy, czyli jeśli na stronie masz iso-8895-2, to dla bazy powinno być ustawione kodowanie latin2... z tym, że to też nie takie proste zmienić po prostu kodowanie, bo wtedy pojawią się znaki zapytania w zapisach bazy, musisz to zrobić po kolei, np. tak jak opisywałem w poprzednich postach

[GhOsT9]

Rowniez mam problem z krzakami, wiec sie dolacze...

Zalozylem sobie ambitny plan - zrobienie strony w 3 jezykach w 95% na bazie MySQL i w UTF8. Wszystkie podstrony i caly panel administracyjny maja charset=UTF-8. Baza danych jest ustawiona na utf8_unicode_ci (moge przestawic na utf8_general_ci ale tak i tak jest lipa).

Strona i baza stoja na hostingu - linux i MySQL 4.1.x

Po dodaniu tekstu z polskimi znakami, na stronie wyswietlaja mi sie krzaki w czesci liter ogoniastych. Tak samo w panelu przy edycji. Probowalem deklarowac kodowanie przy zakladaniu tabel w bazie: TYPE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;

Dodalem do skryptow dwie rzeczy:
na poczatku:

Kod

ini_set('default_charset', 'UTF-8');

i po polaczeniu z baza:

Kod

mysql_query('SET CHARACTER SET utf8');

Wciaz nie smiga a ja jestem w lesie. Strona ma wersje jezykowe PL, EN, DE, wszystkie jezyki sa zapisywane obok siebie w komorkach tabeli, np.

Kod

    pl                varchar(150)                   NOT NULL,
    en                varchar(150)                   NOT NULL,
    de                varchar(150)                   NOT NULL,

Formularze zrobilem na takiej zasadzie, ze przed dodaniem do bazy wpisuje sie wszystkie wersje jezykowe w jednym formularzu, analogicznie jak w sklepach opartych na oscommerce.

Po wielu eksperymentach, wciąż mam krzaki w części znaków.

Ma ktos patent jak to ustawic zeby smigalo bezproblemowo z trzema jezykami i bez krzakow?
Jaka odmiana kodowania UTF8 dla bazy (utf8_unicode_ci czy utf8_general_ci), jaki system porownan dla tabel i co dodac do skryptow php przed odczytem, dodaniem czy zmiana danych w bazie?

[WereWolf]

to chyba oczywiste, ale na wszelki wypadek zapytam...

oczywiście na stronie masz w meta ustawionych charset utf8? (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Jaka odmiana kodowania UTF8 dla bazy (utf8_unicode_ci czy utf8_general_ci)

to tylko systemy porównań (z tego co się orientuję), kodowanie i tak jest utf8, więc to raczej bez znaczenia


jeśli chodzi o zapytanie wysyłane po połączeniu z bazą to raczej powinno być:

[PHP] pobierz, plaintext 
<?php
mysql_query("set names 'utf8'");
?>
[PHP] pobierz, plaintext 

chyba to powinno wystarczyć... jeśli nie, to albo nie wszystkie kolumny mają ustawione kodowanie utf8, ustawienie ogólne dla bazy nie jest utf8, albo coś na samej stronie jest nie tak... nic więcej mi do głowy nie przychodzi

[GhOsT9]

WereWolf:

dzięki za info. set names też przerabiałem, oczywiście, strona ma w meta utf-8.

założę bazę od nowa i pokatuję ponownie "set names".

edit:
cóż, nie do końca pomogło. mam set names, set character set. strona i baza w UTF8, tabela testowa w UTF8...
wszystkie ogoniaste poza "ń" są OK. duże Ń też jest ok... fajnie.

Ten post edytował GhOsT9 11.12.2006, 12:34:19

[WereWolf]

cóż, nie do końca pomogło. mam set names, set character set. strona i baza w UTF8, tabela testowa w UTF8...
wszystkie ogoniaste poza "ń" są OK. duże Ń też jest ok... fajnie.

a gdzie konkretnie masz ten problem?

1. wyświetlanie "statycznych" tekstów na stronie
2. wyświetlanie tekstów z bazy:
- wyświetlanie pobranych tekstów z bazy na stronie
- wyświetlanie tekstu z bazy przez phpmyadmina?

[woodzu]

Ja swój problem rozwiązałem wszędzie deklarując iso-8859-2 / latin2-general-ci

1. phpMyAdmin - 2.9.1.1

phpMyAdmin/index.php (linijka 98)

[PHP] pobierz, plaintext 
<?php
lang_iso_code = 'pl-iso-8859-2';
?>
[PHP] pobierz, plaintext 

phpMyAdmin/librares/config.default.php

[PHP] pobierz, plaintext 
<?php
// linijka 392
	  $cfg['DefaultLang'] = 'pl-iso-8859-2';
 
// linijka 395
	  $cfg['DefaultConnectionCollation'] = 'latin2_general_ci';
 
// linijka 400
	  $cfg['Lang']	 = 'pl-iso-8859-2';
 
// linijka 404
	  $cfg['FilterLanguages'] = '';
 
// linijka 409
	  $cfg['DefaultCharset'] = 'iso-8859-2';
?>
[PHP] pobierz, plaintext 

2. MySQL 5.0.22 (my.ini):

Kod

[client]
  default-character-set=latin2
[mysql]
  default-character-set=latin2
[mysqld]
  default-character-set=latin2

3. Apache/2.0.59 (Win32) (httpd.conf)

Kod

AddDefaultCharset ISO-8859-2

4. na stronie (index.php) oczywiście :

Kod

mysql_query ("SET NAMES latin2");
mysql_query (" SET collation_connection = latin2_general_ci ");

// oraz

[HTML] pobierz, plaintext 
<html xml:lang="pl" lang="pl" xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
[HTML] pobierz, plaintext 

Z takiej konfiguracji eksportowałem już na serwer przez phpMyAdmin 2.7.0-pl2 ( MySQL 4.1 ) z ustawieniem "System porównań dla połączenia MySQL: latin2_general_ci" i jakiś inny serwer z utf8. Bezproblemowo się importowało i później eksportowało z tych serwerów.

Wszystko działa pięknie i wspaniale. Przy imporcie trzeba tylko zaznaczyć "Zestaw znaków dla pliku latin2", coby nie stracić ogonków. W strukturze bazy każdą kolumnę typu char/text mam z metodą porównywania latin2_genere_ci.


Stronę miałem wcześniej w ISO-8859-2. Kiedy podzieliłem ją na podstrony wstawiane przez funkcje reqiue_once () index.php został w tym kodowaniu, natomiast podstrony zapisywały się w WINDOWS-1250. To rozwiązał program Gżegżółka XP w kilka sekund. Więc strony miałem już czyste.

W PMA nie wyświetlają się żadne zbędne krzaki, można spokojnie dodawać i edytować rekordy.
Jedyny problem na jaki się napotkałem to PMA zmieniał literkę " ó " na "& oacute;". Tzn. w takiej formie zapisywał do bazy, ale na stronie było już " ó ". Tymczasowo rozwiązałem to przy odczycie z bazy funkcją ...

[PHP] pobierz, plaintext 
<?php
$zmienna = str_replace ( "& oacute;" , "ó" ,  $zmienna );
?>
[PHP] pobierz, plaintext 

... ale kombinuje dalej czemu wstawia się tak a nie tak jak być powinno. Macie może pomysły?

P.S.
Aha tak w sumie to witam wszystkich bo to mój pierwszy post na tym forum :]
Mam nadzieję że komuś się może przydać mój conig.

Pozdrawiam



Ten post edytował woodzu 14.12.2006, 17:03:43

[WereWolf]

Jedyny problem na jaki się napotkałem to PMA zmieniał literkę " ó " na "& oacute;". Tzn. w takiej formie zapisywał do bazy, ale na stronie było już " ó ".

hmm... a to ciekawe, z tym się nie spotkałem (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

a zamieniane jest to tylko przy wprowadzaniu danych przez PMA, czy przez formularze na stronie też?
jeśli tylko przez PMA, to pewnie wina samego engine'u PMA... ale w niego się nie zagłębiałem, więc nie wiem (IMG:http://forum.php.pl/style_emoticons/default/smile.gif) ogólnie używam go tylko do przeglądania danych od czasu do czasu (raczej rzadko), ewentualnie do poprawienia czegoś na szybko, albo wyszukania jakichś danych... wolę konsolę, ale nie zawsze jest do niej dostęp (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

[woodzu]

przez formularze też zamienia, zapomniałem tego dodać, gdyby zamieniał tylko przy wprowadzaniu danych z PMA to bym się tym tak nie przejmował, jak narazie to mój jedyny mankament

wnioskuje że to coś związane z kodowaniem samego MySQLa

[hhg]

mysle ze powinno sie skorzystac z tego:
http://dev.mysql.com/doc/refman/5.0/en/charset-convert.html

tyle ze mam maly problem z zastosowaniem:

[SQL] pobierz, plaintext 
SELECT CONVERT(_latin1'Müller' USING utf8);
INSERT INTO utf8table (utf8column)
    SELECT CONVERT(latin1field USING utf8) FROM latin1table;
[SQL] pobierz, plaintext 

nie rozumiem co wstawic za _latin1'Muller'

wogole co oznacza co w tym zapytaniu??

[WereWolf]

tyle ze mam maly problem z zastosowaniem:

[SQL] pobierz, plaintext 
SELECT CONVERT(_latin1'Müller' USING utf8);
INSERT INTO utf8table (utf8column)
    SELECT CONVERT(latin1field USING utf8) FROM latin1table;
[SQL] pobierz, plaintext 

z tego co rozumiem:
CONVERT - nazwa funkcji
_latin1 - użyj kodowania _latin1 (traktuje tekst jako kodowany w latin1, nie zważając na domyślne ustawienia, albo ustawienia typu "set names")
'Muller' - tekst, ktory ma zmienic
USING - wiadomo
utf8 - kodowanie wyjściowe

w drugim wstawia do kolumny utf8column (jak przypuszczam ustawionej na utf8), konwertując w locie komórkę latin1field przy użyciu utf8 z tabeli latin1table...

nawet jeśli to działa tak jak ma działać, to jakoś nie jestem do tej metody przekonany (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)
powinno być raczej wszystko poustawiane tak jak miało być, czyli wszędzie jedno kodowanie - strona, ustawienia tabeli i w razie konieczności (jeśli serwer ma ustawione inne domyślnie używane kodowanie) - dodane po połączeniu z bazą zapytanie "set names 'kodowanie'", zwłaszcza, że zapytania typu _latin1'tekst' raczej nie są stworzone do takich zastosowań, a raczej do pojedynczych przypadków

druga sprawa... przy takiej metodzie, przy każdym zapytaniu do bazy następuje jakaś tam konwersja znaków - a to zawsze trochę trwa, przy niewielkiej stronie pewnie można by to pominąć, ale przy większej ilości zapytań już wzrasta obciążenie serwera

Ten post edytował WereWolf 15.12.2006, 07:16:16

[woodzu]

druga sprawa... przy takiej metodzie, przy każdym zapytaniu do bazy następuje jakaś tam konwersja znaków - a to zawsze trochę trwa, przy niewielkiej stronie pewnie można by to pominąć, ale przy większej ilości zapytań już wzrasta obciążenie serwera

dokładnie ! taka metoda odpada

a ja już częściowo rozwiązałem problem,
- eksportowałem całą bazę,
- podmieniłem wszystkie wystąpienia "& oacute;" na normalne "ó" w pajączku,
- przeinstalowałem, MySQLa i phpmyadmin, wszystkie konfigi tak jak powyżej podałem,
- tylko w phpMyAdmin/librares/config.default.php zakomentowałem linijke $cfg['Lang'] = 'pl-iso-8859-2';
- import
teraz już normalnie, zarówno pma wstawia/edytuje "ó" jak i zwykły formularz text/textarea również,
problem pozostał tylko w formularzach wysiwyg (konkretnie to TinyMCE) , ale to już temat na inną bajkę i chyba wiem gdzie się to zmieniało

[FXJ]

Witam

Jest to mój pierwszy post na tym forum więc witam gorąco,
niestety mam podobny problem, próbowałem rozwiązać go
powyższymi sposobami, ale niestety zonk, a do plików Apache,
mySQL itp. nie mam dostępu.

Po pierwsze, mam dwie wersje bazy danych w postaci (fragment)
a) normalne polskie znaki

[SQL] pobierz, plaintext 
INSERT INTO `kategoria` VALUES (1, 'Aktualności', 1, 1);
[SQL] pobierz, plaintext 

(IMG:http://forum.php.pl/style_emoticons/default/cool.gif) kodowane znaki czyli ¶, ±, ľ itp.

[SQL] pobierz, plaintext 
INSERT INTO `kategoria` VALUES (1, 'Aktualności', 1, 1);
[SQL] pobierz, plaintext 

Z którym plikiem bazy danych mam się "bawić"?

Mój cel to kodowanie iso, metodę porównywania znaków mam ustawione
na latin2_general_ci, w projekcie tabeli:

[SQL] pobierz, plaintext 
DEFAULT CHARSET=latin2
[SQL] pobierz, plaintext 

No i mam znaki ? ? ? po imporcie na serwerze :/
Jakieś pomysły, po zmianie na binary wszystko cyka,
ale jak wrócę na np. varchar znów to samo.

[dj_piotrek]

Mam podobny problem jak opisane powyżej z tą różnicą, że jak wchodze do myphpadmin i przeglądam dane z bazy to wszystko jest OK
Ale jak strona próbuje pobrać te same dane z bazy to większość poskich znaków zamienia się na znaki zapytania

"...Zespó? powsta? w Sopocie na prze?omie 1993/94 roku. Przez ten czas, wspó?pracowa? z ró?nymi muzykami zbieraj?c nowe do?wiadczenia. ..."

kod strony wygląda następująco

plik ./inc/common.php'

<?php
function db_connect()
{
@$link_id= mysql_connect("localhost","user","pass");
if(!$link_id)
{
return false;
}
if(!mysql_select_db("nazwa_bazy"))
{
return false;
}
return $link_id;
}
?>

plik index.php

<?php include('./inc/common.php');
$link_id=db_connect();
if(!$link_id) return "brak poł&plusmn;czneia z baz&plusmn;";
$sql = 'SELECT * FROM `program` WHERE ( `data` = \'2005-01-28\' )';
$wynik_pobierz=mysql_query($sql);
while($dane_pobierz=mysql_fetch_array($wynik_pobierz)){
$data_program=$dane_pobierz["data"];
$data_program=strtotime($data_program); //zamienia na formayt uniksowy
$data_program=date("d-m-Y",$data_program); // konweruje w formacjie d-m-r
$tytul_program=$dane_pobierz["tytul"];
$tytul_program=stripslashes($tytul_program);
$opis_program=$dane_pobierz["caly"];

echo "<table>";
echo"<tr><td><B>$data_program</b></td></tr>";
echo "<tr><td>$tytul_program</td></tr>";
echo "<tr><td>$opis_program</td></tr>";
}
?>

to wszystko jest odpalone na debianie , co mogę zrobić, żeby normalnie odczytywać znaki polskie na stronie??

[WereWolf]

to wszystko jest odpalone na debianie , co mogę zrobić, żeby normalnie odczytywać znaki polskie na stronie??

dwa pytania:
1. czy masz na samej stronie w htmlu ustawione informacje o kodowaniu znaków? (meta)
2. w jakim kodowaniu masz dane w bazie? jeśli w phpmyadminie wszystko wyświetla się poprawnie, to podejrzewam, że wystarczy dodać zapytanie przy łączeniu się z bazą danych - o tym było już wcześniej... np. jeśli dane są w iso-8895-2, to po mysql_connect dodaj: mysql_query("set names latin2")

[VegetaSSJ]

Witam!

A ja mam problem taki że nie wiem jak wstawiać polskie znaki do bazy przez stronę www. Wszsystkie ustawienia mam na latin2 i iso-8859-2. Ustawienia Apache 2.0.59, PHP 5.1.6, phpMyAdmin-2.9.2, i MySQL 5.x mam takie jak podał kolega @woodzu.

W index.php mam następujący przykładowy kod:

[PHP] pobierz, plaintext 
...
<html xml:lang="pl" lang="pl" xmlns="http://www.w3.org/1999/xhtml">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
...
 
<?php
$db = new mysqli('localhost', 'root', '***', 'ZSRDB');
db -> query('SET CHARACTER SET latin2');
db -> query('SET collation_connection = latin2_general_ci');
$db -> query("insert into ogloszenia (TYTUL, TRESC, AUTOR, TYP) values ('tytul', 'żźćąęół', 'autor', 1)");
$zapytanie = "select * from Ogloszenia";
$wynik = $db -> query($zapytanie);
$wiersz = $wynik -> fetch_assoc();
echo $wiersz['TRESC'];
?>
[PHP] pobierz, plaintext 

Kiedy wstawiam dane do bazy przy użyciu poniższej instrukcji z poziomu index.php

[PHP] pobierz, plaintext 
<?php
$db -> query("insert into ogloszenia (TYTUL, TRESC, AUTOR, TYP) values ('tytul', 'żźćąęół', 'autor', 1)");
?>
[PHP] pobierz, plaintext 

po ich wyświetleniu w tym samym skrypcie zamiast kogonków są krzaki.

Kiedy wstawię te same dane przy użyciu phpMyAdmin-2.9.2 po ich wyświetleniu w index.php tekst jest normalny, czyli ogonki są.

Proszę o pomoc w odpowiedzi na pytanie jak wstawiać do bazy dane przy użyciu formularza www, ewentualnie bezpośrednio ze skryptu php aby po ich wyświetleniu nie zgubiły się ogonki.

[acztery]

daj takie cos przed dodaniem i przed wyciaganiem danych z bazy

[PHP] pobierz, plaintext 
<?php
$db->query("set names 'iso-8859-2");
?>
[PHP] pobierz, plaintext 

powinno pomóc, mi zawsze działa z tym ze nie stosuje iso od dawno. Polecam utf-8 mniej klopotów

[Spanner]

widze, ze połączenie masz na clasach, wię ja bym do classy łączącej się z bazą dał takie coś

[PHP] pobierz, plaintext 
<?php
mysql_query('SET character_set_connection=latin2', $this->connection_id);
mysql_query('SET character_set_client=latin2', $this->connection_id);
mysql_query('SET character_set_results=latin2', $this->connection_id);
mysql_query('set names latin2;');
?>
[PHP] pobierz, plaintext 

zaraz po nawiązaniu połączenia z bazą,wtedy od razu odpada ci wszelkie dodatkowe zapytania, pamiętanie o nich itp

Ten post edytował Spanner 22.02.2007, 15:19:49

[WebCM]

Aby nie tworzyć nowego tematu, dołączę pytanie tutaj.

Zaktualizowałem pakiet WebServ - więc PHP z 5.1.5 nad 5.2.3 i MySQL z 4 na 5. Teraz w przeglądarce nie wyświetlają się polskie znaki w pobranych danych z bazy. Aktualizacja rekordów z poziomu PHP też nic nie daje. MySQL 5 dodatkowo jeszcze posiada mechanizm porównywania znaków.

Fragment my.ini:

Kod

language=c:/usr/mysql/share/polish

character-set-server=latin2
default-character-set=latin2

Zmienne MySQL:

Kod

character_set_system=utf8 (I tego nie mogę zmienić)

Pozostałe zmienne - collation_* i character_set_* (opr. _filesystem = binary) mają wartość LATIN2.

Tabele również mają kodowanie latin2, lecz nie mogą zapamiętać porównania znaków (ustawiam latin2_general_ci, nie ma polish_ci), chyba że MySQL-Front po prostu ich nie odczytuje.

Pomaga dopiero poniższe zapytanie wywołane po rozpoczęciu połączenia:

Kod

SET CHARACTER SET 'latin2'

Tylko dla nowo wprowadzonych danych.

Czym to jest spowodowane? Nieprawidłową konwersją bazy danych? Czy da się ten problem ominąć bez dodatkowego zapytania, czy w skryptach dla MySQL 5 to raczej standard? A może lepiej postawić na UTF?

[Aztech]

Niedawno odkryłem cudowne rozwiązanie na wszelkie problemy związane z kodowaniem. Czasami zdarza się, że mimo wpisania wszystkich ustawień w plikach konfiguracyjnych nadal mamy krzaczki, ew. musimy przed każdym zapytaniem ustawiać CHARACTER SET. Ten wpis w my.ini załatwia większość problemów:

Kod

skip-character-set-client-handshake

[patrycjusz]

Witam,

Odgrzewam temat bo mam spory problem, otóż,
<span style="font-weight: bold;"><a href="http://pl.php.net/baza mysql z której eksportuje ma:character set client utf8character set connection utf8character set database utf8character set filesystem binarycharacter set results utf8character set server utf8character set system utf8character sets dir C:\Dev\MySQL\share\charsets\collation connection utf8_general_cicollation database utf8_general_cicollation server utf8_general_ci" title="Zobacz w manualu PHP" target="_manual">baza mysql z której eksportuje ma:
character set client utf8
character set connection utf8
character set database utf8
character set filesystem binary
character set results utf8
character set server utf8
character set system utf8
character sets dir C:\Dev\MySQL\share\charsets\
collation connection utf8_general_ci
collation database utf8_general_ci
collation server utf8_general_ci</a></span>
niby wszystko ok, tabele mają:

[SQL] pobierz, plaintext 
CREATE TABLE `classes_fields` (
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
[SQL] pobierz, plaintext 

i nie zależnie od tego, z czego robie dump'a (mysqdump, phpmyadmin, mysql administrator) wali takimi o to krzakami:Aktualność , Treść, NagĹ‚Ăłwek.
Jak otworze plik dump.sql poprzez notatnik to widzę kodowanie pliku ładnie UTF-8.

Dodam, że serwer http (po drodze żadnej konwersji nie ma) na localhoście wyświetla pięknie utf-8 bez krzaków. Tylko w dumpie są.

Może jakieś koncepcje?

pozdrawiam,
patS

P.S. Dodatkowa zagadka, poprawnie już mi się udało go wyeksportować, za pomocą komendy: C:\Dev\MySQL\bin>mysqldump.exe -u root -p --default-character-set=latin1 kig > c:\Dump.sql - plik otwieram w notepadzie - wskazuje utf-8 i nie ma żadnych krzaków 9poza &oacute.

ha!

sam sobie odpowiem, dla potomnych jakby ktoś kiedyś miał problem:

1. mysqldump.exe -u root -p --default-character-set=latin1 kig > c:\Dump.sql
2. w notatniku zamieniamy kodowanie z utf8 z sygnaturą na utf8 i dopisujemy set names 'latin2'
3. importujemy z phpmyadmina i wybieramy jako kodowanie pliku utf8



pzdr, patS

Ten post edytował patrycjusz 8.10.2007, 11:38:07