Witam
Mój problem nie polega na tym, że coś mi nie działa, lecz na tym, że kilka rzeczy nie rozumiem. Proszę wiec o wyjaśnienie. Mam sobie taki przykładowy fragment kodu



Jest tu po lewej u góry znacznik meta, kóry mówi, jakie jest kodowanie strony, a sam plik jest również zapisany w UTF-8 (widać to po prawej u dołu). Dlaczego więc gdy usunę linię 13-stą

$pdo -> exec("SET NAMES 'utf8'");

to zaczynają się wyświetlać krzaki Reszta plików strony jest zapisana również w UTF-8 więc powinno być wydaje mi się ok, nawet bez tej linijki. Baza danych jak i tabele tak samo są zapisane w UTF-8



Więc w czym problem, dlaczego żeby zachować poprawne kodowanie w bazie i na stronie to muszę wstawiać linijkę 13 wymuszając prawidłowe kodowanie

------

Drugie pytanie brzmi tak. Czytałem, że utf8_general_ci jest wydajniejsze od utf8_unicode_ci, czy w takim razie powinienem w dreamweaverze ustawić utf8_general_ci Jeśli tak to gdzie to się ustawia? bo jak na razie jak widać na obrazku pierwszym (po prawej na dole) plik jest zapisany w unicode, a baza w general.

Z góry dziękuję za odpowiedzi

tak ponieważ mysql nie zgadnie jakim kodowaniem ma pobierać rekordy z bazy, stad tez trzeba mu o tym powiedzieć, utf8 w plikach to po prostu utf8, błędem jest jak w plikach php dajesz go z bom

To jest nieco bardziej skomplikowane niż com to przedstaił ;)

Chodzi o to, że domyślnie MySQL na styku klient-serwer spodziewa się ASCII. Jeśli domyślna konfiguracja nie została zmieniona, to oczywiście serwer poda UTF-8 (bo tak jest w bazie) ale klient i tak dostanie ASCII, bo tak jest skonfigurowany on i połączenie do serwera. Plik z kodem źródłowym czy kodowanie bazy nie mają tu nic do rzeczy.
Problem jest właśnie na styku klient-serwer.

Tutaj masz więcej na ten temat:
http://dev.mysql.com/doc/refman/5.0/en/cha...connection.html

hmmmm Ja nie ogarniam tego co napisałeś ale pewnie masz racje

To może bardziej łopatologicznie.

Klient wysyła zapytanie do serwera. Serwer nie może się domyślić jakie jest użyte kodowanie z zapytaniu więc tą informacje bierze albo z konfiguracji albo od klienta.
Przykład:

[SQL] pobierz, plaintext 
SELECT * FROM tabel1 WHERE some_field="字編碼";
[SQL] pobierz, plaintext 

Jeśli klient nie powie serwerowi, że to jest UTF-8 a domyślnie serwer jest ustawiony na ASCII, to nawet jak pole some_field ma "字編碼" to i tak serwer nic nie znajdzie, bo nie dostanie "字編碼" tylko krzaki.

To samo dzieje się, kiedy serwer wyciąga dane z bazy. Kolumna jest UTF-8 no i serwer wyciąga w UTF-8. Teraz musi to wysłać do klienta. Jeśli domyślna konfiguracja to ASCII, to masz ten sam problem co wyżej. Dlatego albo ustawiasz to w plikach konfiguracyjnych albo musisz to zmienić live albo poprzez SET NAMES albo bezpośrednio przez API: mysqli::set_charset (lepsze i szybsze rozwiązanie niż SET NAMES).

Czegoś się dowiedziałem dzisiaj, w robocie siedze na posgresie albo MSSQL, a tam nigdy takich problemów nie zaobserwowałem
Myslałem, że głupoty piszesz na początku, a tutaj taka nowinka.

Dzięki za odpowiedz i dzieki za pytanie dla autora

Nie wiem jak to jest w MSSQL, ale PostgreSQL ma coś podobnego do MySQL (oczywiście nie dokładnie to samo, ale zbliżone):

Ustaw na serwerze bazę na UNICODE. Potem w kliencie zrób:

[SQL] pobierz, plaintext 
SET CLIENT_ENCODING TO 'LATIN1';
[SQL] pobierz, plaintext 

i nasępnie select z bazy UNICODE.

PostgreSQL po prostu robi konwersję on-the-fly z server encoding do client encoding. MySQL zwraca krzaki po prostu obetnie to, czego nie potrafi zrozumieć, albo zapoda z krzaków jeśli kodowania są źle ustawione. A PostgreSQL wali błędem (jeśli nie znajdzie mapowania do, w tym przypadku, LATIN1).

Więcej na ten temat jest tutaj:

http://www.postgresql.org/docs/9.4/static/multibyte.html

Bezsprzecznie PostgreSQL radzi sobie tutaj o niebo lepiej i jego zachowanie jest bardziej logiczne niż MySQL-a.

Xelah masz rację, zrobiłem zbyt duży skrót myślowy

Dziękuję wszystkim za odpowiedzi, to mi trochę rozjaśniło A mam jeszcze takie pytanko, czy nie powinienem w takim razie tego kodowania ujednolicić, tzn skoro w prawym dolnym rogu Dreamweavera pisze Unicode (UTF-8), to nie powinienem w bazie ustawić kodowania utf8_unicode_ci zamiast utf8_general_ci Niby general jest wydajniejszy z tego co czytałem, ale czy nie lepiej żeby unicode było i tu i tu??

Kodowanie pliku nie ma za dużo wspólnego z metodą porównywania w bazie. Plik jest w UTF-8. To jest właśnie kodowanie. Nazwa "Unicode" to tylko definicja każdego możliwego znaku (bez względu na użyte kodowanie). W przypadku kodowania UTF-8 jeden znak będzie reprezentowany na co najmniej 8 bitach, w URF-16 na 16 itd.

Żeby to bardziej uprościć, można powiedzieć, że UTF-8 czy UCS2 to sposób zapisu tak zwanych "code points" definiowanych w Unicode.

W ten sposób działa kodowanie w pliku.

To, o czym Ty wspomniałeś (utf8_general_ci i utf8_unicode_ci) to tylko metoda, jakiej używa baza do porównania znaków (mniejszy, większy, równy) zapisanych, w tym przypadku, w UTF-8. general_ci jest dosyć prymitywny i ma sporo problemów z niektórymi skryptami. unicode_ci z kolei o radzi sobie o wiele lepiej.

Tutaj masz obie metody:
http://collation-charts.org/mysql60/mysql6...i.european.html
http://collation-charts.org/mysql60/mysql6...i.european.html


To ma znaczenie przy wyszukiwaniu w bazie i sortowaniu. Ale nie ma kompletnie niczego wspólnego z UTF-8 o którym mowa w kodowaniu znaków w pliku. I baza i plik mają UTF-8. To jest jedyna istotna informacja.

Wybór metody porównywania znaków jest zależny tylko i wyłącznie od Twoich konkretnych potrzeb.

Jeszcze raz wszystkim dziękuję Plusiki poszły