Ĺadny brzuch
Wiem, że już było. Wiem, że pełno tego w necie. Ale próbowałem już różnych kombinacji i nic. Mam w MySQL relację zawierającą słowa. Niektóre zawierają polskie znaki, np. "ś". W zależności od ustawień w pliku konfiguracyjnym w linii poleceń SQL widzę albo "ś" albo "?". Jednak niezależnie od tego po wywołaniu skryptu PHP w przeglądarce wyświetla mi się "?" albo romb ze znakiem zapytania w środku. Proszę o konkretne rady, co gdzie na co zmienić żeby działało.
Zmieniałem już plik my.ini w sekcjach client, mysql i mysqld; dodawałem linię AddDefaultCharset w pliku konfiguracyjnym serwera (Apache 2.2); zmieniałem kodowanie strony (XHTML); w skrypcie PHP zaraz po połączeniu się z bazą danych wywoływałem funkcję mysql_query z "set names", "set character set" i "set collation_connection"; teraz edytowałem jeszcze plik php.ini. Jednak nic nie działa - w przeglądarce krzaki (przy normalnym wywołaniu echo('ś') wyświetla poprawnie). Czytałem też o funkcji header, ale tego nie próbowałem jeszcze. Zmieniałem też kodowanie na UTF-8. Ogólnie teraz wszędzie mam latin-2. Zaznaczam, że nie używam PHP MyAdmin.
//EDIT: Chyba pomyliłem działy ;P Będę wdzięczny za przeniesienie tematu ;)
Użytkownik ROB4L edytował ten post 18 październik 2008, 18:30
Wiem, że już było. Wiem, że pełno tego w necie. Ale próbowałem już różnych kombinacji i nic. Mam w MySQL relację zawierającą słowa. Niektóre zawierają polskie znaki, np. "ś". W zależności od ustawień w pliku konfiguracyjnym w linii poleceń SQL widzę albo "ś" albo "?". Jednak niezależnie od tego po wywołaniu skryptu PHP w przeglądarce wyświetla mi się "?" albo romb ze znakiem zapytania w środku. Proszę o konkretne rady, co gdzie na co zmienić żeby działało.
Zmieniałem już plik my.ini w sekcjach client, mysql i mysqld; dodawałem linię AddDefaultCharset w pliku konfiguracyjnym serwera (Apache 2.2); zmieniałem kodowanie strony (XHTML); w skrypcie PHP zaraz po połączeniu się z bazą danych wywoływałem funkcję mysql_query z "set names", "set character set" i "set collation_connection"; teraz edytowałem jeszcze plik php.ini. Jednak nic nie działa - w przeglądarce krzaki (przy normalnym wywołaniu echo('ś') wyświetla poprawnie). Czytałem też o funkcji header, ale tego nie próbowałem jeszcze. Zmieniałem też kodowanie na UTF-8. Ogólnie teraz wszędzie mam latin-2. Zaznaczam, że nie używam PHP MyAdmin.
//EDIT: Chyba pomyliłem działy ;P Będę wdzięczny za przeniesienie tematu ;)
Ja konwertuje przed zapisaniem do bazy danych tekst do charset=iso-8859-2 i nie ma później problemów
A jak to zrobić?
A jak to zrobić?
$aa = strtr($aa, "\xA5\x8C\x8F\xB9\x9C\x9F", "\xA1\xA6\xAC\xB1\xB6\xBC");
http://webmade.org/p...aracter-set.php
http://dev.mysql.com...connection.html
Użytkownik Kozack edytował ten post 18 październik 2008, 20:01
http://webmade.org/p...aracter-set.php
http://dev.mysql.com...connection.html
Próbowałem wywoływać zapytania z obu tych stron, ale żadna nie podaje jakie wartości mam podać żeby wyświetlić polskie znaki, a o to mi chodzi. Już próbowałem z różnymi ale nie działa. To samo tyczy się ustawień w plikach konfiguracyjnych itd. Dlatego pytam o konkretne wartości a nie o "narzędzia".
Zainstalowałem tego PMA i "metoda porównywania napisów" jest ustawiona na latin2_general_ci, co jest zgodne z tym o czym pisałem na początku.
Statjacek -> ale przy jakich ustawieniach kodowania w bazie (plik konfiguracyjny), czy dodawać linijkę adddefaultcharset w konfiguracji serwera, czy wykorzystywać na początku skryptu zapisującego 'set names' itp.?
//EDIT: Już sobie jakoś poradziłem, chociaż nie jest to "pełne" rozwiązanie. Ogólnie w pliku my.ini w każdej sekcji mam ustawione kodowanie na latin2 - po [client], [mysql], [mysqld] znajduje się linijka default-character-set=latin2. Za pomocą PHP MyAdmin dla danej relacji (tabeli) pole Metoda porównywania napisów jest ustawione na latin2_bin. Ponadto w skrypcie PHP odczytującym dane z bazy zaraz po połączeniu się z bazą dodałem linijkę mysql_query("SET NAMES latin2;");. Nie sprawdzałem jeszcze zapisu; tylko sam odczyt. Rozwiązanie niepełne bo w necie widziałem też takie nie wymagające dodawania tej linijki w skryptach no i zapis nieprzetestowany. Jak coś wykombinuję to dopiszę tutaj dla potomnych ;P
Użytkownik ROB4L edytował ten post 18 październik 2008, 23:09
Po ustawieniu tego samego kodowania na stronie (set names) oraz w bazie dane wrzucane przez stronę będą przez nią poprawnie odczytywane (nawet jeśli w adminie nie widać polskich znaków). Innaczej po prostu się nie da. W jaki sposób dodawałeś dane do bazy? Czy admin wyświetla polskie znaki? Jakie ustawiłeś kodowanie znaków w HTMLu?
Użytkownik Kozack edytował ten post 19 październik 2008, 13:31
W HTML-u miałem oczywiście iso-8859-2. Dane do bazy dodawałem przez tą konsolkę mysql-a. Odczytując dane za jej pomocą widziałem polskie znaki a na stronie już nie - nawet pomimo użycia 'set names', 'set client_character_set' (czy jakoś tak ;) ).
Nie jest to takie oczywiste, bo często (nawet nie wiem czy nie częściej) używa się teraz UNICODE :)
Dodawaj dane przez skrypt albo phpMyAdmina (ustaw na pierwszej stronie metodę porównywania znaków dla połączenia). Widocznie nie ustawiłeś odpowiedniego kodowania podczas dodawania danych przez konsolę.
Użytkownik Kozack edytował ten post 19 październik 2008, 14:53
Raz ustawiałem, ale na latin2_general_ci. PMA wskazywał na to, że jest ustawione latin2_general_ci. Jednak dopiero latin2_bin dało poprawne wyniki. Tylko nie wiem dlaczego, bo to w sumie było jedno z najczęściej polecanych kodować w necie. Grunt, że wypisuje te polskie znaki.
A z tym unicode, to chodzi o utf8, tak? Z tym też trochę kombinowałem, chociaż ogólnie nastawiłem się bardziej na latin2 ;)
Raz ustawiałem, ale na latin2_general_ci. PMA wskazywał na to, że jest ustawione latin2_general_ci. Jednak dopiero latin2_bin dało poprawne wyniki. Tylko nie wiem dlaczego, bo to w sumie było jedno z najczęściej polecanych kodować w necie. Grunt, że wypisuje te polskie znaki.
A z tym unicode, to chodzi o utf8, tak? Z tym też trochę kombinowałem, chociaż ogólnie nastawiłem się bardziej na latin2 ;)
ustaw w PHPMyAdmin latin2 i dane z formularza konwertuj. Będzie ok
Użytkownik statjacek edytował ten post 19 październik 2008, 22:06
Wytłumacz mi dlaczego konwertujesz akurat z cp1250 na latin2? Kodujesz strony w cp1250?
Użytkownik Kozack edytował ten post 20 październik 2008, 12:07
Wytłumacz mi dlaczego konwertujesz akurat z cp1250 na latin2? Kodujesz strony w cp1250?
Nie. Mam charset=iso-8859-2. Ze strony jest wysyłany formularz z danymi tekstowymi z pól takich jak: textarea czy input. W polach tych tekst jest wpisany przez userów więc nie podlega żadnemu kodowaniu. Czyli jest w takiej formie jak go napisał User czyli 1250. Zmienne z formularza trafiają do skryptu php nie posiadają kodowania charset=iso-8859-2. Jeśli w nie zmienionej formie się je zapisze do bazy danych będą problemy z Polskimi znakami.
@statjacek:
Bzdury gadasz. Formularze przejmują kodowanie z dokumentu, więc jeśli jest izolatka, to izolatkę wyśle agent (już on ma się zająć konwersją). Jeśli jednak się uprzeć, wtedy można umieścić w formularzu atrybut kodowania i gotowe.
Użytkownik andrzej_aa edytował ten post 20 październik 2008, 20:04
@statjacek:
Bzdury gadasz. Formularze przejmują kodowanie z dokumentu, więc jeśli jest izolatka, to izolatkę wyśle agent (już on ma się zająć konwersją). Jeśli jednak się uprzeć, wtedy można umieścić w formularzu atrybut kodowania i gotowe.
Nie wiem co to jest izolatka. Naturalnie próbowałem wielokrotnie wysłać formularz Postem i nigdy nie było kodowania. Dopiero po konwersji było ok. Być może to jest zależne od ustawień serwera.
izolatka = iso-8859-2
Jak to nie było kodowania? Wytłumacz mi jak wygląda tekst, który nie posiada strony kodowej. Strona kodowa określa jak wyglądają znaki o poszczególnych kodach. Na przykład kod 161 w latin2 to "Ą", ale w cp1250 "Ą" jest przypisane do kodu 165. Jeśli zmienisz kodowanie na stronie, to zmienią się nie dane, a jedynie sposób ich wyświetlania, ale jeśli dokonasz konwersji, to wszystkie znaki o kodzie 161 zostaną zamienione na 165 itd.
Tekst wprowadzany do formularza jest w takiej stronie kodowej jakiej używa system, przeglądarka konwertuje dane do strony kodowej, którą ustawisz w dokumencie. Skoro w dokumencie ustawiłeś latin2, to dane polecą właśnie w takiej stronie kodowej.
Aby uniknąć problemów z kodowaniem wymyślono UNICODE (już sama nazwa coś sugeruje). Do dokumentu wstawiasz:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
Dokument należy zapisać w formacie UTF-8 without BOM. A zaraz po połączeniu z MySQLem:
set names utf8;
I żadna konwersja od tej pory nie jest potrzebna. Jeśli w bazie ustawisz inną strone kodową, to zostanie dokonana automatyczna konwersja, ponieważ serwer wie, że dane przychodzą w postaci UTF-8. Takie coś działa i nie ma innej opcji.
Użytkownik Kozack edytował ten post 21 październik 2008, 11:03
izolatka = iso-8859-2
Jak to nie było kodowania? Wytłumacz mi jak wygląda tekst, który nie posiada strony kodowej. Strona kodowa określa jak wyglądają znaki o poszczególnych kodach. Na przykład kod 161 w latin2 to "Ą", ale w cp1250 "Ą" jest przypisane do kodu 165. Jeśli zmienisz kodowanie na stronie, to zmienią się nie dane, a jedynie sposób ich wyświetlania, ale jeśli dokonasz konwersji, to wszystkie znaki o kodzie 161 zostaną zamienione na 165 itd.
Tekst wprowadzany do formularza jest w takiej stronie kodowej jakiej używa system, przeglądarka konwertuje dane do strony kodowej, którą ustawisz w dokumencie. Skoro w dokumencie ustawiłeś latin2, to dane polecą właśnie w takiej stronie kodowej.
Aby uniknąć problemów z kodowaniem wymyślono UNICODE (już sama nazwa coś sugeruje). Do dokumentu wstawiasz:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
Dokument należy zapisać w formacie UTF-8 without BOM. A zaraz po połączeniu z MySQLem:
set names utf8;
I żadna konwersja od tej pory nie jest potrzebna. Jeśli w bazie ustawisz inną strone kodową, to zostanie dokonana automatyczna konwersja, ponieważ serwer wie, że dane przychodzą w postaci UTF-8. Takie coś działa i nie ma innej opcji.
Być może w przypadku utf-8 tak jest, ale w przypadku iso-8859-2 na moim serwerze niestety bez konwersji jest lipa.
zanotowane.pl doc.pisz.pl pdf.pisz.pl zsf.htw.pl
Zmieniałem już plik my.ini w sekcjach client, mysql i mysqld; dodawałem linię AddDefaultCharset w pliku konfiguracyjnym serwera (Apache 2.2); zmieniałem kodowanie strony (XHTML); w skrypcie PHP zaraz po połączeniu się z bazą danych wywoływałem funkcję mysql_query z "set names", "set character set" i "set collation_connection"; teraz edytowałem jeszcze plik php.ini. Jednak nic nie działa - w przeglądarce krzaki (przy normalnym wywołaniu echo('ś') wyświetla poprawnie). Czytałem też o funkcji header, ale tego nie próbowałem jeszcze. Zmieniałem też kodowanie na UTF-8. Ogólnie teraz wszędzie mam latin-2. Zaznaczam, że nie używam PHP MyAdmin.
//EDIT: Chyba pomyliłem działy ;P Będę wdzięczny za przeniesienie tematu ;)
Użytkownik ROB4L edytował ten post 18 październik 2008, 18:30
Wiem, że już było. Wiem, że pełno tego w necie. Ale próbowałem już różnych kombinacji i nic. Mam w MySQL relację zawierającą słowa. Niektóre zawierają polskie znaki, np. "ś". W zależności od ustawień w pliku konfiguracyjnym w linii poleceń SQL widzę albo "ś" albo "?". Jednak niezależnie od tego po wywołaniu skryptu PHP w przeglądarce wyświetla mi się "?" albo romb ze znakiem zapytania w środku. Proszę o konkretne rady, co gdzie na co zmienić żeby działało.
Zmieniałem już plik my.ini w sekcjach client, mysql i mysqld; dodawałem linię AddDefaultCharset w pliku konfiguracyjnym serwera (Apache 2.2); zmieniałem kodowanie strony (XHTML); w skrypcie PHP zaraz po połączeniu się z bazą danych wywoływałem funkcję mysql_query z "set names", "set character set" i "set collation_connection"; teraz edytowałem jeszcze plik php.ini. Jednak nic nie działa - w przeglądarce krzaki (przy normalnym wywołaniu echo('ś') wyświetla poprawnie). Czytałem też o funkcji header, ale tego nie próbowałem jeszcze. Zmieniałem też kodowanie na UTF-8. Ogólnie teraz wszędzie mam latin-2. Zaznaczam, że nie używam PHP MyAdmin.
//EDIT: Chyba pomyliłem działy ;P Będę wdzięczny za przeniesienie tematu ;)
Ja konwertuje przed zapisaniem do bazy danych tekst do charset=iso-8859-2 i nie ma później problemów
A jak to zrobić?
A jak to zrobić?
$aa = strtr($aa, "\xA5\x8C\x8F\xB9\x9C\x9F", "\xA1\xA6\xAC\xB1\xB6\xBC");
http://webmade.org/p...aracter-set.php
http://dev.mysql.com...connection.html
Użytkownik Kozack edytował ten post 18 październik 2008, 20:01
http://webmade.org/p...aracter-set.php
http://dev.mysql.com...connection.html
Próbowałem wywoływać zapytania z obu tych stron, ale żadna nie podaje jakie wartości mam podać żeby wyświetlić polskie znaki, a o to mi chodzi. Już próbowałem z różnymi ale nie działa. To samo tyczy się ustawień w plikach konfiguracyjnych itd. Dlatego pytam o konkretne wartości a nie o "narzędzia".
Zainstalowałem tego PMA i "metoda porównywania napisów" jest ustawiona na latin2_general_ci, co jest zgodne z tym o czym pisałem na początku.
Statjacek -> ale przy jakich ustawieniach kodowania w bazie (plik konfiguracyjny), czy dodawać linijkę adddefaultcharset w konfiguracji serwera, czy wykorzystywać na początku skryptu zapisującego 'set names' itp.?
//EDIT: Już sobie jakoś poradziłem, chociaż nie jest to "pełne" rozwiązanie. Ogólnie w pliku my.ini w każdej sekcji mam ustawione kodowanie na latin2 - po [client], [mysql], [mysqld] znajduje się linijka default-character-set=latin2. Za pomocą PHP MyAdmin dla danej relacji (tabeli) pole Metoda porównywania napisów jest ustawione na latin2_bin. Ponadto w skrypcie PHP odczytującym dane z bazy zaraz po połączeniu się z bazą dodałem linijkę mysql_query("SET NAMES latin2;");. Nie sprawdzałem jeszcze zapisu; tylko sam odczyt. Rozwiązanie niepełne bo w necie widziałem też takie nie wymagające dodawania tej linijki w skryptach no i zapis nieprzetestowany. Jak coś wykombinuję to dopiszę tutaj dla potomnych ;P
Użytkownik ROB4L edytował ten post 18 październik 2008, 23:09
Po ustawieniu tego samego kodowania na stronie (set names) oraz w bazie dane wrzucane przez stronę będą przez nią poprawnie odczytywane (nawet jeśli w adminie nie widać polskich znaków). Innaczej po prostu się nie da. W jaki sposób dodawałeś dane do bazy? Czy admin wyświetla polskie znaki? Jakie ustawiłeś kodowanie znaków w HTMLu?
Użytkownik Kozack edytował ten post 19 październik 2008, 13:31
W HTML-u miałem oczywiście iso-8859-2. Dane do bazy dodawałem przez tą konsolkę mysql-a. Odczytując dane za jej pomocą widziałem polskie znaki a na stronie już nie - nawet pomimo użycia 'set names', 'set client_character_set' (czy jakoś tak ;) ).
Nie jest to takie oczywiste, bo często (nawet nie wiem czy nie częściej) używa się teraz UNICODE :)
Dodawaj dane przez skrypt albo phpMyAdmina (ustaw na pierwszej stronie metodę porównywania znaków dla połączenia). Widocznie nie ustawiłeś odpowiedniego kodowania podczas dodawania danych przez konsolę.
Użytkownik Kozack edytował ten post 19 październik 2008, 14:53
Raz ustawiałem, ale na latin2_general_ci. PMA wskazywał na to, że jest ustawione latin2_general_ci. Jednak dopiero latin2_bin dało poprawne wyniki. Tylko nie wiem dlaczego, bo to w sumie było jedno z najczęściej polecanych kodować w necie. Grunt, że wypisuje te polskie znaki.
A z tym unicode, to chodzi o utf8, tak? Z tym też trochę kombinowałem, chociaż ogólnie nastawiłem się bardziej na latin2 ;)
Raz ustawiałem, ale na latin2_general_ci. PMA wskazywał na to, że jest ustawione latin2_general_ci. Jednak dopiero latin2_bin dało poprawne wyniki. Tylko nie wiem dlaczego, bo to w sumie było jedno z najczęściej polecanych kodować w necie. Grunt, że wypisuje te polskie znaki.
A z tym unicode, to chodzi o utf8, tak? Z tym też trochę kombinowałem, chociaż ogólnie nastawiłem się bardziej na latin2 ;)
ustaw w PHPMyAdmin latin2 i dane z formularza konwertuj. Będzie ok
Użytkownik statjacek edytował ten post 19 październik 2008, 22:06
Wytłumacz mi dlaczego konwertujesz akurat z cp1250 na latin2? Kodujesz strony w cp1250?
Użytkownik Kozack edytował ten post 20 październik 2008, 12:07
Wytłumacz mi dlaczego konwertujesz akurat z cp1250 na latin2? Kodujesz strony w cp1250?
Nie. Mam charset=iso-8859-2. Ze strony jest wysyłany formularz z danymi tekstowymi z pól takich jak: textarea czy input. W polach tych tekst jest wpisany przez userów więc nie podlega żadnemu kodowaniu. Czyli jest w takiej formie jak go napisał User czyli 1250. Zmienne z formularza trafiają do skryptu php nie posiadają kodowania charset=iso-8859-2. Jeśli w nie zmienionej formie się je zapisze do bazy danych będą problemy z Polskimi znakami.
@statjacek:
Bzdury gadasz. Formularze przejmują kodowanie z dokumentu, więc jeśli jest izolatka, to izolatkę wyśle agent (już on ma się zająć konwersją). Jeśli jednak się uprzeć, wtedy można umieścić w formularzu atrybut kodowania i gotowe.
Użytkownik andrzej_aa edytował ten post 20 październik 2008, 20:04
@statjacek:
Bzdury gadasz. Formularze przejmują kodowanie z dokumentu, więc jeśli jest izolatka, to izolatkę wyśle agent (już on ma się zająć konwersją). Jeśli jednak się uprzeć, wtedy można umieścić w formularzu atrybut kodowania i gotowe.
Nie wiem co to jest izolatka. Naturalnie próbowałem wielokrotnie wysłać formularz Postem i nigdy nie było kodowania. Dopiero po konwersji było ok. Być może to jest zależne od ustawień serwera.
izolatka = iso-8859-2
Jak to nie było kodowania? Wytłumacz mi jak wygląda tekst, który nie posiada strony kodowej. Strona kodowa określa jak wyglądają znaki o poszczególnych kodach. Na przykład kod 161 w latin2 to "Ą", ale w cp1250 "Ą" jest przypisane do kodu 165. Jeśli zmienisz kodowanie na stronie, to zmienią się nie dane, a jedynie sposób ich wyświetlania, ale jeśli dokonasz konwersji, to wszystkie znaki o kodzie 161 zostaną zamienione na 165 itd.
Tekst wprowadzany do formularza jest w takiej stronie kodowej jakiej używa system, przeglądarka konwertuje dane do strony kodowej, którą ustawisz w dokumencie. Skoro w dokumencie ustawiłeś latin2, to dane polecą właśnie w takiej stronie kodowej.
Aby uniknąć problemów z kodowaniem wymyślono UNICODE (już sama nazwa coś sugeruje). Do dokumentu wstawiasz:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
Dokument należy zapisać w formacie UTF-8 without BOM. A zaraz po połączeniu z MySQLem:
set names utf8;
I żadna konwersja od tej pory nie jest potrzebna. Jeśli w bazie ustawisz inną strone kodową, to zostanie dokonana automatyczna konwersja, ponieważ serwer wie, że dane przychodzą w postaci UTF-8. Takie coś działa i nie ma innej opcji.
Użytkownik Kozack edytował ten post 21 październik 2008, 11:03
izolatka = iso-8859-2
Jak to nie było kodowania? Wytłumacz mi jak wygląda tekst, który nie posiada strony kodowej. Strona kodowa określa jak wyglądają znaki o poszczególnych kodach. Na przykład kod 161 w latin2 to "Ą", ale w cp1250 "Ą" jest przypisane do kodu 165. Jeśli zmienisz kodowanie na stronie, to zmienią się nie dane, a jedynie sposób ich wyświetlania, ale jeśli dokonasz konwersji, to wszystkie znaki o kodzie 161 zostaną zamienione na 165 itd.
Tekst wprowadzany do formularza jest w takiej stronie kodowej jakiej używa system, przeglądarka konwertuje dane do strony kodowej, którą ustawisz w dokumencie. Skoro w dokumencie ustawiłeś latin2, to dane polecą właśnie w takiej stronie kodowej.
Aby uniknąć problemów z kodowaniem wymyślono UNICODE (już sama nazwa coś sugeruje). Do dokumentu wstawiasz:
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
Dokument należy zapisać w formacie UTF-8 without BOM. A zaraz po połączeniu z MySQLem:
set names utf8;
I żadna konwersja od tej pory nie jest potrzebna. Jeśli w bazie ustawisz inną strone kodową, to zostanie dokonana automatyczna konwersja, ponieważ serwer wie, że dane przychodzą w postaci UTF-8. Takie coś działa i nie ma innej opcji.
Być może w przypadku utf-8 tak jest, ale w przypadku iso-8859-2 na moim serwerze niestety bez konwersji jest lipa.