[MySQL][PHP] Kodowanie znaków - 2 pytania |
[MySQL][PHP] Kodowanie znaków - 2 pytania |
12.07.2015, 20:42:39
Post
#1
|
|
Grupa: Zarejestrowani Postów: 46 Pomógł: 1 Dołączył: 23.04.2011 Ostrzeżenie: (0%) |
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 |
|
|
12.07.2015, 21:52:00
Post
#2
|
|
Grupa: Zarejestrowani Postów: 3 033 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
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
Ten post edytował com 12.07.2015, 21:52:38 |
|
|
13.07.2015, 07:25:36
Post
#3
|
|
Grupa: Zarejestrowani Postów: 139 Pomógł: 24 Dołączył: 12.05.2013 Skąd: Hamburg Ostrzeżenie: (0%) |
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 Ten post edytował Xelah 13.07.2015, 07:45:26 |
|
|
13.07.2015, 11:54:31
Post
#4
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 30 Dołączył: 22.01.2007 Ostrzeżenie: (0%) |
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 Ten post edytował prz3kus 13.07.2015, 12:07:37 |
|
|
13.07.2015, 12:57:09
Post
#5
|
|
Grupa: Zarejestrowani Postów: 139 Pomógł: 24 Dołączył: 12.05.2013 Skąd: Hamburg Ostrzeżenie: (0%) |
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:
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). |
|
|
13.07.2015, 13:17:57
Post
#6
|
|
Grupa: Zarejestrowani Postów: 260 Pomógł: 30 Dołączył: 22.01.2007 Ostrzeżenie: (0%) |
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 |
|
|
13.07.2015, 14:08:44
Post
#7
|
|
Grupa: Zarejestrowani Postów: 139 Pomógł: 24 Dołączył: 12.05.2013 Skąd: Hamburg Ostrzeżenie: (0%) |
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:
i nasępnie select z bazy UNICODE. PostgreSQL po prostu robi konwersję on-the-fly z server encoding do client encoding. MySQL 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. Ten post edytował Xelah 13.07.2015, 14:39:56 |
|
|
13.07.2015, 15:50:36
Post
#8
|
|
Grupa: Zarejestrowani Postów: 3 033 Pomógł: 366 Dołączył: 24.05.2012 Ostrzeżenie: (0%) |
Xelah masz rację, zrobiłem zbyt duży skrót myślowy
|
|
|
13.07.2015, 16:58:35
Post
#9
|
|
Grupa: Zarejestrowani Postów: 46 Pomógł: 1 Dołączył: 23.04.2011 Ostrzeżenie: (0%) |
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??
Ten post edytował Baku12345 13.07.2015, 16:59:42 |
|
|
13.07.2015, 20:23:37
Post
#10
|
|
Grupa: Zarejestrowani Postów: 139 Pomógł: 24 Dołączył: 12.05.2013 Skąd: Hamburg Ostrzeżenie: (0%) |
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. |
|
|
14.07.2015, 01:02:52
Post
#11
|
|
Grupa: Zarejestrowani Postów: 46 Pomógł: 1 Dołączył: 23.04.2011 Ostrzeżenie: (0%) |
Jeszcze raz wszystkim dziękuję Plusiki poszły
|
|
|
Wersja Lo-Fi | Aktualny czas: 27.04.2024 - 14:37 |