Krzaki w bazie, a polskie znaki na stronie...

[GyniO 10]

Witam,

 

Ostatnio znajomy poprosił mnie, żeby mu przeniósł forum IPB 2.3.6 na jego VPS'a.

Podczas przenosin bazy zauważyłem, że choć baza/tabele/pola mają kodowanie utf8, dane zawarte w tych tabelach nie posiadają polskich znaków.

 

O dziwo forum działa ok, forum posiada polskie znaki ale tylko na tym hostingu.

 

Hosting to vihost.pl (de) z cPanelem.

 

Próbowałem różnych sposobów eksportu bazy, czy to przez PMA, mysqldumpa, HeidiSQL, konwert pliku przez grzegrzółkę ale nic nie skutkowało.

Potrzebuje w jakiś sposób przekonwertować tą bazę z krzakami na bazę z polskimi znakami - bo tylko wtedy forum będzie działać poprawnie na VPS'ie (zmiana kodowania na VPS'ie nie wchodzi w grę).

 

Pisałem na support IPB, tam raczej nikt nie wie jak mi pomóc.

 

Znajomy napisał do supportu hostingu, ciężko było od nich wydobyć jakiegokolwiek backupa tłumacząc, że można zrobić sobie to samemu, a gdy go zrobili to baza nadal nie miała polskich znaków.

 

Przykład wpisów w bazie:

Jeżeli nie będę miał na stanie dorobie w 10 min

 

No dobra nie chcą dawać w III modować...<br />Ale przecież w II są mody różne a gra na popularności nie traci

[vet0 19]

A jest w ogole jakieś kodowanie w którym mysql zapisuje w tabelach polskie litery tak jak powinno być ? o chyba nie.. Każde kodowanie z jakim się spotkałem zastępuje znaki diakrytyczne jakimiś krzaczorami

[Bartosz Stępień 75]

Ja miałem tez problem i gżegżółka rozwiązał problem za mnie. A otwierałeś ten plik sql? Czy są tam krzaczory? Jeżeli tak to musisz się pobawić z eksportem. W gżegżółce jak nie podasz prawidłowego kodowania jakie ma aktualnie plik i będziesz chciał uft8 czy iso-8859-2 to nic nie zdziała.

 

Ale wiesz na sucho nic się nie wymyśli, wyślij mi kawałek tabeli, z jakimiś nieważnymi danymi i spróbuję przekonwertować ją.

[GyniO 10]

Eksport przez mysqldumpa z wymuszeniem kodowania latin2 czy utf8 nie pomagał, po otwarciu pliku krzaki takie same jak w bazie.

 

Z ACP forum wyczytałem tylko te informacje:

character_set_client latin1
character_set_connection latin1
character_set_database utf8
character_set_filesystem binary
character_set_results latin1
character_set_server latin1
character_set_system utf8
character_sets_dir /usr/share/mysql/charsets/
collation_connection latin1_swedish_ci
collation_database utf8_general_ci
collation_server latin1_swedish_ci

 

Mi to jednak niewiele mówi..

Edytowano Listopad 3, 2011 przez GyniO (zobacz historię edycji)

[Bartosz Stępień 75]

A nie możesz przez phpmyadmin? Jest to lepsza metoda.

[kafi 2425]

latin1... czeka cię droga przez mękę.

Podeślij mi przykładowy dump (np. tabelki z nazwami i opisami forów dyskusyjnych), to postaram się jutro wieczorem na jej przykładzie zrobić dla ogółu jakiś mały tutorial z obrazkami, jak takie coś ogarnąć. Jednak warunkiem koniecznym są zamiany owych znaczków na "krzaki". Jeśli się pojawią znaki zapytania, to musztarda po obiedzie.

[GyniO 10]

A nie możesz przez phpmyadmin? Jest to lepsza metoda.

 

Napisałem w 1 poście, że PMA nie pomaga.

 

Podeślij mi przykładowy dump (np. tabelki z nazwami i opisami forów dyskusyjnych)

 

OK podeślę.

 

Jedyne rozwiązanie jaki mi przychodzi na myśl to pętla w PHP, która wybiera dane i wkłada je do innej bazy..

Edytowano Listopad 4, 2011 przez GyniO (zobacz historię edycji)

[blackfire 185]

A jest w ogole jakieś kodowanie w którym mysql zapisuje w tabelach polskie litery tak jak powinno być ? o chyba nie.. Każde kodowanie z jakim się spotkałem zastępuje znaki diakrytyczne jakimiś krzaczorami

 

Doskonały przykład niezrozumienia problemu. Kafi, pisz ten tutorial

 

Nie ma czegoś takiego jak "tak jak powinno być". Musisz rozróżnić dwie kluczowe sprawy: znaki a bajty (Unicode ninjas są proszeni o przymknięcie oczu na drastyczne uproszczenia). Masz taki znaczek: "ą" (LATIN SMALL LETTER A WITH OGONEK). W bazie Unicode ma on przypisany kod U+0105 i tyle możesz o nim powiedzieć. Niestety, codepointów (czyli np. takich U+0105) nie da się bezpośrednio zapisać w bazie danych, wysłać w sieć itp., dlatego powstały różne sposoby konwersji znaków (LATIN SMALL...) na bajty. Realnie używany jest UTF-8, gdzie ą (U+0105) jest zapisywane jako dwa bajty: \xc4 \x85. Proces dekodowania UTF-8 -> Unicode zamienia z powrotem te dwa bajty na U+0105, czyli platoniczny ideał "ą".

 

Zanim upowszechnił się Unicode i UTF-8, powszechne były inne, jednobajtowe kodowania (i niestety dalej są powszechnie używane). Np. w popularnym ISO-8859-2 znak ą (wtedy jeszcze nie był ani LATIN SMALL..., ani tym bardziej U+0105) zapisuje się jako jeden bajt \xb1. W forsowanym onegdaj przez MS kodowaniu CP-1250 ą to \xb9. Wszystkie te zapisy opisują dokładnie ten sam znak: ą, ale żeby się tego dowiedzieć, musisz wiedzieć, jakiego kodowania użyć do konwersji \xb9 -> Unicode. Bo \xb9 to wcale nie musi być ą w CP-1250, to równie dobrze może być š w ISO-8859-2.

 

"Krzaki" pojawiają się, kiedy traktujesz dane zapisane w jednym kodowaniu jako zapisane w innym. Przykładowo, masz string "\xb1", który (jesteś o tym głęboko przekonany) przedstawia ą w latin2 (ISO-8859-2). Twój software operuje w UTF-8, jak Latający Potwór Spaghetti przykazał, więc przed wyświetleniem (wypisaniem do przeglądarki) musi przekonwertować ten string na UTF-8. Tak się nieszczęśliwie składa, że skądś sobie wydumał, że ten string jest zakodowany w latin1 (ISO-8859-1). No to bierze \xb9 i konwertuje latin1->UTF8. Wynik? \xc2 \xb1, odpowiadający U+00B1, czyli PLUS-MINUS SIGN (±).

 

Druga warstwa konwersji, która również musi się udać żeby było widać pliterki a nie krzaki, to wyświetlanie. Tutaj ponownie konwertowane są dane z postaci strumienia bajtów z określonym kodowaniem (wynikającym z nagłówków http, ustawień terminala czy czego tam innego), a wynikowe codepointy są odnajdowane w fontach i rysowane na ekranie.

 

Problem jest szczególnie widoczny w mysqlu (zwłaszcza za czasów migracji 4.0->4.1 to była prawdziwa plaga), bo łatwo jest osiągnąć konfigurację, która prawie zawsze działa. Przykładowo: na stronie zadeklarowane kodowanie utf8, dane do bazy wrzucane zakodowane również w utf8, a kodowanie kolumny w bazie i oczekiwane kodowanie danych wyjściowych zadeklarowane jako latin1 (domyślne). Wygląda to tak:

 

1. User w formularzu wpisuje ą

2. Przeglądarka wysyła \xc4 \x85

3. INSERT INTO ... VALUES (..., "\xc4\x85")

4. Serwer mysql konwertuje dane z latin1 (character_set_client się ta opcja bodajże nazywa) do latin1 (kodowanie kolumny), czyli nic nie robi

5. SELECT ... FROM ...

6. Serwer mysql konwertuje dane z latin1 (kodowanie kolumny) do latin1 (character_set_client), czyli nic nie robi

7. Do klienta idzie \xc4 \x85 z nagłówkiem "Content-type: text/html; charset=utf-8"

8. Klient dekoduje \xc4 \x85 na U+0105 i wyświetla ą

 

Teraz puszczamy w to wszystko phpmyadmina, który stara się robić dobrze i eksportować dane w utf8:

0. SET NAMES UTF8

1. SELECT ... FROM ...

2. Serwer mysql konwertuje dane z latin1 (kodowanie kolumny) do utf8 (character_set_client)

3. Klient dostaje wynik konwersji \xc4 (LATIN CAPITAL LETTER A WITH DIAERESIS, \xc3 \x84) i \x85 (NEXT LINE, \xc2 \x85)

4. OMGWTFBBQ gdzie moje ogonki?