Aktywne Wpisy

Pangia +142
ja p------ę, ktoś tarpanem przyjechał na świąteczne zakupy do biedronki
#czarneblachy
#czarneblachy
źródło: 1000011370
Pobierz
KladzSie +11
Tak dawno nie piłem yerby poleccie coś trendy #yerbamate #yerbamatewykopclub





Mam pytanie odnośnie kodowania. Moja cała baza to UTF-8 a dokładnie utf8mb4generalci debile z hostingu ustawili sobie:
Kodowanie znaków serwera: ISO 8859-2 Central European (latin2)
I teraz w prestashop w back office jak i czasami na front office wyskakują krzaki mimo że w bazie jest normalnie z ogonkami.
Czy istnieje jakaś możliwość zmusić za pomocą .htaccess do kodowania UTF-8?
Próbowałem AddDefaultCharset utf-8 w htaccess ale nie działa. Dodam że na innych serwerach wyświetla się poprawnie bo zrobiłem kopię 1/1.
https://stackoverflow.com/questions/6115612/how-to-convert-an-entire-mysql-database-characterset-and-collation-to-utf-8
Lepiej tak niż SQL przerabiać i dodawać charset do zapytań
Jaka wersja PS?
@sohost @LuckyLuke_2776
Okazuje się że skur... z cyberfolks zmieniły sobie kodowanie serwera kiedyś było UTF-8 a teraz jest latin2 i połowa kodowania wpadła do bazy z latin2 a połowa UTF-8. Przy eksporcie z bazy z dopiskiem --default-character-set=latin2 wszystko zamienia się na ogonki jak powinno być. Tylko niestety
@airflame: Ja to robię ręcznie w Sublime Text bawiąc się opcjami FILE >> Reopen with encoding / Save with encoding i naprzemiennie z firefoxem i VIEW >> Repair text encoding eksperymentując z różnymi kodowaniami. Manipuluję plikiem i zawsze się jakoś udawało od 14 lat ( ͡° ͜ʖ ͡°)
header('Content-Type: text/html; charset=utf-8');Ogólnie w TPL tam gdzie się nie wyświetlają polskie znaki jest
<meta charset="utf-8">
Więc wysyłany zapewne jest latin2 z php bezpośrednio. Zapewne jest tam wzmianka aby używał serwera albo not set. Więc zaciąga default latin2