Hej,

Mam taki oto problem: baza danych i wszystkie tabele mają porównywanie "utf8_general_ci" i teraz próbuję napisać prosty skrypt, który pobiera coś z $_GET i wykonuje "SELECT" na jednej z tabel, np. tak:

[PHP] pobierz, plaintext 
$nazwisko=$_GET['nazwisko'];
(...) SELECT * FROM `tabela` WHERE nazwisko='$nazwisko' 
[PHP] pobierz, plaintext 

No i wszystko jest OK, dopóki $nazwisko nie zawiera polskich ogonków.

ps. jeśli na sztywno zrobię np: $nazwisko="źółkiewski" to też jest OK.

ps2. strona jest zapisana w utf8, a jeśli zrobię: echo $nazwisko to pojawi się prawidłowo np. "źółkiewski". Nie działa tylko jeśli "źółkiewski" przekażę w url'u.

Co mam z tym zrobić?

Spróbuj zmienić metodę porównywania napisów na "utf8_polish_ci"

Dzięki, ale nie mogę - ta tabela zawiera również dane w innych językach (np. francuski) stąd utf_general.

Pokaż strukturę tabeli

Pole Typ Metoda porównywania napisów

id int(11)
name_latin varchar(160) utf8_general_ci
name_pl varchar(160) utf8_general_ci
location varchar(160) utf8_general_ci
(...)


No wszędzie jest utf8_general_ci, plik zapisany jako utf8

edit: myślę, że to całe $_GET coś psuje, bo, tak jak wspomniałem - jeśli na sztywno zrobię np: $nazwisko="źółkiewski" to jest OK.

Do porównań typu "A jest równe B" nie ma znaczenia, jaki mechanizm porównań wybierzemy. One się przydają jedynie przy porównaniach według porządku leksykograficznego: czy słowo A jest wcześniej w porządku leksykograficznym niż B. utf8_general_ci to uproszczona, nieco szybsza lecz nie do końca dokładna wersja utf8_unicode_ci; jeśli chcemy mieć dokładne porównania, powinniśmy wybrać to drugie. Ponadto jeżeli trzymasz dane np. w języku francuskim, absolutnie nic nie szkodzi ustawić "ut8_polish_ci". Język francuski jest świetnie obsługiwany przez utf8_unicode_ci, dlatego nie ma potrzeby dla niego tworzyć specjalnej klasy, natomiast w polskim trzeba uwzględnić kilka specyficznych reguł, stąd mamy utf8_polish_ci. Jest to wykonane jako rozszerzenie domyślnego algorytmu, czyli język francuski w dalszym ciągu powinien być poprawnie sortowany, a dodatkowo zyskujesz poprawność przy tekstach polskich.

Natomiast jeśli chodzi o kodowanie - a jak wysyłasz tę zmienną w adresie? Formularz ją generuje czy jakaś funkcja? Wiesz, że musisz zakodować znaki zgodnie z kodowaniem UTF-8, aby skrypt to później poprawnie odczytał? Przykładowo, gdy w formularzu na stronie unikodowej wpiszę "ąęść", to dostanę w adresie:



A jeśli wpiszę "ąęść" bezpośrednio w pasku przeglądarki, zakoduje mi ona ten ciąg przy pomocy kodowania jednobajtowego:



i na stronie, która spodziewa się danych unikodowych, będą tutaj krzaki.

No tak mi się właśnie wydawało.

To jak mam przekonwertować dane z $_GET by było prawidłowo, zakładając, że string będzie wysłany przez formularz? (Tak konkretnie to przez ajax, który pobierze dane z formularza i odpali skrypt).

Jakoś google nie pomaga

edit: czyżby chodziło o urldecode ?
Ale jednej rzeczy nie za bardzo rozumiem... bo wiem, że po wpisaniu w url'u (w przeglądarce) znaczków np. polskich, to zamienia na %jakiśkod%, ale myślałem, że php sam się tym zajmuje, no bo jak zrobię:
echo $_GET['jakas_wartosc'] i podejrzę źródło strony, to jest ładnie wszystko przekonwertowane.

edit2: urldecode nie działa... poza tym w dokumentacji php znalazłem takie coś:
"The superglobals $_GET and $_REQUEST are already decoded. Using urldecode() on an element in $_GET or $_REQUEST could have unexpected and dangerous results. "

edit3: no dobra, zadziałało, gdy zrobiłem takie coś:

$nazwisko=iconv('cp1250', 'utf-8', $nazwisko);

Ale czemu? I skąd mam wiedzieć jakiego kodowania użyć w pierwszym parametrze, skoro strona jest międzynarodowa i user może pochodzić z dowolnego kraju....

Nie no, poddaje się. To owszem, działa, ale tylko pod FF i IE, pod Chrome już nie działa (pod Chrome działa za to zwyczajne echo $nazwisko)