Podstrony
- telcocafe
- [php] Dodanie textu do pliku. Problem... :) POMOCY!!!!!!!!!!!!!
- Problem ze zgrywaniem z kamery Problem ze zgrywaniem z kamery
- [JS] Problem ze skryptem pobierającym źródło strony skrypt pobierający źródło strony
- Głupi problem HELP !!!
- [JS, jQuery] Problem z przejściem z JS na jQuery
- [HTML] 2 problemy z html-em
- [domena] Problem z domeną
- Problem z O/C - Barton 2800+ AMD Athlon XP 2800+ Barton
- Problem z SP2 NIE uruchamia mi sie system !!!
- Problem z Koszem systemowym POMOCY!!!
- zanotowane.pl
- doc.pisz.pl
- pdf.pisz.pl
- taatry.keep.pl
telcocafe
Zaktualizowałem pakiet WebServ - więc PHP z 5.1.5 nad 5.2.3 i MySQL z 4 na 5. Teraz w przeglądarce nie wyświetlają się polskie znaki w pobranych danych z bazy. Aktualizacja rekordów z poziomu PHP też nic nie daje. MySQL 5 dodatkowo jeszcze posiada mechanizm porównywania znaków.Fragment my.ini:
language=c:/usr/mysql/share/polish character-set-server=latin2 default-character-set=latin2
Zmienne MySQL:
character_set_system=utf8 (I tego nie mogę zmienić)Pozostałe zmienne - collation_* i character_set_* (opr. _filesystem = binary) mają wartość LATIN2.
Tabele również mają kodowanie latin2, lecz nie mogą zapamiętać porównania znaków (ustawiam latin2_general_ci, nie ma polish_ci), chyba że MySQL-Front po prostu ich nie odczytuje.
Pomaga dopiero poniższe zapytanie wywołane po rozpoczęciu połączenia:
SET CHARACTER SET 'latin2'Tylko dla nowo wprowadzonych danych.
Czym to jest spowodowane? Nieprawidłową konwersją bazy danych? Czy da się ten problem ominąć bez dodatkowego zapytania, czy w skryptach dla MySQL 5 to raczej standard? A może lepiej postawić na UTF?
Użytkownik Ferrari edytował ten post 26 lipiec 2007, 13:02
Nie znam odpowiedzi na twoje pytania, ale używając MySQl 5 napotkałem taką sytuację. Napisałem programik w c#, który komunikuje się właśnie z MySQL5. Tablice mam kodowane Latin2 i kiedy coś do bazy zapisuję lub z niej czytam wszystko jest ok, ale kiedy robię backup bazy a potem ją przywracam, to przy kodowaniu Latin2 gubią się polskie znaki. Natomiast ta operacja wykonana z domyślnym kodowaniem UTF8 nie gubi polskich znaków. Zastanawiałem się długo z czego to może wynikać i nie znalazłem odpowiedzi.
Może ktoś inny coś podpowie? Chętnie bym poczytał.
Dokładnie to nie wiem sam czemu tak jest... Ale napewno co radze zrobic to skorzystac jednak z kodowanie utf8.
Tylko dla nowo wprowadzonych danych.
No bo tak bedzie :) Nowo wprowadzone rekordy są zakodowane poprawnie według latin2. Ja bym radził ci zrobic backup bazy. A potem wartosci w backupie pozamieniac na inne kodowanie tak by działało prawidłowo. Mozna do tego celu uzyc programu Gżegżółka badz e-textmate. Zamien kodowanie backupu na utf8. i prowadz cała baze w utf-8. Sprawdz takze czy kodowanie strony masz ustawione wtedy na utf8 :)
W skrypcie używam ISO-8859-2, więc nie wiem, czy po nagłej zmianie na UTF-8 wszystko się nie rozsypie. Ponadto pliki i teksty w utf8 zajmują więcej miejsca.
Wracam jednak do pytania - czy wykonywanie zapytania ustawiającego kodowanie jest potrzebne?
Więcej miejsca zajmują jedynie pliki,w ktorych użyte zostały polskie znaki (2 bity na polski znak,1 bit na zwykły). Czy cały czas to nie wiem,ponieważ nie używam - sam mam utf-8 i wszystko jest dobrze :) Może poza tym,że PMA nie wyświetla poprawnie polskich znaków . . . Ale ominąłem to własnym MySQL Adminem :D
PhpMyAdmin jest raczej nastawiony bardziej na obsługę UTF niż Latin. :) Dobrze by było, aby MySQL nie musiał konwertować specjalnie znaków dla PHP.
Poczytam jeszcze o UTF. Jak myślicie - warto? Jednak czy po aktualizacji CMS-a, który w nowej wersji nagle używa UTF-8, jego użytkownikom na stronach nie posypie się tekst? Dane są raczej zapisywane w utf8 - przynajmniej to domyślne ustawienie w MySQL, z jakim spotkałem się na większości serwerów.
...
Użytkownik Ferrari edytował ten post 26 lipiec 2007, 20:17
(2 bity na polski znak,1 bit na zwykły)
Bajty, prosze pana, bajty. :P
Jak z wydajnością UTF-8 względem iso-8859-2? Weź trochę wyluzuj... W jaki sposób zmiana kodowania miałaby zauważalnie wpłynąć na wydajność... CMSa?!
Niestety MySQL nie jest "latin-przyjazne". Wiele skryptów stosuje UTF-8 i problemów z stronami w różnych językach nie ma. W bazie ustawiasz kodowanie utf-8, a w skrypcie jedynie w HEAD dajesz utf-8 i zrobione.
Konwersja: iso -> utf8: musiałbyś przekodować za pomocą iconv (PHP) albo ińszych metod na utf.
Jak z wydajnością UTF-8 względem iso-8859-2?
Po prostu musiałeś zadać to pytanie, czyż nie? :)
Chyba jednak przejdę na UTF-8. W latin2 z angielskim i niemieckim nie powinno być problemu, ale jak ktoś by chciał pisać np. po rusku to wtedy gorzej. Lepiej zresztą oszczędzać na zbędnym kodzie HTML niż na zawartości. :)