1. Издавач
2. x64 (aka andi)

писателите на сценаристите за почетници не се грижат за такво нешто како кодирање. Затоа, на сајтови понекогаш може да се најде страшно неред, кога податоците од базата на податоци се добиваат во едно кодирање, страната се формира во друга, а на серверот му се дава трето. како резултат на тоа, ако страницата може да се декриптира, а потоа најмалку 2 пати. Значи, зошто се случува таков проблем и како да се надмине тоа?

во рускиот сегмент најчесто можете да ги најдете т.н. прозорец-кодирање. наречете го поинаку: windows-1251, cp1251 или дури и ansi. следното е UTF-8. Можете исто така да го најдете името Уникод, но ова не е сосема точно, бидејќи Уникод е општото име за целата група (utf-8, utf-16, utf-32). и многу популарна реткост е koi8-r или едноставно koi-8 - некогаш популарна кодирање на Linux. Се разбира, можно е да се сретнеме со нешто друго во рускиот сегмент, но ова е прилично "попустливост" од страна на авторот.

Главната разлика помеѓу utf-8 и другите (првенствено windows-1251 и koi8-r) е последниот еден-бајт, а максималниот број на знаци кои можат да бидат претставени со користење на овие кодови е ограничен на 256. Се разбира, за целосна презентација на текстот на оваа можеби не е доволно. и за html беше пронајдено решение - употребата на т.н. мнемоника. на пример:

© - и копија;

Освен фактот дека секој таков карактер е опишан од група на знаци, кодот станува нечитлив и работата со текстот станува посложена. ова е местото каде што multibyte utf-8 доаѓа до спасување. многу е погодно да се користат букви од различни азбуки и различни симболи во еден текст.

Така, најудобна група на почетни услови е како што следува: кодирањето на базата на податоци, php скриптите и html страниците / js скриптите треба да бидат исти. Се разбира, можете да користите различни, но во овој случај постои ризик од збунетост. не е важно која код страница се користи. ако сајтот е само за публика од руски јазик, Windows-1251 ќе биде сосема доволно. во спротивно, UTF-8 би бил логичен избор. првата опција е повеќе или помалку јасна. мултибајт кодирање ќе бара некои гестови.

Кога работите со utf-8, стандардна тетратка за белешки нема да работи ! Факт е дека овој уредувач, кога зачувува датотека во ова кодирање, додава потпис на почетокот - 3 знаци, таканаречениот bom (byte byte mark), кој може да се користи за одредување на кодирањето при отварање на датотека. подобро е да се избере друг уредувач: notepad2 или notepad ++ . во поставките мора да одберете да зачувате без потпис.

Следниот важен чекор е да работиме со базата на податоци. Многу е пожелно кодирањето на полето base / table / text да одговара на кодирањето на сценариото (може да биде cp1251 или utf-8, или нешто друго). ако податоците од базата на податоци се добиени во форма на "zyuk", најверојатно кодирањето на врската е различно од податоците зачувани во базата на податоци. Следното барање ќе помогне да се надмине ситуацијата (изврши веднаш по поврзувањето со базата на податоци):

ако сајтот користи windows-1251, треба да го наведете - cp1251.

воопшто, нема ништо тешко. само, стандардните php функции не се дизајнирани да работат со мултибајтни стрингови. но постојат стандардни библиотеки што ќе помогнат да се исправи ситуацијата: iconv и mbstring . за регуларни изрази, таму е исто така потребен прекинувач кој се активира со модификаторот u .

Па, податоците од базата на податоци се добиваат, скриптите се напишани според сите правила. Останува да се испрати точниот наслов и да се прикаже кодот на страницата во прелистувачот на корисникот. ние испраќаме наслов така:

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

ако се користи единечно бајт кодирање, вредноста за табелата ќе биде различна - windows-1251 . После тоа, проблемите не треба да останат.

Некои наједноставни примери за работа со utf-8 во php:

пример 1: iconv, број на знаци по линија

$ s = 'стринг'; # стринг во utf-8 $ cnt1 = strlen ($ s); # ќе ја содржи вредноста $ 12 cnt2 = iconv_strlen ($ s, 'UTF-8'); # точна вредност, 6

пример 2: mbstring, бројот на знаци во низа

$ s = 'стринг'; # стринг во utf-8 $ cnt1 = strlen ($ s); # ќе ја содржи вредноста $ 12 cnt2 = mb_strlen ($ s, 'UTF-8'); # точна вредност, 6

пример 3: регуларни изрази, пребарување и замена

$ s = 'Стринг'; # линија во utf-8 $ s = preg_replace ('/ p / i', 'd', $ s); # Замена нема да се случи $ s = preg_replace ('/ p / iu', 'd', $ s); # резултат збор док

i модификаторот пропишува несензитивно пребарување, а u модификаторот му кажува на моторот за регуларен израз да работи со utf-8 стрингови.

ако некој рече дека php не може да работи со utf-8, тоа ќе биде погрешно. Веќе неколку години ги правам сите мои проекти во ова кодирање и воопшто немам проблеми. Самите пребарувачи веќе долго време го користеа ова прекрасно шифрирање.

Издавач

присутен 11 часа

x64 (aka andi)

Коментари: 2846 Публикации: 395 Регистрација: 02-04-2009