novice script skribenter er ligeglad med sådan en ting som kodning. På steder kan du til tider finde et forfærdeligt rod, når dataene fra databasen er opnået i en kodning, bliver siden dannet i en anden, og serveren får den tredje. Som et resultat, hvis siden kan dekrypteres, så mindst 2 gange. Så hvorfor opstår et sådant problem, og hvordan man overvinder det?
I det russiske segment kan du oftest finde den såkaldte Windows-kodning. kalder det anderledes: windows-1251, cp1251 eller endda ansi. det næste er utf-8. Du kan også finde navnet unicode, men det er ikke helt korrekt, da Unicode er det generelle navn for hele gruppen (utf-8, utf-16, utf-32). og en meget populær sjældenhed er koi8-r eller simpelthen koi-8 - den engang populære Linux-kodning. Det er selvfølgelig muligt at møde noget andet i det russiske segment, men det er snarere en "overbærenhed" af forfatteren.
Hovedforskellen mellem utf-8 og andre (primært windows-1251 og koi8-r) er den sidste enbyte, og det maksimale antal tegn, der kan repræsenteres ved hjælp af disse kodninger, er begrænset til 256. Det siger sig selv, at for en komplet præsentation af denne tekst Måske er det ikke nok. og for html blev der fundet en løsning - brugen af såkaldte mnemonics. for eksempel:
© - & copy;
foruden det faktum, at hver sådan karakter beskrives af en gruppe tegn, bliver koden ulæselig og arbejdet med teksten bliver mere kompliceret. Det er her, hvor multibyte utf-8 kommer til undsætning. Det er meget praktisk at bruge bogstaver af forskellige alfabeter og forskellige symboler i en tekst.
Således er det mest behagelige sæt af indledende betingelser som følger: Kodningen af databasen, php scripts og html sider / js scripts bør være den samme. Selvfølgelig kan du bruge forskellige, men i dette tilfælde er der risiko for at blive forvirret. det er ligegyldigt hvilken kode side der bruges. Hvis webstedet kun er til et russisk talende publikum, vil windows-1251 være nok. ellers ville utf-8 være det logiske valg. den første mulighed er mere eller mindre klar. multibyte kodning vil kræve nogle bevægelser.
Når du arbejder med utf-8, vil en standard notesblok ikke fungere ! Faktum er, at denne editor, når du gemmer en fil i denne kodning, tilføjer en signatur til starten - 3 tegn, den såkaldte bom (byte-ordre), som kan bruges til at bestemme kodningen, når du åbner en fil. det er bedre at vælge en anden editor: Notepad2 eller notesblok ++ . i indstillingerne skal du vælge at gemme uden en underskrift.
Det næste vigtige skridt arbejder med databasen. Det er yderst ønskeligt, at kodningen af basen / tabellen / tekstfeltet passer til scriptkodningen (det kan være cp1251 eller utf-8 eller noget andet). hvis dataene fra databasen er opnået i form af "zyuk", er det sandsynligvis, at kodningen af forbindelsen er forskellig fra de data, der er lagret i databasen. Følgende forespørgsel hjælper med at overvinde situationen (udfør umiddelbart efter tilslutning til databasen):
Hvis webstedet bruger Windows-1251, skal du angive det - cp1251.
Generelt er der ikke noget svært. kun standard php funktioner er ikke designet til at arbejde med multibyte strenge. men der er standard biblioteker, der vil hjælpe med at rette op på situationen: iconv og mbstring . For regulære udtryk er der også en nødvendig switch, der aktiveres med modifikatoren u .
Nå er dataene fra databasen opnået, scripts er skrevet i overensstemmelse med alle reglerne. Det er fortsat at sende den korrekte titel og vise sidekoden i brugerens browser. vi sender overskriften således:
header ('Content-Type: text / html; charset = utf-8');
hvis der anvendes single-byte-kodning, vil værdien for charset være anderledes - windows-1251 . Derefter bør problemer ikke forblive.
Nogle enkleste eksempler på at arbejde med utf-8 i php:
Eksempel 1: ikonv, antal tegn pr. linje
$ s = 'streng'; # streng i utf-8 $ cnt1 = strlen ($ s); # vil indeholde værdien $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # Korrekt værdi, 6
Eksempel 2: mbstring, antallet af tegn i en streng
$ s = 'streng'; # streng i utf-8 $ cnt1 = strlen ($ s); # vil indeholde værdien $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # Korrekt værdi, 6
Eksempel 3: Regulære udtryk, Søg og erstat
$ s = 'String'; # linje i utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # udskiftning sker ikke $ s = preg_replace ('/ p / iu', 'd', $ s); # resultatorddok
I modifikatoren foreskriver tilfælde af ufølsom søgning, og u- modifikatoren fortæller den regulære ekspressionsmotor at arbejde med utf-8-strenge.
hvis nogen siger at php ikke kan fungere med utf-8, vil det være forkert. I flere år har jeg nu gjort alle mine projekter i denne kodning, og der var slet ingen problemer. Søgemaskiner selv har længe brugt denne vidunderlige kodning.
Forfattere
offline 11 timer
x64 (aka andi)
Kommentarer: 2846 Publikationer: 395 Registrering: 02-04-2009
Så hvorfor opstår et sådant problem, og hvordan man overvinder det?