розныя кадоўкі ў php

  1. аўтар публікацыі
  2. x64 (aka andi)

пачаткоўцам скриптописателям глыбока пляваць на такое паняцце, як кадоўка

пачаткоўцам скриптописателям глыбока пляваць на такое паняцце, як кадоўка. таму на сайтах часам можна сустрэць жудасную кашу, калі дадзеныя з БД атрымліваюцца ў адной кадоўцы, старонка фарміруецца ў іншы, а серверам аддаецца трэцяя. у выніку старонку калі і можна расшыфраваць, то мінімум з 2 раз. дык вось, з-за чаго ж такая бяда здараецца і як яе перамагчы?

у рускім сегменце часцей за ўсё можна сустрэць так званую windows-кадоўку. называюць яе па-рознаму: windows-1251, cp1251 ці нават ansi. наступнай ідзе utf-8. можна сустрэць таксама назва unicode, але гэта не зусім карэктна, т. к. юнікод агульная назва для цэлай групы (utf-8, utf-16, utf-32). і ўжо зусім рарытэтам з'яўляецца папулярная koi8-r або проста якія-8 - некалі папулярная линуксовская кадоўка. вядома, можна ў рускім сегменце сустрэць і нешта іншае, але гэта хутчэй з'яўляецца «пястотай» аўтарам.

асноўнае адрозненне utf-8 ад іншых (у першую чаргу windows-1251 і koi8-r) - апошнія з'яўляюцца однобайтовыми, і максімальную колькасць сімвалаў, якія можна ўявіць з дапамогай дадзеных кадовак абмежаваць колькасьць 256. само-сабой, што для паўнавартаснага прадстаўлення тэксту гэтага можа быць недастаткова. і для html было знойдзена выйсце - выкарыстанне так званых Мнемонік. напрыклад, так:

© - & copy;

акрамя таго, што кожны такі сімвал апісваецца групай сімвалаў, код становіцца малочитаемым і праца з тэкстам ўскладняецца. тут-то і прыходзіць на дапамогу многобайтовая utf-8. вельмі зручна ў адным тэксце выкарыстоўваць літары розных алфавітаў і розныя сімвалы.

такім чынам, найбольш камфортны набор пачатковых умоў такой: кадоўка базы дадзеных, php-скрыптоў і html-старонак / js-скрыптоў павінна быць адной і той жа. вядома, можна выкарыстоўваць і розныя, але ў гэтым выпадку ёсць рызыка заблытацца. пры гэтым не важна, якая менавіта кодавая старонка выкарыстоўваецца. калі сайт будзе толькі для рускамоўнай аўдыторыі, windows-1251 будзе цалкам дастаткова. інакш лагічным выбарам будзе utf-8. з першым варыянтам ўсё больш-менш зразумела. а для шматбайтавую кадоўкі спатрэбяцца некаторыя рухі цела.

пры працы з utf-8 стандартны виндусовский notepad не падыдзе! справа ў тым, што дадзены рэдактар, пры захаванні файла ў гэтай кадыроўцы, дадае ў пачатак сігнатуру - 3 сімвала, так званы bom (byte order mark), паводле якога пры адкрыцці файла можна вызначыць кадыроўку. лепш выбраць іншы рэдактар: notepad2 або notepad ++ . у наладах абавязкова выбраць захаванне без сігнатуры.

наступны важны крок - праца з базай дадзеных. вельмі пажадана, каб кадоўка базы / табліцы / тэкставага поля супадалі з кадоўкай скрыпту (гэта можа быць cp1251 або utf-8, або што-небудзь іншае). калі дадзеныя з базы атрымліваюцца ў выглядзе «Зюков», хутчэй за ўсё кадоўка злучэнне адрозніваецца ад дадзеных, якія захоўваюцца ў БД. наступны запыт дапаможа перамагчы сітуацыю (выканаць адразу пасля злучэння з базай):

калі на сайце выкарыстоўваецца windows-1251, варта паказаць яе - cp1251.

увогуле-то, няма нічога складанага. адзіна, стандартныя функцыі php не прызначаныя для працы з многобайтовыми радкамі. але ёсць стандартныя бібліятэкі, якія дапамогуць выправіць сітуацыю: iconv і mbstring . для рэгулярных выразаў таксама існуе неабходны перамыкач, які актывуецца з дапамогай мадыфікатара u.

што ж, дадзеныя з базы атрыманы, скрыпты напісаныя па ўсіх правілах. застаецца адаслаць правільны загалоўкі і вывесці код старонкі ў браўзэр карыстача. загаловак пасылаем так:

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

калі выкарыстоўваецца однобайтовая кадоўка, тое значэнне для charset будзе іншым - 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 ( '/ стар / i', 'д', $ s); # Замена не адбудзецца $ s = preg_replace ( '/ стар / iu', 'д', $ s); # Вынік слова дока

мадыфікатар i загадвае регистронезависимый пошук, а мадыфікатар u кажа рухавічку рэгулярных выразаў працаваць з utf-8 радкамі.

калі нехта скажа, што php не можа працаваць з utf-8, ён будзе не мае рацыю. ужо некалькі гадоў раблю ўсё свае праекты ў гэтай кадыроўцы і праблем не было зусім. пошукавыя сістэмы самі даўно выкарыстоўваюць гэтую выдатную кадыроўку.

аўтар публікацыі

не ў сеткі 11-й гадзіне

x64 (aka andi)

Каментары: 2846 Публікацыі: 395 Рэгістрацыя: 2009/04/02

Дык вось, з-за чаго ж такая бяда здараецца і як яе перамагчы?