[a.....e]

#programowanie #mysql #php #hosting #pytanie #pytaniedoeksperta #informatyka

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.

[LuckyLuke_2776]

@airflame: a nie możesz ALTER Database zrobić na inny charset?

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ń

[a.....e]

@LuckyLuke_2776: Tak jak wspomniałem baza jest w UTF-8 nie muszę już tego wykonywać. Problem jest z serwerem i wymuszaniem tego gównianego latin2

[LuckyLuke_2776]

@airflame: tzn? no jak jest w utf-8, a serwer w latin2, to baze zmień na latin2 i już, żeby nie pisać w SQL "USING iso-8859-2 COLLATE iso-8859-2" czy tam SELECT CONVERT(column USING iso...) itp. Czy jednak zawziącie chcesz bronić tego utf-8 bo tak i c--j bo to najlepsze co może być i musi być utf-8? Jak tak, to zmień serwer ( ͡° ͜ʖ ͡°)

[a.....e]

@LuckyLuke_2776: No problem będzie jak w prestashop masz language Polish i przy dodawaniu cms do bazy UTF-8 wpadnie a nie latin2 :)

[sohost]

@airflame wyczyść cache prestashop.

[a.....e]

@sohost Jest wyczyszczona i nawet nie włączona

[theqkash]

@airflame: AddDefaultCharset ustawia Ci kodowanie na poziomie pliku wyjściowego, a z tego co piszesz to problem masz w samej komunikacji z bazą. Bo rozumiem że inne rzeczy z ogonkami (takie jak np. stałe elementy menu albo panel admina) wyswietlają się prawidłowo?
Jaka wersja PS?

[a.....e]

@theqkash: Wersja 1.7.8.9. W panelu admina wyświetlają się krzaki czasami w front office. Ale chyba wiem co już jest nie tak.

@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

[LuckyLuke_2776]

Przydał by się program który by zamienił latin2 kodowanie w istniejącej już bazie na utf-8 nie psując utf-8

@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 ( ͡° ͜ʖ ͡°)

[a.....e]

@LuckyLuke_2776: Wiesz wydaje mi się że to jednak nie chodzi o samą mysql. Wydaje mi się że w niektórych php nie ma linijki do kodowania utf-8 czyli plik zaczytuje z bazy utf-8 a serwer ma kodowanie default latin2 i wyskakują krzaki bo serwer czyta za pomocą latin2.

Zmieniłem wszystko na ogonki w kodowaniu utf-8 ale nadal krzaki w back office.

Hosting musi wymusić UTF-8 na serwie inaczej się chyba nie

[LuckyLuke_2776]

@airflame: Jak tak, to sprawdziłbym kodowanie pliku .php samego w sobie, oraz wrzucił do wyświetlania header('Content-Type: text/html; charset=utf-8');

[a.....e]

@LuckyLuke_2776: No właśnie nie chcę zmieniać nic w PS bo potem przy aktualizacji to i tak będzie wipeout :/

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