IE6: φ = Q = φ
FF3.0: .1% 84? Q =% F4
Chrome4: .1% 84? Q = .1% 84
Mai ales mulțumit de firefox. Ce caractere din partea de cale au fost codificate ca UTF-8 și în partea de interogare - ca CP-1251 (în general, un salut complet, în opinia mea).
upd: verificat: de la codarea paginii rezultatul nu depinde de niciun browser.
Puneți o rază de lumină, vă rog.
În mod obișnuit, alfabetul chirilic din adresa URL este codificat folosind metodele encodeURI și encodeURIComponent.
Firefox a făcut exact cum era de așteptat: url-ul este codificat în utf8 (un astfel de aranjament)
datele formularului apar în codarea paginii (astfel încât script-urile vor aștepta). IE6 a fost scris
Americani care nu știu decât latin1 (comparați cu IE7, pe care indienii au scris-o).
Chrome supărat: (Aparent, a fost scris de americani care cred că înlocuirea latin1 pe
utf8 duce la rezolvarea tuturor problemelor legate de codificare.
De regulă: nu folosiți litere ruse în url și așteptați parametrii în codarea paginii.
Codificarea este următorul pas.
Problema apare chiar înainte de codificare, deoarece ceea ce va fi codificat este diferit în diferite browsere.
Din IE 6 vine codificat φ? Q = φ. din FF - codat .1% 84? q =% F4. Și FIG înțelege că aceasta este aceeași pagină a venit.
Mai ales pentru firefox:
Rezultatul este același. Și nu se schimbă dacă codificarea este schimbată în latin-1.
Astfel, aceste forme provin mai degrabă în codificarea Windows decât în codarea paginii (aceasta este singura mea presupunere despre motivul pentru care codifică cererea GET în CP-1251 atât de persistent), iar adresa URL este codificată ca UTF-8.
De regulă: nu folosiți litere ruse în url și așteptați parametrii în codarea paginii.
Din păcate, trebuie să colectez date nu din paginile mele. Care nu se știe în ce browser sunt vizualizate și în general necunoscute de cine au fost făcute.
Cred deja că acum nu faceți o listă de utilizatori-agenți pe cele mai frecvente browsere și nu înțeleg fiecare caz manual.
Mă întreb cum se descurcă liveinternetul cu asta.
În general, este necesar să ne gândim. Mă simt, cu excepția faptului că o sălbăticie nu vine cu nimic.
Dacă nu mergeți în junglă de codificare chirilică de către browsere și rezolvați sarcina (colectați url-uri și jurnaliști js-counters), atunci puteți lua o decizie cu privire la liră. Iată codul contorului lor:
Dacă vă uitați atent, rețineți că pentru a codifica adresele URL, acestea utilizează metoda de evacuare, care convertește șirul la unicode hexazecimale. Pe server este necesar să executați unescape pentru câmpurile recepționate. Nu există o astfel de funcție în PHP, dar puteți găsi implementări. După ce php_unescape (apelat, de exemplu) se execută pe serverul urldecode, în cazul în care adresa URL era în codificarea standard URI.
Acesta? Sau am înțeles greșit sarcina.
Da, este același lucru (eu, în general, l-am folosit, doar am confundat-o în unele locuri, așa că am avut greșeli).
Am venit aici cu câteva gânduri, despre care voi spune până acum două:
2. Math.random () este conceput pentru a împiedica caching-ul. Ar putea fi realizat prin trimiterea unei imagini cu antetul "Cache-control: no-cache" de pe serverul de counter?
Reprezentantul nu este întotdeauna transmis - securitatea, firewall-urile și unii clienți îl taie. nu-cache-ul nu se aplică tuturor clienților. Există, de exemplu, cazuri în care în rețeaua locală există un proxy de cache (pentru salvarea traficului), care înregistrează scoruri la zero.
Trimiteți-le prietenilor: