diferite codificări php
scriitorii de scenarii novice nu le pasă de un astfel de lucru ca de codificare. Prin urmare, pe site-uri uneori găsiți o mizerie teribilă, atunci când datele din baza de date sunt obținute într-o singură codificare, pagina este formată într-un altul, iar serverul este dat celui de-al treilea. ca rezultat, dacă pagina poate fi decriptată, atunci cel puțin de 2 ori. Deci, de ce se întâmplă o astfel de problemă și cum să o depășiți?
în segmentul rus cel mai adesea puteți găsi așa-numita codificare ferestre. numiți-l diferit: windows-1251, cp1251 sau chiar ansi. următorul este utf-8. De asemenea, puteți găsi numele unicode, dar acest lucru nu este complet corect, deoarece Unicode este numele general pentru întregul grup (utf-8, utf-16, utf-32). și o raritate foarte populară este koi8-r sau pur și simplu koi-8 - codarea o dată populară de Linux. Desigur, este posibil să se întâlnească și altceva în segmentul rus, dar aceasta este mai degrabă o "îngăduință" de autor.
Principala diferență dintre utf-8 și altele (în primul rând windows-1251 și koi8-r) este ultimul octet, iar numărul maxim de caractere care pot fi reprezentate folosind aceste codificări este limitat la 256. Este de la sine înțeles că pentru o prezentare completă a acestui text poate să nu fie suficient. și pentru html a fost găsită o soluție - utilizarea așa-numitelor mnemonice. de exemplu:
© - & copy;
Pe lângă faptul că fiecare astfel de caracter este descris de un grup de caractere, codul devine necitit și lucrul cu textul devine mai complicat. acesta este locul unde utf-8 multibite vine la salvare. este foarte convenabil să folosiți litere de alfabete diferite și simboluri diferite într-un singur text.
Astfel, cel mai confortabil set de condiții inițiale este după cum urmează: codarea bazei de date, scripturile php și paginile html / js ar trebui să fie aceleași. Desigur, puteți folosi altele, dar în acest caz există riscul de a deveni confuz. nu contează ce pagină de cod este utilizată. dacă site-ul este doar pentru un public vorbitor de limbă rusă, windows-1251 va fi suficient. altfel, utf-8 ar fi alegerea logică. prima opțiune este mai mult sau mai puțin clară. codificarea multibyte va necesita unele gesturi.
Când lucrați cu utf-8, un notepad notepad standard nu va funcționa ! Faptul este că acest editor, atunci când salvează un fișier în această codare, adaugă o semnătură la început - 3 caractere, așa-numitul bom (marcaj ordine byte), care poate fi folosit pentru a determina codificarea la deschiderea unui fișier. este mai bine să alegeți un alt editor: Notepad2 sau notepad ++ . în setările pe care trebuie să le salvați fără o semnătură.
Următorul pas important este colaborarea cu baza de date. Este foarte de dorit ca codarea câmpului de bază / tabel / text să se potrivească cu codarea scriptului (ar putea fi cp1251 sau utf-8 sau altceva). dacă datele din baza de date sunt obținute sub formă de "zyuk", cel mai probabil conexiunea de codare este diferită de datele stocate în baza de date. Următoarea interogare va ajuta la depășirea situației (executați imediat după conectarea la baza de date):
dacă site-ul folosește windows-1251, trebuie să-l specificați - cp1251.
în general, nu este nimic dificil. numai funcțiile standard php nu sunt proiectate să funcționeze cu șiruri multibyte. dar există biblioteci standard care vor ajuta la corectarea situației: inconv și mbstring . pentru expresiile regulate, există, de asemenea, un comutator necesar care este activat cu modificatorul u .
Ei bine, datele din baza de date sunt obținute, scripturile sunt scrise în conformitate cu toate regulile. Rămâne să trimiteți titlul corect și să afișați codul paginii în browserul utilizatorului. trimitem titlurile astfel:
antet ("Content-Type: text / html; charset = utf-8");
dacă se folosește codarea de un singur octet, valoarea pentru caractere va fi diferită - windows-1251 . După aceea, problemele nu ar trebui să rămână.
Câteva exemple mai simple de lucru cu utf-8 în php:
exemplul 1: iconv, numărul de caractere pe linie
$ s = 'șir'; # șir în utf-8 $ cnt1 = strlen ($ s); # va conține valoarea $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # valoare corectă, 6
exemplu 2: mbstring, numărul de caractere dintr-un șir
$ s = 'șir'; # șir în utf-8 $ cnt1 = strlen ($ s); # va conține valoarea $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # valoare corectă, 6
exemplul 3: expresii regulate, căutare și înlocuire
$ s = 'String'; # linie în utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # înlocuirea nu se va întâmpla $ s = preg_replace ('/ p / iu', 'd', $ s); # doc word result
modificatorul i prescrie căutarea insensibilă la minuscule și modificatorul u declară că motorul expresiei regulate funcționează cu șiruri utf-8.
dacă cineva spune că php nu poate funcționa cu utf-8, va fi greșit. De mai mulți ani am făcut toate proiectele mele în această codificare și nu au existat probleme. Motoarele de căutare au folosit mult timp această codificare minunată.
Autori
offline 11 ore
x64 (aka andi)
Comentarii: 2846 Publicații: 395 Înregistrare: 02-04-2009
Deci, de ce se întâmplă o astfel de problemă și cum să o depășiți?