Polskie znaki po konwersji leżą, ale nie jestem pewny, czy z winy konwersji

[Gość]

To będzie długa historia... Przekonałem znajomego do przejścia na IPB z phpBB3 i siedliśmy we dwóch wyposażeni w piwo do konwersji.

 

Kolejność:

- zrzucamy pliki phpBB ze starego forum oraz bazę na localhost (xampp), baza w phpBB3 jest w latin2_general_ci, a porównywanie znaków dla połączenia - utf8_general_ci, po wejściu phpMyAdminem widać polskie znaki normalnie

- dla pewności odpalamy stare forum z localhosta (poprawiając połączenie z bazą) - działa, są polskie znaki

- robimy bazę pod IPB 3.4.7, znaki na utf8_unicode_ci

- instalujemy lokalnie IPB, zaraz po instalacji startujemy konwersję robiąc wszystko kolejno jak każą

- po konwersji lokalnie wszystko jest OK, są polskie znaki na forum, natomiast w phpMyAdminie wygląda to w stylu: "Z ciekawoÅ›ci sam zobaczÄ™."

- samo IPB po konwersji w pliku conf_global.php sql_charset ma pusty, nie ma tam utf8, ale wszystko działa, więc się tym nie przejmujemy

- robimy kopię skonwertowanej bazy (znaki w pliku z kopią są takie jak w phpMyAdminie)

- na serwerze tworzymy bazę (utf8_unicode_ci, czyli jak lokalnie, porównywanie znaków dla połączenia też to samo - utf8_general_ci)

- idziemy zgodnie z poradnikiem http://forum.invisionize.pl/topic/1470-przenoszenie-forum-na-inny-serwer/(bo w sumie teraz przenosimy z lokala na serwer), czyli ładujemy pliki, poprawiamy połączenie z bazą w conf_global.php

- kontrola ścieżek, czyszczenie szablonów, cache itp.

 

Byłem niemal pewny, że to zagra, ale nic z tego. Choć baza ma te same kodowanie znaków, porównywanie znaków i wygląda tak samo jak lokalna patrząc przez phpMyAdmina, to forum wyświetla się bez polskich znaków (zamiast tego są ? normalne lub w czarnych rombach)

 

Spróbowałem dopisać utf8 w conf_global.php (co jednak wydaje mi się bez sensu, przecież lokalnie działa bez tego), to forum wyświetla znaki prosto jak są widoczne przez phpMyAdmina, czyli np.: "Z ciekawoÅ›ci sam zobaczÄ™."

 

Dodatkowo czasami sypie błędami w stylu:

Warning: preg_replace(): Compilation failed: invalid UTF-8 string at offset 17

Warning: Cannot modify header information - headers already sent by

 

Na próbę zrobiliśmy inaczej i postawiliśmy czyste IPB na serwerze, a na koniec tylko przepięliśmy bazę na zaimportowaną, ale też nic z tego, ten sam efekt.

 

Kolejna próba - wstawiliśmy nowy post na obydwa fora - lokalne, gdzie polskie znaki są OK oraz to na serwerze, gdzie są wywalone. Nowe posty w obydwu miejscach wyświetlają się OK, ale dostaliśmy różne efekty widoczne w phpMyAdminie (cały czas mamy te same metody porównywania znaków)

 

post o treści: śćźćół 汉字[漢字]

phpMyAdmin lokalny: Å›Ä‡ÅºÄ‡Ã³Å 汉字[漢字]

phpMyAdmin serwer: ĹÄĹşÄóŠćąĺ­[柢ĺ­]

 

Jeszcze jeden eksperyment - dograliśmy spolszczenie. Lokalnie OK, a na serwerze OK, jeśli nie wywali warningów podanych u góry - wtedy spolszczenie ładuje się też bez polskich znaków.

 

Jeśli to coś podpowie, to serwer to dHosting, domyślnie tworzy się tam bazy danych przez ich web admina i mają metodę porównywania latin2, którą zmieniliśmy przed ładowaniem bazy na utf8, bo w końcu taką mamy lokalnie, więc czemu na serwerze miałaby być inna?

 

Co tu się odwala?

 

Dzieje się jakiś kosmos, proszę o naprowadzenie co zrobić inaczej. Nic nie jest problemem, możemy pyknąć wszystko od początku, łącznie z konwersją, byleby efekt końcowy był prawidłowy. Jedyne ograniczenie - nie na serwerze, baza jednak trochę ma, lokalnie mieli się to dość długo, nie widzę szans na zrobienie konwersji online.

 

Jednocześnie nie chcemy nic zmieniać w samym kodzie IPB (np. parametry połączenia), żeby później nam to nie ciążyło przy aktualizacjach - jeśli to działa lokalnie to przecież musi jakoś działać też z serwera? Nie jestem pewny, czy to jednak wina konwersji (choć przecież działa na koniec po konwersji lokalnie), czy też przenosin?

[DawPi]

http://forum.invisionize.pl/tutorials/article/15-naprawa-wy%C5%9Bwietlania-polskich-znak%C3%B3w/

[Gość]

Dzięki, byłem tam już, ale nie chcemy robić modyfikacji w samym IPB, bo później będziemy się z tym męczyć przy każdej aktualizacji (albo przynajmniej przy tych, które ten plik podmienią). Poza tym jest to nienormalne mając na uwadze, że lokalnie działa bez takich kombinacji. Musi istnieć jakaś logiczna przyczyna...

[tenechu]

Spróbuj skorzystać z poradnika Dawida i zobacz efekt, na koniec możesz spróbować jeszcze dopisać w pole charset w pliku conf_global.php - latin2. Czasem pomaga

[Gość]

No nic, siadłem do tego i zrobiłem kilka eksperymentów. Wyszło tak, że zmiany kodu na latin2 i utf8 nie pomogły (w pierwszym przypadku bez zmian - znaki zapytania, w drugim - znaki jak w bazie, nieczytelne), ale pomogła zmiana na latin1. Ponieważ jednak jak pisałem wyżej zmiana w kodzie nie podoba mi się, wycofałem to i dałem latin1 w sql_charset w conf_global.php. Wydaje się, że działa, na razie robię resynchronizację wszystkiego i czyszczę cache, ale już widzę, że jest raczej dobrze.

 

Po skończonej kompletnej resynchronizacji jeszcze wszystko posprawdzam i potwierdzę.

 

Ta zmiana jeszcze ujdzie, bo jest w konfiguracji, więc nie będzie się wysypywać przy aktualizacjach.

 

Czy ktoś jest w stanie wyjaśnić:

1) Dlaczego mam wybierać latin1, choć ani nic nie wskazuje, że baza jest tak zapisana, ani nie są tak ustawione sposoby kodowania znaków w bazie i porozumiewania się z nią, a sam wygląd bazy jest taki sam jak lokalnie, gdzie żadnego latin1 nie wybieram i to działa?

2) Czy to ustawienie nie niesie ryzyka, że forum nie będzie poprawnie obsługiwać unicode, pogubi nietypowe znaki z postów itp.?

[DawPi]

Ad 1 - widocznie jednak nie jest tam wszystko identycznie.

Ad 2 - nie powinno pogubić.