kodowanie UTF w MySQL

[Pała 0]

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

[shive 0]

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.

[patryk 451]

Moim zdaniem jest to niezbyt fachowe podejście do sprawy.

 

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

[shive 0]

Dobrze skonfigurowany myAdmin nie wymaga myślenia Nie licz na inteligencję usera, bo nie ma na co liczyć.

[Irvin 0]

Hmm, czyli stosowanie UTF-8 uważasz za 'nieprofesjonalne' ??

 

I don't think so...

[shive 0]

Nie, po prostu uważam, że powinienem mieć możliwość wyboru ISO, a domyślne ustawienia powinny być również na ISO.

[Irvin 0]

Hmm no w sumie racja

 

To tak jak z demokracją w polsce - teoretcznie mamy wybór

[shive 0]

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...

[bezsciemy 0]

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?

[shive 0]

Piszę o domyślnej metodzie porównywania napisów oraz kodowaniu znaków przechowywanych w bazie.

[tabor23 0]

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ę

 

Pozdarwiam

Piotr

[Śledziu 0]

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.

[Gość]

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

[tabor23 0]

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.

[Noone 19]

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

[tabor23 0]

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.

[Gość normanos]

SET NAMES nigdy mnie nie zawiodło.

[tabor23 0]

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 )

[tabor23 0]

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?

[Gość patrick]

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

[tabor23 0]

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.

[hyhyhy 0]

Polecam program GżegżółkaXP, gzegzolka.com ;-) Pozdr.

[tabor23 0]

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ę

Jeszcze raz dzięki.

 

p