Skocz do zawartości
Pała

kodowanie UTF w MySQL

Polecane posty

tak z ciekawosci mozna sie spytac co to jest i czym to sie objawia?

bo ja własnie mam strone na mambo i jeszcze galerie coppermine obydwa na MYSQL i wszystko lata zawodowo zadnych problemów dodam ze sam wszystko instalowałem tez zadnych problemów nie było.

 

Pozdrawiam

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Chodzi o to, że na większości porządnych hostingów mamy przezroczyste kodowanie ISO 8859-2, natomiast w wielu tanich hostingach do wyboru jest UTF i niedoświadczony user może mieć problem np. z importem baz z innego serwera, lub nieoczekiwane efekty porównywania znaków przy domyślnych ustawieniach. Moim zdaniem jest to niezbyt fachowe podejście do sprawy.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Moim zdaniem jest to niezbyt fachowe podejście do sprawy.

 

Przede wszystkim ze strony usera, ktory klika gdzie popadnie zamiast 5 sekund pomyslec :D.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Więc jeśli wchodzę do myAdmina a tak napaćkane UTFami (TYLKO UTFami), to mam pewne wątpliwości co do podejścia firmy do klienta...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Więc jeśli wchodzę do myAdmina a tak napaćkane UTFami (TYLKO UTFami), to mam pewne wątpliwości co do podejścia firmy do klienta...

Ty piszesz o kodowaniu bazy czy skryptów za pomocą których wprowadzasz dane do bazy?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

To chyba dobry temat aby napisać o moim problemie i zapytać o radę/pomoc.

 

Sprawa jest następująca:

Korzystam z hostingu, gdzie serwer zlokalizowany jest w UK. Korzystam od 2ch lat i absolutnie złego słowa nie mogę powiedzieć (prawdziwy support 24h/dobe) choć ostatnio dokonali prostego zabiegu zamiany waluty i teraz zamiast 20$ płacę 20GBP ;)

 

Moje umiejętności są takie, że znam HTML oraz CSS, potrafię sobie zainstalować Mambo, stworzyć bazę, nadać uprawnienia, zmienić layout itp. Generalnie swoje pomysły realizuję w oparciu o gotowe skrypty, które sam dostosowuję na własne potrzeby. mam więc całkiem fajny serwis oparty o Mambo i np katalog stron oparty o QLweb..

 

No i jak do tej pory wszystko było dobrze. Postanowiłem jednak stworzyć tym razem serwis ogłoszeniowy. No i tym razem nie znalazłem skryptu, który by mi odpowiadał dlatego postanowiłem skorzystać z oferty twórcy serwisu www.ogloszenia24.nazwa.pl - znaczy się mój serwis będzie oparty o ten skrypt - po drobnych przeróbkach.

No i niestety tym razem się wysypało - dokładniej polskie znaki w bazie danych.

Wersja robocza wygląda fatalnie www.lokale.slask.pl Tworca skryptu twierdzi, że winna może tu być wersja bazy MySQL, 4.1.10 zamias 4.1.11, na której on tworzył skrypt.

Ale do mnie to nie przemawia - przecież mam jeszcze inne serwisy i wszystko działa bez zarzutu.

 

ciekawe jest to, że dane nie wgrywane/czytazne z bazy danych wyświetlają się poprawnie. Natomiast wszystko co przechodzi przez bazę nie - zamiast polskich znaków pojawiają się znaki zapytania.

 

Co ciekawe, trochę niestety na oślep, ale za pomocą phpMyAdmin udało mi się zajrzeć do zawartosci tabel i okazało się, że tam też nie ma polskich znaków tylko znaki zapytania. No więc dla testów wyedytowałem zawartość jednego rekordu zamieniając znaki zapytania na polskie znaki. Niestety po tej operacji nadal nie uzyskałem polskich czcionek na stronie (choć podgląd zawartości komórki tabeli jest teraz dobry - czyli wyrazy zawierają polskie czcionki).

 

Serwer ma ustawione kodowanie na UTF8 więc takie też ustawiłem bazie przez phpMyadmin:

MySQL charset: UTF-8 Unicode (utf8)

MySQL connection collation: utf8_unicode_ci

collation (dla wszystkich pól) również: utf8_unicode_ci

 

Fakt faktem, w kodzie strony mam charset=iso-8859-2 ale nawet zmiana w przeglądarce nie daje poprawy.

Na koniec zobaczcie jeszcze dwa linki wskazująca niby to samo - a jednak nie:

http://www.lokale.slask.pl/txt.php?id=polityka

http://www.lokale.slask.pl/polityka.php

 

Na koniec zwrócę jeszcze uwagę na to, że skrypt pisany był w:

<meta name="generator" content="WebSite PRO 4.2">

też go mam i czasem to co się w nim zapisuje (zwłaszcza w php) nie działa tak jak powinno.

 

Nie znam się na tym więc szukam niestety "na ślepo". Może ktoś z was mógłby mi łopatologicznie wytłumaczyć w czym rzecz lub nawet pomóc za co na pewno się odpłacę :P

 

Pozdarwiam

Piotr

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Pobaw się collation utf8_polish_ci. I przekoduj (zmień kodowanie podczas save'owania pliku na utf8) może to coś da. Głowy za to nie dam.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość

Też mam problemy z kodowaniem przy zmianie serwa.. to jest jakaś parodia.. co serwer to krzaczki..

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Najzabawniejsze jest to, że 3 serwisy chodzą bez problemu a ten nagle wyrzuca mi tu takie historie.

Siedzę, klikam i tracę wiarę.

Podobno na serwerach nazwa.pl skrypt działa dobrze. No ale nie jest sztuką wyrzucić 300 na nowy serwer a na swoim mieć pusto.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Drugi link który podałeś mi nie działa ale pierwszy wskazuje że były źle zapisane do bazy - nie UTF-8.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

No tak, coś pogrzebałem przy sposobie zapisu pliku i teraz się w ogóle nie wyświetla.

Pierwszy link pobiera bezpośrednio z bazy danych, a drugi z pliku.

 

tak jak tutaj:

http://www.lokale.slask.pl/txt.php?id=reg - z bazy

http://www.lokale.slask.pl/reg.php - z pliku

 

ale nawet jak wejde do bazy i tam przeedytuje zawartość zmieniając znaki zapytania w polskie czcionki to na stronie jest bez zmian.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dzięki za podpowiedzi.

Nie wiem teraz po czyjej stronie leży wina - serwera, bazy czy skryptu. Gdzie najpierw powinienem szukać błędów lub niekompatybilności (ale mi się trudna alegoria napisała ;))

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

szybki update.

zamieniłem na:

MySQL charset: UTF-8 Unicode (utf8)

MySQL connection collation: utf8_polish_ci

collation (dla wszystkich pól) również: utf8_polish_ci

 

oraz znalazłem w tabeli config pole kodowanie gdzie było iso-8859-2 no i zamieniłem tam na utf8_polish_ci

efekt jest taki, że wszystko co jest w bazie do tego momentu jest nadal wyświetlane jako krzaki natomiast nowe ogłoszenia mają już polskie znaki

Efekt uboczny to to, ze elementy statyczne menu itp, które do tej pory były wyświetlane poprawnie się zakrzaczyły, ale to chyba dlatego, że skrypt jest pisany w iso-8859-2.

 

Mam teraz pytanie - czy wystarczy teraz tylko każdy z tych plików (plików skryptu) zapisać w formacie UTF8 ? są może jakieś programy do tego?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach
Gość patrick

A nie lepiej było wprowadzić konfiguracje "locales" taką jak na poprzednim serwerze mysql ?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

O ile dobrze zrozumiałem wyjaśnienia autora skryptu: na tamtym serwerze (nazwa.pl) jest dostepny charset = iso-8859-2, a na moim nie ma...

Tam wszystko pasuje no a tutaj nie ma polskich znaków.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Serdeczne dzięki za podpowiedzi.

Wyglada na to, że się uporałem ;)

 

Generalnie po zmianach w bazie na utf8_polish_ci trzeba było jeszcze raz zainstalować skrypt. Nie trzeba było go konwertować ani nic z nim robić tylko jeszcze raz wgrać do bazy. Co prawda w bazie polskie czcionki wyglądają jak krzaki, ale odczytywane i wyświetlane są poprawnie.

 

 

Jeszcze tylko odrobina grafffiki i startuję :D

Jeszcze raz dzięki.

 

p

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się


×