forskjellige php kodinger

  1. Forfattere
  2. x64 (aka andi)

nybegynner skriptforfattere bryr seg ikke om en slik ting som koding

nybegynner skriptforfattere bryr seg ikke om en slik ting som koding. Derfor kan du på nettsteder ofte finne et forferdelig rot, når dataene fra databasen er oppnådd i en koding, blir siden dannet i en annen, og serveren får den tredje. Som et resultat, hvis siden kan dekrypteres, så minst 2 ganger. Så, hvorfor oppstår et slikt problem og hvordan man kan overvinne det?

I det russiske segmentet finner du oftest den såkalte Windows-kodingen. ring det annerledes: windows-1251, cp1251 eller til og med ansi. det neste er utf-8. Du kan også finne navnet unicode, men dette er ikke helt riktig, siden Unicode er det generelle navnet for hele gruppen (utf-8, utf-16, utf-32). og en veldig populær sjeldenhet er koi8-r eller bare koi-8 - den gang populære Linux-kodingen. Selvfølgelig er det mulig å møte noe annet i det russiske segmentet, men dette er snarere en "overbærenhet" av forfatteren.

Hovedforskjellen mellom utf-8 og andre (primært windows-1251 og koi8-r) er den siste enbyte, og det maksimale antall tegn som kan representeres ved hjelp av disse kodene, er begrenset til 256. Det er selvsagt at for en fullstendig presentasjon av teksten til dette Kan ikke være nok. og for html ble det funnet en løsning - bruken av såkalte mnemonics. for eksempel:

© - & copy;

foruten det faktum at hver slik karakter er beskrevet av en gruppe tegn, blir koden ulæselig og arbeidet med teksten blir mer komplisert. Dette er hvor multibyte utf-8 kommer til redning. Det er veldig praktisk å bruke bokstaver av forskjellige alfabeter og forskjellige symboler i en tekst.

Dermed er det mest behagelige settet av innledende forhold som følger: kodingen av databasen, php-skript og html-sider / js-skript bør være det samme. Selvfølgelig kan du bruke forskjellige, men i dette tilfellet er det fare for å bli forvirret. Det spiller ingen rolle hvilken kodeside som brukes. Hvis nettstedet bare er for et russisktalende publikum, vil windows-1251 være ganske nok. ellers ville utf-8 være det logiske valget. Det første alternativet er mer eller mindre klart. multibyte koding vil kreve noen bevegelser.

Når du arbeider med utf-8, vil en notisblokk ikke fungere ! Faktum er at denne redaktøren, når du lagrer en fil i denne kodingen, legger til en signatur i begynnelsen - 3 tegn, den såkalte bombe (byte-ordremerke), som kan brukes til å bestemme kodingen når du åpner en fil. det er bedre å velge en annen redaktør: Notepad2 eller notisblokk ++ . I innstillingene må du velge å lagre uten en signatur.

Det neste viktige trinnet er å jobbe med databasen. Det er svært ønskelig at kodingen av basen / tabellen / tekstfeltet samsvarer med skriptkodingen (det kan være cp1251 eller utf-8 eller noe annet). hvis dataene fra databasen er oppnådd i form av "zyuk", er det sannsynlig at kodingen av forbindelsen er forskjellig fra dataene lagret i databasen. Følgende spørsmål vil bidra til å overvinne situasjonen (utfør umiddelbart etter å ha koblet til databasen):

Hvis nettstedet bruker Windows-1251, bør du spesifisere det - cp1251.

Generelt er det ikke noe vanskelig. bare, standard php funksjoner er ikke designet for å arbeide med multibyte strenger. men det finnes standardbiblioteker som vil bidra til å rette opp situasjonen: iconv og mbstring . For regulære uttrykk er det også en nødvendig bryter som aktiveres med modifikatoren u .

Vel, dataene fra databasen er oppnådd, skriptene er skrevet i henhold til alle reglene. Det gjenstår å sende riktig tittel og vise sidekoden i brukerens nettleser. vi sender kursen slik:

header ('Content-Type: text / html; charset = utf-8');

hvis en-byte-koding brukes, vil verdien for charsetet være annerledes - windows-1251 . Deretter bør problemer ikke forbli.

Noen enkleste eksempler på å jobbe med utf-8 i php:

eksempel 1: iconv, antall tegn per linje

$ s = 'streng'; # streng i utf-8 $ cnt1 = strlen ($ s); # vil inneholde verdien $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # riktig verdi, 6

eksempel 2: mbstring, antall tegn i en streng

$ s = 'streng'; # streng i utf-8 $ cnt1 = strlen ($ s); # vil inneholde verdien $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # riktig verdi, 6

Eksempel 3: Vanlige uttrykk, søk og erstatt

$ s = 'String'; # linje i utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # erstatning vil ikke skje $ s = preg_replace ('/ p / iu', 'd', $ s); # resultatorddok

I modifikatoren foreskriver ikke-følsom søk, og u modifikatoren forteller den vanlige uttrykksmotoren for å jobbe med utf-8-strenger.

hvis noen sier at php ikke kan fungere med utf-8, vil det gå galt. I flere år har jeg gjort alle mine prosjekter i denne kodingen, og det var ingen problemer i det hele tatt. Søkemotorer har lenge brukt denne fantastiske kodingen.

Forfattere

frakoblet 11 timer

x64 (aka andi)

Kommentarer: 2846 Publikasjoner: 395 Registrering: 02-04-2009

Så, hvorfor oppstår et slikt problem og hvordan man kan overvinne det?

Новости

Карта