Forum PHP.pl

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

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

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)

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

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 ;/

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.

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

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

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 (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)

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

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

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

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)

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

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

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