Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [PHP] $_GET, kodowanie i różnice w przeglądarkach Opera FF
Forum PHP.pl > Forum > Przedszkole
neverever
Dziwna sprawa...

Mam bazę z ustawionym kodowaniem latin2_general_ci, nawiązując połączenie daję oczywiście: mysql_query('SET NAMES latin2',$conn);
Na stronie mam ustawione oczywiście ISO-8859-2.

Teraz łądnie mi dodaje nowe wpisy, ładnie też je pobiera i wyświetla - polskie znaki są ok.

...i teraz pojawia się problem!

Pobrane z bazy słowa są użyte do generowana linków, gdzie to są przekazywane w formie parametru GETem.

przekazywane są plskie znaki, wszystkie inne znaki specjalne są wycinane a spacje zamieniane na -
czyli link ma postać index.php?param=kraków-20-05-2008

Pod Operą by mi dobrze gwyświetało odebrznego geta muszę przekodować:
echo iconv("UTF-8","ISO-8859-2", urldecode($_GET['param']));

pod FF natomiast wtedy mi urywa na polskim znaku.

Ale jak dam:
echo urldecode($_GET['param']);

to pod FF dobrze pokazuje, ale pod operą ó zamienia na krzaczki.

Co jest grane?
erix
Na stronie jakie masz ustawione kodowanie?
neverever
Na stronie mam ustawione ISO-8859-2.

Problem w tym, że w linku muszę przekazać polskie znaki w postaci jawnej - zatem urlencode odpada.

Zrobiłęm sobie prosty skrypt testowy wyświetlający otrzymaną zmienną $_GET i zarzucam mu np. słowo: kraków
Zatem w przeglądarce wklejam linka o postaci: http://localhost/test.php?in=kraków

Opera i IE zamieniają go na: http://localhost/test.php?in=krak%C3%B3w
i wyświetlają w efekcie: krakĂłw

A FF zamienia ten link na: http://localhost/test.php?in=krak%F3w
i wyświetla w efekcie słowo: kraków

Zatem Opera i IE polskie znaki kodują inaczej niż FF!

Żeby pod Operą i IE otrzymać poprawny ciag, muszę otzymaną GETem zmienną przekodować przy użyciu iconv utf-8/iso-8859-2
-no ale wtedy FF niepoprawnie pokazuje wynik - ucina na polskich znakach pokazując tylko: krak

Problem znika jeśli zmienię kodowanie strony na UTF-8 a otrzymaną GETem zmienną potraktuję urldecode.

Jak sobie z tym poradzić zachowując kodowanie strony ISO-8859-2 ?
Podkreślam! znaki w linku muszą mieć postać "jawną" - czyli np.: http://localhost/test.php?in=kraków
hiszpanespaniol
jestem zielony z PHP, ale jesli się wywoła phpinfo, to można sprawdzić jakiej się używa przeglądarki. jest też sposób aby się dowiedziec jakiej używa przeglądarki ktoś kto odwiedza stronę, za pomocą wyszukiwania odpowiedniego ciągu znaków. Wtedy mógłbyś osobno zrobić skrypt dla Opery a osobno dla Fiefox. Szczegółów na ten temat jest mnóstwo, w manualu też jest bo pamiętam. To tylko takja sugestia jest, zapewne o tym sposobie wiesz

PS. konkretnie chodzi mi o get_browser()
PiXel2.0
Wydaje mi sie, ze nie da sie rozwiazac tego problemu z poziomu skryptu.

Tutaj chodzi o kodowanie tekstu wprowadzanego recznie do paska adresu i rozne przegladarki roznie go koduja (prawdopodobnie zalezy to od ustawien przegladarki u klienta).

Pomijajac kodowanie URL:
krak%C3%B3w jest kodowane w UTF-8
krak%F3w jest kodowane w ISO

Jasli utworzysz taki dokument z polskim znakiem w odnosniku (obojetnie czy to HTML czy PHP):
  1. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
  2. <html xmlns="http://www.w3.org/1999/xhtml">
  3. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-2" />
  4. <title>Untitled Document</title>
  5. </head>
  6. <a href="http://localhost/test.php?in=kraków">test</a>
  7. </body>
  8. </html>


to zadeklarowane kodowanie wymusi na przegladarce zakodowanie polskich znakow w adresach odnosnikow w iso-8859-2.

Wtedy w kazdej przegladarce bedzie w pasku adresu:
http://localhost/test.php?in=krak%F3w

Jesli jednak wpiszesz ten aders recznie z polskim znakiem to przegladarka nie wie jak bedzie zakodowany dokument ktorego jeszcze nie pobrala i zakoduje ten znak wg swoich wlasnych domyslnych ustawien.

Opera akurat koduje w UTF-8 a FF w ISO.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2025 Invision Power Services, Inc.