KOI-8 (шифра за размена на информации, 8 бита), KOI8- осум-битен стандард за кодирање знаци во компјутерската наука. Дизајниран за кодирање на буквите од кирилицата. Постои и седум-битна верзија на кодирањето - KOI-7. KOI-7 и KOI-8 се опишани во ГОСТ 19768-74 (сега неважечки).
Програмерите на KOI-8 ги поставија знаците од руската азбука на врвот на проширената табела ASCII на таков начин што позициите на кириличните знаци одговараат на нивните фонетски колеги во англиската азбука на дното на табелата. Тоа значи дека ако во текст напишан со KOI-8 се отстрани осмиот бит од секој знак, тогаш се добива „читлив“ текст, иако е напишан со латински букви. На пример, зборовите „Руски текст“ би станале „rUSSKIJ tEKST“. Како споредна последица, кириличните знаци не биле подредени по азбучен ред.
Кодирање KOI8-R
| .0 | .1 | .2 | .3 | .4 | .5 | .6 | .7 | .8 | .9 | .А | .Б | .Ц | .Д | .Е | .Ф | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 8. |
─
2500 |
│
2502 |
┌
250C |
┐
2510 |
└
2514 |
┘
2518 |
├
251C |
┤
2524 |
┬
252C |
┴
2534 |
┼
253C |
▀
2580 |
▄
2584 |
█
2588 |
▌
258C |
▐
2590 |
| 9. |
░
2591 |
▒
2592 |
▓
2593 |
⌠
2320 |
■
25А0 |
∙
2219 |
√
221А |
≈
2248 |
≤
2264 |
≥
2265 |
А0 |
⌡
2321 |
°
Б0 |
²
Б2 |
·
Б7 |
÷
F7 |
| А. |
═
2550 |
║
2551 |
╒
2552 |
д 451 |
╓
2553 |
╔
2554 |
╕
2555 |
╖
2556 |
╗
2557 |
╘
2558 |
╙
2559 |
╚
255А |
╛
255Б |
╜
255C |
╝
255D |
╞
255E |
| Б. |
╟
255 F |
╠
2560 |
╡
2561 |
Јо 401 |
╢
2562 |
╣
2563 |
╤
2564 |
╥
2565 |
╦
2566 |
╧
2567 |
╨
2568 |
╩
2569 |
╪
256А |
╫
256Б |
╬
256C |
©
А9 |
| В. |
Ју 44E |
А 430 |
б 431 |
ts 446 |
г 434 |
д 435 |
ѓ 444 |
Г 433 |
X 445 |
И 438 |
ти 439 |
До 43А |
л 43Б |
м 43C |
n 43D |
О 43E |
| Д. |
П 43F |
Јас 44F |
Р 440 |
Со 441 |
Т 442 |
на 443 |
и 436 |
В 432 |
б 44C |
с 44Б |
ч 437 |
w 448 |
ух 44D |
sch 449 |
ч 447 |
ъ 44А |
| Е. |
ЈУ 42E |
А 410 |
Б 411 |
В 426 |
Д 414 |
Е 415 |
Ф 424 |
Г 413 |
X 425 |
И 418 |
Y 419 |
ДО 41А |
Л 41Б |
М 41C |
Н 41D |
ЗА 41E |
| Ф. |
П 41F |
Јас 42F |
Р 420 |
СО 421 |
Т 422 |
У 423 |
И 416 |
ВО 412 |
б 42C |
Y 42Б |
З 417 |
Ш 428 |
Е 42D |
SCH 429 |
Х 427 |
Комерсант 42А |
Кодирање KOI8-U (украински)
| .0 | .1 | .2 | .3 | .4 | .5 | .6 | .7 | .8 | .9 | .А | .Б | .Ц | .Д | .Е | .Ф | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| А. |
═
2550 |
║
2551 |
╒
2552 |
д 451 |
є
454 |
╔
2554 |
і
456 |
ї
457 |
╗
2557 |
╘
2558 |
╙
2559 |
╚
255А |
╛
255Б |
ґ
491 |
╝
255D |
╞
255E |
| Б. |
╟
255 F |
╠
2560 |
╡
2561 |
Јо 401 |
Є
404 |
╣
2563 |
І
406 |
Ї
407 |
╦
2566 |
╧
2567 |
╨
2568 |
╩
2569 |
╪
256А |
Ґ
490 |
╬
256C |
©
А9 |
— Замполит (@ComradZampolit) 17 август 2017 година
Како работи KOI8-R?
KOI8-R е осумбитна шифра наменета за кодирање на буквите од кирилицата. Програмерите ги поставија ликовите од руската азбука на таков начин што позициите на кириличните знаци одговараат на нивните фонетски колеги во англиската азбука на дното на табелата. И ако во текстот напишан во ова кодирање се отстрани осмиот бит од секој знак, тогаш резултатот е текст сличен на транслитерација со латински букви.
Овој код за размена на информации се користеше во седумдесеттите години на компјутерите од компјутерската серија ES, а од средината на осумдесеттите почна да се користи во првите русифицирани верзии на оперативниот систем UNIX.
Кодирањето се состоеше во тоа што на секој знак му беше доделен уникатен код: од 00000000 до 11111111. Така, едно лице ги разликува ликовите по нивниот преглед, а компјутерот - според нивниот код.
Дали во моментов се користи кодирањето на Chernoff?
бр. Тоа беше релевантно за старите осум-битни компјутери; сега главно се користи Unicode во различни формати.
Денес ќе разговараме со вас за тоа од каде доаѓаат krakozyabrs на веб-локација и во програми, какви текстуални шифри постојат и кои треба да се користат. Ајде внимателно да ја разгледаме историјата на нивниот развој, почнувајќи од основниот ASCII, како и неговите продолжени верзии CP866, KOI8-R, Windows 1251 и завршувајќи со модерни шифрирања на конзорциумот Уникод UTF 16 и 8. Содржина: За некои, оваа информација може да изгледа непотребна, но дали знаете колку прашања добивам конкретно во врска со ползечките krakozyabrs (нечитливи збир на знаци). Сега ќе имам можност да ги упатам сите на текстот на оваа статија и да ги најдам сопствените грешки. Па, подгответе се да ги апсорбирате информациите и обидете се да го следите текот на приказната.
ASCII - основно кодирање на текст за латинската азбука
Развојот на шифрирањето на текстот се случи истовремено со формирањето на ИТ индустријата и за тоа време тие успеаја да претрпат доста промени. Историски, сè започна со EBCDIC, кој беше прилично дисонантен во рускиот изговор, што овозможи да се кодираат буквите од латинската азбука, арапските бројки и интерпункциски знаци со контролни знаци. Но, сепак, почетната точка за развој на модерни текстуални шифри треба да се смета за познатата ASCII(Американски стандарден код за размена на информации, кој на руски обично се изговара како „аски“). Ги опишува првите 128 знаци кои најчесто ги користат корисниците што зборуваат англиски - латински букви, арапски бројки и интерпункциски знаци. Овие 128 знаци опишани во ASCII, исто така, вклучуваа некои услужни знаци како загради, хаш ознаки, ѕвездички итн. Всушност, можете сами да ги видите:
Токму овие 128 знаци од оригиналната верзија на ASCII станаа стандард, а во секое друго кодирање дефинитивно ќе ги најдете и тие ќе се појават по овој редослед. Но, факт е дека со еден бајт информации можете да шифрирате не 128, туку дури 256 различни вредности (две на моќ од осум е еднакво на 256), па по основната верзија на Asuka цела серија на продолжени ASCII шифри, во која, покрај 128 основни знаци, беше можно да се кодираат и симболи на националното кодирање (на пример, руски). Овде, веројатно вреди да се каже малку повеќе за системите за броеви што се користат во описот. Прво, како што сите знаете, компјутерот работи само со броеви во бинарниот систем, имено со нули и единици („Булова алгебра“, ако некој го земал во институт или училиште). Еден бајт се состои од осум бита, од кои секој е моќност од два, почнувајќи од нула и завршувајќи со два до седмата моќност: 
Не е тешко да се разбере дека сите можни комбинации на нули и единици во таков дизајн можат да бидат само 256. Конвертирањето на број од бинарниот систем во децимален систем е прилично едноставно. Треба само да ги соберете сите моќи на два со оние над нив. Во нашиот пример, ова излегува дека е 1 (2 на моќта на нула) плус 8 (два на моќта од 3), плус 32 (два до петтата моќност), плус 64 (до шестата моќност), плус 128 (до седмата сила). Вкупниот број е 233 во децимална нотација. Како што можете да видите, сè е многу едноставно. Но, ако внимателно ја погледнете табелата со ASCII знаци, ќе видите дека тие се претставени во хексадецимално кодирање. На пример, „ѕвездичка“ одговара на хексадецималниот број 2А во Аски. Веројатно знаете дека во хексадецималниот броен систем, покрај арапските бројки, се користат и латински букви од A (значи десет) до F (значи петнаесет). Па тогаш, за претворање на бинарен број во хексадецималенприбегнете кон следниот едноставен и очигледен метод. Секој бајт на информации е поделен на два дела од четири бита, како што е прикажано на горната слика од екранот. Тоа. Во секој половина бајт, само шеснаесет вредности (од две до четвртата моќност) можат да се кодираат бинарно, што лесно може да се претстави како хексадецимален број. Покрај тоа, во левата половина од бајтот, степените ќе треба повторно да се бројат почнувајќи од нула, а не како што е прикажано на екранот. Како резултат на тоа, преку едноставни пресметки, добиваме дека бројот Е9 е кодиран на сликата од екранот. Се надевам дека текот на моето размислување и решението на оваа загатка ви беа јасни. Па, сега да продолжиме, всушност, да зборуваме за кодирање на текст. Проширени верзии на Asuka - CP866 и KOI8-R кодирање со псевдографски слики
Така, почнавме да зборуваме за ASCII, што беше, како што беше, почетна точка за развој на сите модерни шифрирања (Windows 1251, Unicode, UTF 8). Првично, содржеше само 128 знаци од латинската азбука, арапски бројки и нешто друго, но во проширената верзија стана можно да се користат сите 256 вредности што можат да се кодираат во еден бајт информации. Оние. Стана возможно да додадете симболи на буквите од вашиот јазик на Аски. Тука ќе треба повторно да отстапиме за да објасниме - Зошто воопшто ни се потребни текстуални кодови?и зошто е толку важно. Карактерите на екранот на вашиот компјутер се формираат врз основа на две работи - збирки векторски форми (репрезентации) од сите видови знаци (тие се во датотеки со фонтови што се инсталирани на вашиот компјутер) и код што ви овозможува точно да го извадите тој од овој сет на векторски форми (датотека со фонтови).симбол кој ќе треба да се вметне на вистинското место. Јасно е дека самите фонтови се одговорни за векторските форми, но оперативниот систем и програмите што се користат во него се одговорни за кодирањето. Оние. кој било текст на вашиот компјутер ќе биде збир од бајти, од кои секој шифрира еден единствен знак од овој текст. Програмата што го прикажува овој текст на екранот (уредувач на текст, прелистувач итн.), при парсирање на кодот, го чита кодирањето на следниот знак и ја бара соодветната векторска форма во потребната датотека со фонтови, која е поврзана за да го прикаже ова текстуален документ. Сè е едноставно и банално. Ова значи дека за да се шифрира кој било знак што ни треба (на пример, од националната азбука), мора да се исполнат два услови - векторската форма на овој знак мора да биде во користениот фонт и овој знак може да биде кодиран во проширени ASCII шифрирања во еден бајт. Затоа, има цел куп такви опции. Само за кодирање на знаци на руски јазик, постојат неколку варијанти на продолжена Аска. На пример, првично се појави CP866, кој имаше можност да користи знаци од руската азбука и беше проширена верзија на ASCII. Оние. нејзиниот горен дел целосно се совпадна со основната верзија на Аска (128 латински знаци, бројки и други глупости), која е претставена на скриншот веднаш погоре, но долниот дел од табелата со кодирање CP866 го имаше изгледот наведен на скриншот веднаш подолу и ви овозможи да шифрирате уште 128 знаци (руски букви и секакви псевдографии):
Гледате, во десната колона бројките почнуваат со 8, бидејќи ... броевите од 0 до 7 се однесуваат на основниот дел од ASCII (видете ја првата слика од екранот). Тоа. руската буква „М“ во CP866 ќе ја има шифрата 9C (се наоѓа на пресекот на соодветниот ред со 9 и колона со бројот C во хексадецималниот броен систем), што може да се напише во еден бајт информации, и ако има соодветен фонт со руски знаци, оваа буква без проблеми ќе се појави во текстот. Од каде оваа сума? псевдографика во CP866? Целата поента е дека ова кодирање за руски текст беше развиено уште во тие бушави години кога графичките оперативни системи не беа толку распространети како што се сега. И во Dosa и слични оперативни системи за текст, псевдографиката овозможи барем некако да се диверзифицира дизајнот на текстовите, и затоа CP866 и сите негови други врсници од категоријата проширени верзии на Asuka изобилуваат во него. CP866 беше дистрибуиран од IBM, но покрај ова, беа развиени голем број шифри за знаци на руски јазик, на пример, може да се припише истиот тип (проширен ASCII). КОИ8-Р:
Принципот на неговото функционирање останува ист како оној на CP866 опишан малку порано - секој знак од текстот е кодиран со еден единствен бајт. Сликата од екранот ја прикажува втората половина од табелата KOI8-R, бидејќи првата половина е целосно конзистентна со основната Асука, која е прикажана на првата слика од екранот во оваа статија. Меѓу карактеристиките на кодирањето KOI8-R, може да се забележи дека руските букви во неговата табела не се по азбучен ред, како што, на пример, го направија тоа во CP866. Ако ја погледнете првата слика од екранот (на основниот дел, кој е вклучен во сите проширени шифрирања), ќе забележите дека во KOI8-R руските букви се наоѓаат во истите ќелии од табелата како и соодветните букви од латинската азбука. од првиот дел од табелата. Ова беше направено за погодност за префрлување од руски на латински знаци со отфрлање на само еден бит (два до седмата сила или 128). Windows 1251 - модерна верзија на ASCII и зошто пукнатините излегуваат
Понатамошниот развој на шифрирањето на текстот се должеше на фактот дека графичките оперативни системи се здобиваа со популарност и потребата да се користи псевдографска во нив исчезна со текот на времето. Како резултат на тоа, се појави цела група која, во суштина, сè уште беа проширени верзии на Асука (еден знак од текстот е кодиран со само еден бајт информации), но без употреба на псевдографски симболи. Тие припаѓаа на таканаречените ANSI кодирање, кои беа развиени од Американскиот институт за стандарди. Во вообичаениот јазик, името кирилица се користеше и за верзијата со поддршка на руски јазик. Пример за ова може да биде Windows 1251. Поволно се разликуваше од претходно користените CP866 и KOI8-R со тоа што местото на псевдографските симболи во него го зазедоа исчезнатите симболи на руската типографија (освен ознаката за акцент), како и симболите што се користат на словенските јазици блиску до Руски (украински, белоруски, итн.) :
Поради толкавото изобилство на кодирање на руски јазик, производителите на фонтови и производителите на софтвер постојано имаа главоболки, а вие и јас, драги читатели, честопати ги добивавме истите озлогласени krakozyabryкога настана забуна со верзијата што се користи во текстот. Многу често тие излегуваа при испраќање и примање пораки по е-пошта, што подразбираше создавање на многу сложени табели за конверзија, кои, всушност, не можеа суштински да го решат овој проблем, а често корисниците користеа транслитерација на латински букви за кореспонденција со цел да избегнувајте ги озлогласените глупости кога користите руски шифрирања како CP866, KOI8-R или Windows 1251. Всушност, пукнатините што се појавуваат наместо руски текст беа резултат на неправилна употреба на кодирањето на даден јазик, што не соодветствува со она во кој текстуалната порака беше првично кодирана. Да речеме дека ако се обидете да прикажете знаци кодирани со CP866 користејќи ја табелата со шифри на Windows 1251, тогаш истите тие глупости (бесмислено збир на знаци) ќе излезат, целосно заменувајќи го текстот на пораката. 
Слична ситуација многу често се јавува при креирање и поставување веб-локации, форуми или блогови, кога текстот со руски знаци е погрешно зачуван во погрешно кодирање што стандардно се користи на страницата или во погрешен уредувач на текст, што додава невидливо замолчување до кодот со голо око. На крајот, на многу луѓе им здосади оваа ситуација со многу шифрирања и постојано лази, а се појавија предусловите за создавање на нова универзална варијација која ќе ги замени сите постоечки и конечно ќе го реши проблемот со изгледот. на нечитливи текстови. Покрај тоа, имаше проблем со јазиците како кинескиот, каде што имаше многу повеќе јазични знаци од 256. Уникод - универзални шифри UTF 8, 16 и 32
Овие илјадници знаци од јазичната група на југоисточна Азија не би можеле да се опишат во еден бајт од информации што биле распределени за кодирање знаци во проширените верзии на ASCII. Како резултат на тоа, беше создаден конзорциум наречен Уникод(Unicode - Unicode Consortium) со соработка на многу лидери во ИТ индустријата (оние кои произведуваат софтвер, кои кодираат хардвер, кои создаваат фонтови), кои биле заинтересирани за појава на универзално кодирање на текст. Првата варијација објавена под покровителство на Уникод Конзорциумот беше UTF 32. Бројот во името на кодирањето значи број на битови што се користат за кодирање на еден знак. 32 бита се еднакви на 4 бајти информации кои ќе бидат потребни за кодирање на еден знак во новото универзално UTF кодирање. Како резултат на тоа, истата датотека со текст кодиран во проширената верзија на ASCII и во UTF-32, во вториот случај, ќе има големина (тежина) четири пати поголема. Ова е лошо, но сега имаме можност да шифрираме со помош на YTF голем број знаци еднакви на два до триесет и втората моќност ( милијарди карактери, што ќе ја покрие секоја навистина потребна вредност со колосална маржа). Но, многу земји со јазици од европската група воопшто не требаа да користат толку огромен број знаци во кодирањето, меѓутоа, при користење на UTF-32, тие без причина добија четирикратно зголемување на тежината на текстуалните документи, и како резултат на тоа, зголемување на обемот на интернет сообраќај и обемот на складирани податоци. Ова е многу, и никој не може да си дозволи таков отпад. Како резултат на развојот на Уникод, UTF-16, што се покажа толку успешно што стандардно беше усвоено како основен простор за сите знаци што ги користиме. Користи два бајта за кодирање на еден знак. Ајде да видиме како изгледа оваа работа. Во оперативниот систем Виндоус, можете да ја следите патеката „Почеток“ - „Програми“ - „Додатоци“ - „Системски алатки“ - „Табела со знаци“. Како резултат на тоа, ќе се отвори табела со векторските форми на сите фонтови инсталирани на вашиот систем. Ако го изберете множеството знаци на Уникод во „Напредни опции“, ќе можете да го видите за секој фонт одделно целиот опсег на знаци вклучени во него. Патем, со кликнување на кој било од нив, можете да го видите неговиот двобајт код во формат UTF-16, кој се состои од четири хексадецимални цифри:
Колку знаци може да се кодираат во UTF-16 користејќи 16 бита? 65.536 (два со моќ од шеснаесет), и ова е бројот што беше усвоен како основен простор во Unicode. Покрај тоа, постојат начини да се кодираат околу два милиони знаци користејќи го, но тие беа ограничени на проширен простор од милион карактери текст. Но, дури и оваа успешна верзија на кодирањето на Уникод не им донесе големо задоволство на оние кои пишуваа, да речеме, програми само на англиски јазик, бидејќи за нив, по преминот од проширената верзија на ASCII на UTF-16, тежината на документите се удвои ( еден бајт по знак во Aski и два бајти за истиот знак во YUTF-16). Токму за задоволство на сите и на се во конзорциумот Уникод беше одлучено излезе со кодирањепроменлива должина. Се викаше UTF-8. И покрај осумте во името, тој всушност има променлива должина, т.е. Секој знак од текстот може да биде кодиран во низа од еден до шест бајти во должина. Во пракса, UTF-8 користи само опсег од еден до четири бајти, бидејќи повеќе од четири бајти код повеќе не е ни теоретски можно да се замисли нешто. Сите латински знаци во него се кодирани во еден бајт, исто како во стариот добар ASCII. Она што е забележливо е дека во случај на кодирање само на латиницата, дури и оние програми што не разбираат Unicode, сепак ќе го читаат она што е шифрирано во YTF-8. Оние. основниот дел на Асука едноставно беше префрлен на оваа креација на конзорциумот Уникод. Кирилични знаци во UTF-8 се кодирани во два бајти, а, на пример, грузиски - во три бајти. Конзорциумот Уникод, откако ги создаде UTF 16 и 8, го реши главниот проблем - сега имаме фонтовите имаат единствен простор за код. И сега нивните производители можат да го пополнат само со векторски форми на текстуални знаци врз основа на нивните силни страни и способности. Во „Табела со знаци“ погоре можете да видите дека различни фонтови поддржуваат различен број на знаци. Некои фонтови богати со Уникод може да бидат доста тешки. Но, сега тие не се разликуваат по тоа што се создадени за различни шифрирања, туку по тоа што производителот на фонтови го пополнил или не целосно го пополнил просторот за единствен код со одредени векторски форми. Луди зборови наместо руски букви - како да се поправи
Ајде сега да видиме како се појавуваат krakozyabrs наместо текст или, со други зборови, како е избрано правилното кодирање за руски текст. Всушност, тој е поставен во програмата во која го креирате или уредувате овој текст или код користејќи фрагменти од текст. За уредување и креирање текстуални датотеки, јас лично користам многу добар, според мое мислење, уредник на Html и PHP Notepad++. Сепак, може да ја нагласи синтаксата на стотици други јазици за програмирање и обележување, а исто така има можност да се прошири со помош на приклучоци. Прочитајте детален преглед на оваа прекрасна програма на дадената врска. Во горното мени на Notepad++ има ставка „Кодирање“, каде што ќе имате можност да конвертирате постоечка опција во онаа што се користи стандардно на вашата страница:
Во случај на локација на Joomla 1.5 и понова верзија, како и во случај на блог на WordPress, треба да ја изберете опцијата за да избегнете појава на пукнатини UTF 8 без BOM. Што е префиксот BOM? Факт е дека кога го развиваа кодирањето YUTF-16, поради некоја причина решија да му прикачат такво нешто како што е можноста за пишување на кодот на знаци и во директна низа (на пример, 0A15) и обратно (150A) . И за програмите да разберат точно во која секвенца да ги читаат шифрите, тоа беше измислено БОМ(Byte Order Mark или, со други зборови, потпис), што беше изразено со додавање на три дополнителни бајти на самиот почеток на документите. Во кодирањето UTF-8, не беа предвидени BOM-ови во конзорциумот Уникод, и затоа додавањето потпис (оние озлогласени дополнителни три бајти на почетокот на документот) едноставно спречува некои програми да го читаат кодот. Затоа, при зачувување на датотеки во UTF, секогаш мора да ја избереме опцијата без BOM (без потпис). Значи, вие сте однапред заштити се од лазење krakozyabrs. Она што е забележливо е дека некои програми во Windows не можат да го направат тоа (не можат да зачуваат текст во UTF-8 без BOM), на пример, истиот озлогласен Windows Notepad. Го зачувува документот во UTF-8, но сепак го додава потписот (три дополнителни бајти) на почетокот на истиот. Покрај тоа, овие бајти секогаш ќе бидат исти - прочитајте го кодот во директна низа. Но, на серверите, поради оваа ситница, може да се појави проблем - ќе излезат измамници. Затоа, под никакви околности Не користете обичен Windows Notepadда уредувате документи на вашата страница ако не сакате да се појавуваат пукнатини. Сметам дека веќе споменатиот уредник Notepad++ е најдобра и наједноставна опција, која практично нема никакви недостатоци и се состои само од предности. Во Notepad++, кога ќе изберете кодирање, ќе имате опција да го конвертирате текстот во кодирање UCS-2, што по својата природа е многу блиску до стандардот Unicode. Исто така во Notepad ќе може да се кодира текст во ANSI, т.е. во однос на рускиот јазик, ова ќе биде Windows 1251, кој веќе го опишавме веднаш погоре.Од каде потекнуваат овие информации? Регистриран е во регистарот на вашиот оперативен систем Виндоус - кое кодирање да се избере во случај на ANSI, кое да се избере во случај на OEM (за рускиот јазик ќе биде CP866). Ако поставите друг стандарден јазик на вашиот компјутер, тогаш овие шифрирања ќе бидат заменети со слични од категоријата ANSI или OEM за истиот јазик. Откако ќе го зачувате документот во Notepad++ во кодирањето што ви треба или ќе го отворите документот од страницата за уредување, можете да го видите неговото име во долниот десен агол на уредувачот: За да избегнете црвенилоПокрај дејствата опишани погоре, ќе биде корисно да се напишат информации за ова кодирање во заглавието на изворниот код на сите страници на страницата, така што нема забуна на серверот или локалниот домаќин. Општо земено, сите јазици за означување на хипертекст освен Html користат специјална декларација xml, која го одредува кодирањето на текстот.<
?
xml version=
"1.0"
encoding=
"windows-1251"
?
>Пред да го анализира кодот, прелистувачот знае која верзија се користи и како точно треба да ги толкува шифрите на знаците на тој јазик. Но, она што треба да се забележи е дека ако го зачувате документот во стандардниот Unicode, тогаш оваа xml декларација може да се испушти (кодирањето ќе се смета за UTF-8 ако нема BOM или UTF-16 ако има BOM). Во случај на документ со јазик на Html, кодирањето се користи за означување Мета елемент, што е напишано помеѓу ознаките за глава за отворање и затворање: <
head>
.
.
.
<
meta charset=
"utf-8"
>
.
.
.
<
/
head>Овој запис е сосема различен од оној усвоен во стандардот во Html 4.01, но целосно е во согласност со новиот Html 5 стандард кој постепено се воведува и ќе биде целосно разбран правилно од сите прелистувачи што се користат во моментов. Теоретски, би било подобро да се постави мета-елемент кој го означува кодирањето на Html документот што е можно повисоко во заглавието на документоттака што во моментот на средба со првиот знак во текстот не од основниот ANSI (кои секогаш се читаат правилно и во која било варијација), прелистувачот веќе треба да има информации за тоа како да ги толкува шифрите на овие знаци. Врска до прво
Здраво, драги читатели на блог-страницата. Денес ќе разговараме со вас за тоа од каде доаѓаат krakozyabrs на веб-локација и во програми, какви текстуални шифри постојат и кои треба да се користат. Ајде внимателно да ја разгледаме историјата на нивниот развој, почнувајќи од основните ASCII, како и неговите продолжени верзии CP866, KOI8-R, Windows 1251 и завршувајќи со модерните шифрирања на Уникод конзорциум UTF 16 и 8.
За некои, оваа информација може да изгледа непотребна, но дали знаете колку прашања добивам конкретно во врска со ползечките krakozyabrs (нечитливи збир на знаци). Сега ќе имам можност да ги упатам сите на текстот на оваа статија и да ги најдам сопствените грешки. Па, подгответе се да ги апсорбирате информациите и обидете се да го следите текот на приказната.
ASCII - основно кодирање на текст за латинската азбука
Развојот на шифрирањето на текстот се случи истовремено со формирањето на ИТ индустријата и за тоа време тие успеаја да претрпат доста промени. Историски, сè започна со EBCDIC, кој беше прилично дисонантен во рускиот изговор, што овозможи да се кодираат буквите од латинската азбука, арапските бројки и интерпункциски знаци со контролни знаци.
Но, сепак, почетната точка за развој на модерни текстуални шифри треба да се смета за познатата ASCII(Американски стандарден код за размена на информации, кој на руски обично се изговара како „аски“). Ги опишува првите 128 знаци кои најчесто се користат од корисниците што зборуваат англиски - , арапски бројки и интерпункциски знаци.
Овие 128 знаци опишани во ASCII, исто така, вклучуваа некои услужни знаци како загради, хаш ознаки, ѕвездички итн. Всушност, можете сами да ги видите:
Токму овие 128 знаци од оригиналната верзија на ASCII станаа стандард, а во секое друго кодирање дефинитивно ќе ги најдете и тие ќе се појават по овој редослед.
Но, факт е дека со еден бајт информации можете да шифрирате не 128, туку дури 256 различни вредности (две на моќ од осум е еднакво на 256), па по основната верзија на Asuka цела серија на продолжени ASCII шифри, во која, покрај 128 основни знаци, беше можно да се кодираат и симболи на националното кодирање (на пример, руски).
Овде, веројатно вреди да се каже малку повеќе за системите за броеви што се користат во описот. Прво, како што сите знаете, компјутерот работи само со броеви во бинарниот систем, имено со нули и единици („Булова алгебра“, ако некој го земал во институт или училиште). , од кои секоја е два на моќта, почнувајќи од нула и до два до седмата:
Не е тешко да се разбере дека сите можни комбинации на нули и единици во таков дизајн можат да бидат само 256. Конвертирањето на број од бинарниот систем во децимален систем е прилично едноставно. Треба само да ги соберете сите моќи на два со оние над нив.
Во нашиот пример, ова излегува дека е 1 (2 на моќта на нула) плус 8 (два на моќта од 3), плус 32 (два до петтата моќност), плус 64 (до шестата моќност), плус 128 (до седмата сила). Вкупниот број е 233 во децимална нотација. Како што можете да видите, сè е многу едноставно.
Но, ако внимателно ја погледнете табелата со ASCII знаци, ќе видите дека тие се претставени во хексадецимално кодирање. На пример, „ѕвездичка“ одговара на хексадецималниот број 2А во Аски. Веројатно знаете дека во хексадецималниот броен систем, покрај арапските бројки, се користат и латински букви од A (значи десет) до F (значи петнаесет).
Па тогаш, за претворање на бинарен број во хексадецималенприбегнете кон следниот едноставен и очигледен метод. Секој бајт на информации е поделен на два дела од четири бита, како што е прикажано на горната слика од екранот. Тоа. Во секој половина бајт, само шеснаесет вредности (од две до четвртата моќност) можат да се кодираат бинарно, што лесно може да се претстави како хексадецимален број.
Покрај тоа, во левата половина од бајтот, степените ќе треба повторно да се бројат почнувајќи од нула, а не како што е прикажано на екранот. Како резултат на тоа, преку едноставни пресметки, добиваме дека бројот Е9 е кодиран на сликата од екранот. Се надевам дека текот на моето размислување и решението на оваа загатка ви беа јасни. Па, сега да продолжиме, всушност, да зборуваме за кодирање на текст.
Проширени верзии на Asuka - CP866 и KOI8-R кодирање со псевдографски слики
Така, почнавме да зборуваме за ASCII, што беше, како што беше, почетна точка за развој на сите модерни шифрирања (Windows 1251, Unicode, UTF 8).
Првично, содржеше само 128 знаци од латинската азбука, арапски бројки и нешто друго, но во проширената верзија стана можно да се користат сите 256 вредности што можат да се кодираат во еден бајт информации. Оние. Стана возможно да додадете симболи на буквите од вашиот јазик на Аски.
Тука ќе треба повторно да отстапиме за да објасниме - зошто воопшто ни требаат шифрирање?текстови и зошто е толку важно. Знаците на екранот на вашиот компјутер се формираат врз основа на две работи - збирки векторски форми (репрезентации) од различни знаци (тие се наоѓаат во датотеки со ) и код што ви овозможува да извадите од овој сет векторски форми (датотека со фонтови ) токму знакот што ќе треба да се вметне на вистинското место.
Јасно е дека самите фонтови се одговорни за векторските форми, но оперативниот систем и програмите што се користат во него се одговорни за кодирањето. Оние. кој било текст на вашиот компјутер ќе биде збир од бајти, од кои секој шифрира еден единствен знак од овој текст.
Програмата што го прикажува овој текст на екранот (уредувач на текст, прелистувач итн.), при парсирање на кодот, го чита кодирањето на следниот знак и ја бара соодветната векторска форма во потребната датотека со фонтови, која е поврзана за да го прикаже ова текстуален документ. Сè е едноставно и банално.
Ова значи дека за да се шифрира кој било знак што ни треба (на пример, од националната азбука), мора да се исполнат два услови - векторската форма на овој знак мора да биде во користениот фонт и овој знак може да биде кодиран во проширени ASCII шифрирања во еден бајт. Затоа, има цел куп такви опции. Само за кодирање на знаци на руски јазик, постојат неколку варијанти на продолжена Аска.
На пример, првично се појави CP866, кој имаше можност да користи знаци од руската азбука и беше проширена верзија на ASCII.
Оние. нејзиниот горен дел целосно се совпадна со основната верзија на Аска (128 латински знаци, бројки и други глупости), која е претставена на скриншот веднаш погоре, но долниот дел од табелата со кодирање CP866 го имаше изгледот наведен на скриншот веднаш подолу и ви овозможи да шифрирате уште 128 знаци (руски букви и секакви псевдографии):
Гледате, во десната колона бројките почнуваат со 8, бидејќи ... броевите од 0 до 7 се однесуваат на основниот дел од ASCII (видете ја првата слика од екранот). Тоа. руската буква „М“ во CP866 ќе ја има шифрата 9C (се наоѓа на пресекот на соодветниот ред со 9 и колона со бројот C во хексадецималниот броен систем), што може да се напише во еден бајт информации, и ако има соодветен фонт со руски знаци, оваа буква без проблеми ќе се појави во текстот.
Од каде оваа сума? псевдографика во CP866? Целата поента е дека ова кодирање за руски текст беше развиено уште во тие бушави години кога графичките оперативни системи не беа толку распространети како што се сега. И во Dosa и слични оперативни системи за текст, псевдографиката овозможи барем некако да се диверзифицира дизајнот на текстовите, и затоа CP866 и сите негови други врсници од категоријата проширени верзии на Asuka изобилуваат во него.
CP866 беше дистрибуиран од IBM, но покрај ова, беа развиени голем број шифри за знаци на руски јазик, на пример, може да се припише истиот тип (проширен ASCII). КОИ8-Р:
Принципот на неговото функционирање останува ист како оној на CP866 опишан малку порано - секој знак од текстот е кодиран со еден единствен бајт. Сликата од екранот ја прикажува втората половина од табелата KOI8-R, бидејќи првата половина е целосно конзистентна со основната Асука, која е прикажана на првата слика од екранот во оваа статија.
Меѓу карактеристиките на кодирањето KOI8-R, може да се забележи дека руските букви во неговата табела не се по азбучен ред, како што, на пример, го направија тоа во CP866.
Ако ја погледнете првата слика од екранот (на основниот дел, кој е вклучен во сите проширени шифрирања), ќе забележите дека во KOI8-R руските букви се наоѓаат во истите ќелии од табелата како и соодветните букви од латинската азбука. од првиот дел од табелата. Ова беше направено за погодност за префрлување од руски на латински знаци со отфрлање на само еден бит (два до седмата сила или 128).
Windows 1251 - модерната верзија на ASCII и зошто пукнатините излегуваат
Понатамошниот развој на шифрирањето на текстот се должеше на фактот дека графичките оперативни системи се здобиваа со популарност и потребата да се користи псевдографска во нив исчезна со текот на времето. Како резултат на тоа, се појави цела група која, во суштина, сè уште беа проширени верзии на Асука (еден знак од текстот е кодиран со само еден бајт информации), но без употреба на псевдографски симболи.
Тие припаѓаа на таканаречените ANSI кодирање, кои беа развиени од Американскиот институт за стандарди. Во вообичаениот јазик, името кирилица се користеше и за верзијата со поддршка на руски јазик. Пример за ова би бил.
Поволно се разликуваше од претходно користените CP866 и KOI8-R со тоа што местото на псевдографските симболи во него го зазедоа исчезнатите симболи на руската типографија (освен ознаката за акцент), како и симболите што се користат на словенските јазици блиску до Руски (украински, белоруски, итн.) :
Поради толкавото изобилство на кодирање на руски јазик, производителите на фонтови и производителите на софтвер постојано имаа главоболки, а вие и јас, драги читатели, честопати ги добивавме истите озлогласени krakozyabryкога настана забуна со верзијата што се користи во текстот.
Многу често тие излегуваа при испраќање и примање пораки по е-пошта, што подразбираше создавање на многу сложени табели за конверзија, кои, всушност, не можеа фундаментално да го решат овој проблем, а корисниците често ги користеа за кореспонденција за да ги избегнат озлогласените трикови при користење Руски шифрирања како CP866, KOI8-R или Windows 1251.
Всушност, пукнатините што се појавуваат наместо рускиот текст се резултат на неправилна употреба на кодирањето на овој јазик, што не соодветствува со онаа на која првично беше кодирана текстуалната порака.
Да речеме дека ако се обидете да прикажете знаци кодирани со CP866 користејќи ја табелата со шифри на Windows 1251, тогаш истите тие глупости (бесмислено збир на знаци) ќе излезат, целосно заменувајќи го текстот на пораката.
Слична ситуација многу често се појавува на форуми или блогови, кога текстот со руски знаци е погрешно зачуван во погрешно кодирање што се користи на страницата стандардно или во погрешен уредувач на текст, кој додава gags на кодот што не се видливи за голо око.
На крајот, на многу луѓе им здосади оваа ситуација со многу шифрирања и постојано лази, а се појавија предусловите за создавање на нова универзална варијација која ќе ги замени сите постоечки и конечно ќе го реши проблемот со изгледот. на нечитливи текстови. Покрај тоа, имаше проблем со јазиците како кинескиот, каде што имаше многу повеќе јазични знаци од 256.
Уникод - универзални шифри UTF 8, 16 и 32
Овие илјадници знаци од јазичната група на југоисточна Азија не би можеле да се опишат во еден бајт од информации што биле распределени за кодирање знаци во проширените верзии на ASCII. Како резултат на тоа, беше создаден конзорциум наречен Уникод(Unicode - Unicode Consortium) со соработка на многу лидери во ИТ индустријата (оние кои произведуваат софтвер, кои кодираат хардвер, кои создаваат фонтови), кои биле заинтересирани за појава на универзално кодирање на текст.
Првата варијација објавена под покровителство на Уникод Конзорциумот беше UTF 32. Бројот во името на кодирањето значи број на битови што се користат за кодирање на еден знак. 32 бита се еднакви на 4 бајти информации кои ќе бидат потребни за кодирање на еден знак во новото универзално UTF кодирање.
Како резултат на тоа, истата датотека со текст кодиран во проширената верзија на ASCII и во UTF-32, во вториот случај, ќе има големина (тежина) четири пати поголема. Ова е лошо, но сега имаме можност да шифрираме со помош на YTF голем број знаци еднакви на два до триесет и втората моќност ( милијарди карактери, што ќе ја покрие секоја навистина потребна вредност со колосална маржа).
Но, многу земји со јазици од европската група воопшто не требаа да користат толку огромен број знаци во кодирањето, меѓутоа, при користење на UTF-32, тие без причина добија четирикратно зголемување на тежината на текстуалните документи, и како резултат на тоа, зголемување на обемот на интернет сообраќај и обемот на складирани податоци. Ова е многу, и никој не може да си дозволи таков отпад.
Како резултат на развојот на Уникод, UTF-16, што се покажа толку успешно што стандардно беше усвоено како основен простор за сите знаци што ги користиме. Користи два бајта за кодирање на еден знак. Ајде да видиме како изгледа оваа работа.
Во оперативниот систем Виндоус, можете да ја следите патеката „Почеток“ - „Програми“ - „Додатоци“ - „Системски алатки“ - „Табела со знаци“. Како резултат на тоа, ќе се отвори табела со векторските форми на сите фонтови инсталирани на вашиот систем. Ако го изберете множеството знаци на Уникод во „Напредни опции“, ќе можете да го видите за секој фонт одделно целиот опсег на знаци вклучени во него.
Патем, со кликнување на кој било од нив, можете да го видите неговиот двобајт код во формат UTF-16, кој се состои од четири хексадецимални цифри:
Колку знаци може да се кодираат во UTF-16 користејќи 16 бита? 65.536 (два со моќ од шеснаесет), и ова е бројот што беше усвоен како основен простор во Unicode. Покрај тоа, постојат начини да се кодираат околу два милиони знаци користејќи го, но тие беа ограничени на проширен простор од милион карактери текст.
Но, дури и оваа успешна верзија на кодирањето на Уникод не им донесе големо задоволство на оние кои пишуваа, да речеме, програми само на англиски јазик, бидејќи за нив, по преминот од проширената верзија на ASCII на UTF-16, тежината на документите се удвои ( еден бајт по знак во Aski и два бајти за истиот знак во YUTF-16).
Токму за да се задоволат сите и сè во конзорциумот Уникод беше одлучено да се излезе кодирање со променлива должина. Се викаше UTF-8. И покрај осумте во името, тој всушност има променлива должина, т.е. Секој знак од текстот може да биде кодиран во низа од еден до шест бајти во должина.
Во пракса, UTF-8 користи само опсег од еден до четири бајти, бидејќи повеќе од четири бајти код повеќе не е ни теоретски можно да се замисли нешто. Сите латински знаци во него се кодирани во еден бајт, исто како во стариот добар ASCII.
Она што е забележливо е дека во случај на кодирање само на латиницата, дури и оние програми што не разбираат Unicode, сепак ќе го читаат она што е шифрирано во YTF-8. Оние. основниот дел на Асука едноставно беше префрлен на оваа креација на конзорциумот Уникод.
Кириличните знаци во UTF-8 се кодирани во два бајти, а, на пример, грузиските знаци се кодирани во три бајти. Конзорциумот Уникод, откако ги создаде UTF 16 и 8, го реши главниот проблем - сега имаме фонтовите имаат единствен простор за код. И сега нивните производители можат да го пополнат само со векторски форми на текстуални знаци врз основа на нивните силни страни и способности. Сега доаѓаат дури и во сетови.
Во „Табела со знаци“ погоре можете да видите дека различни фонтови поддржуваат различен број на знаци. Некои фонтови богати со Уникод може да бидат доста тешки. Но, сега тие не се разликуваат по тоа што се создадени за различни шифрирања, туку по тоа што производителот на фонтови го пополнил или не целосно го пополнил просторот за единствен код со одредени векторски форми.
Луди зборови наместо руски букви - како да се поправи
Ајде сега да видиме како се појавуваат krakozyabrs наместо текст или, со други зборови, како е избрано правилното кодирање за руски текст. Всушност, тој е поставен во програмата во која го креирате или уредувате овој текст или код користејќи фрагменти од текст.
За уредување и креирање текстуални датотеки, јас лично користам многу добар, според мое мислење, . Сепак, може да ја нагласи синтаксата на стотици други јазици за програмирање и обележување, а исто така има можност да се прошири со помош на приклучоци. Прочитајте детален преглед на оваа прекрасна програма на дадената врска.
Во горното мени на Notepad++ има ставка „Кодирање“, каде што ќе имате можност да конвертирате постоечка опција во онаа што се користи стандардно на вашата страница:
Во случај на локација на Joomla 1.5 и понова верзија, како и во случај на блог на WordPress, треба да ја изберете опцијата за да избегнете појава на пукнатини UTF 8 без BOM. Што е префиксот BOM?
Факт е дека кога го развиваа кодирањето YUTF-16, поради некоја причина решија да му прикачат такво нешто како што е можноста за пишување на кодот на знаци и во директна низа (на пример, 0A15) и обратно (150A) . И за програмите да разберат точно во која секвенца да ги читаат шифрите, тоа беше измислено БОМ(Byte Order Mark или, со други зборови, потпис), што беше изразено со додавање на три дополнителни бајти на самиот почеток на документите.
Во кодирањето UTF-8, не беа предвидени BOM-ови во конзорциумот Уникод, и затоа додавањето потпис (оние озлогласени дополнителни три бајти на почетокот на документот) едноставно спречува некои програми да го читаат кодот. Затоа, при зачувување на датотеки во UTF, секогаш мора да ја избереме опцијата без BOM (без потпис). Значи, вие сте однапред заштити се од лазење krakozyabrs.
Она што е забележливо е дека некои програми во Windows не можат да го направат тоа (не можат да зачуваат текст во UTF-8 без BOM), на пример, истиот озлогласен Windows Notepad. Го зачувува документот во UTF-8, но сепак го додава потписот (три дополнителни бајти) на почетокот на истиот. Покрај тоа, овие бајти секогаш ќе бидат исти - прочитајте го кодот во директна низа. Но, на серверите, поради оваа ситница, може да се појави проблем - ќе излезат измамници.
Затоа, под никакви околности Не користете обичен Windows Notepadда уредувате документи на вашата страница ако не сакате да се појавуваат пукнатини. Сметам дека веќе споменатиот уредник Notepad++ е најдобра и наједноставна опција, која практично нема никакви недостатоци и се состои само од предности.
Во Notepad++, кога ќе изберете кодирање, ќе имате опција да го конвертирате текстот во кодирање UCS-2, што по својата природа е многу блиску до стандардот Unicode. Исто така во Notepad ќе може да се кодира текст во ANSI, т.е. во однос на рускиот јазик, ова ќе биде Windows 1251, кој веќе го опишавме веднаш погоре.Од каде потекнуваат овие информации?
Регистриран е во регистарот на вашиот оперативен систем Виндоус - кое кодирање да се избере во случај на ANSI, кое да се избере во случај на OEM (за рускиот јазик ќе биде CP866). Ако поставите друг стандарден јазик на вашиот компјутер, тогаш овие шифрирања ќе бидат заменети со слични од категоријата ANSI или OEM за истиот јазик.
Откако ќе го зачувате документот во Notepad++ во кодирањето што ви треба или ќе го отворите документот од страницата за уредување, можете да го видите неговото име во долниот десен агол на уредувачот:
За да избегнете црвенилоПокрај дејствата опишани погоре, ќе биде корисно да се напишат информации за ова кодирање во заглавието на изворниот код на сите страници на страницата, така што нема забуна на серверот или локалниот домаќин.
Општо земено, сите јазици за означување на хипертекст освен Html користат специјална декларација xml, која го одредува кодирањето на текстот.
Пред да го анализира кодот, прелистувачот знае која верзија се користи и како точно треба да ги толкува шифрите на знаците на тој јазик. Но, она што треба да се забележи е дека ако го зачувате документот во стандардниот Unicode, тогаш оваа xml декларација може да се испушти (кодирањето ќе се смета за UTF-8 ако нема BOM или UTF-16 ако има BOM).
Во случај на документ со јазик на Html, кодирањето се користи за означување Мета елемент, што е напишано помеѓу ознаките за глава за отворање и затворање:
... ...
Овој запис е сосема различен од оној усвоен во, но е целосно усогласен со новиот Html 5 стандард кој полека се воведува и ќе биде целосно разбран правилно од сите прелистувачи што се користат во моментов.
Теоретски, би било подобро да се постави мета-елемент кој го означува кодирањето на Html документот што е можно повисоко во заглавието на документоттака што во моментот на средба со првиот знак во текстот не од основниот ANSI (кои секогаш се читаат правилно и во која било варијација), прелистувачот веќе треба да има информации за тоа како да ги толкува шифрите на овие знаци.
Со среќа! Се гледаме наскоро на страниците на блог-страницата
Можеби ќе ве интересира
Кои се URL-адресите, како се разликуваат апсолутните и релативните врски за една локација? 
OpenServer - модерен локален сервер и пример за тоа како да го користите за инсталирање WordPress на компјутер 
Што е Chmod, какви дозволи да се доделат на датотеки и папки (777, 755, 666) и како да се направи тоа преку PHP 
Пребарување Yandex по страница и онлајн продавница
