Unicode'i kodeering 2. Unicode'i loomise ja arendamise eeldused

Tere, kallid ajaveebisaidi lugejad. Täna räägime teiega sellest, kust krakozyabrid saidilt ja programmides pärinevad, millised tekstikodeeringud on olemas ja milliseid tuleks kasutada. Vaatame lähemalt nende väljatöötamise ajalugu, alustades põhi-ASCII-st, aga ka selle laiendatud versioonidest CP866, KOI8-R, Windows 1251 ning lõpetades Unicode Consortium UTF 16 ja 8 kaasaegsete kodeeringutega.

Mõnele võib see teave tunduda üleliigne, kuid te teaksite, kui palju küsimusi ma saan konkreetselt välja roomatud krakozyabri (loetamatu märgikomplekt) kohta. Nüüd on mul võimalus viidata kõigile selle artikli tekstile ja otsida iseseisvalt oma lengi. Olge valmis teabe vastuvõtmiseks ja proovige jälgida loo kulgu.

ASCII – ladina keele põhiteksti kodeering

Tekstikodeeringu väljatöötamine toimus samaaegselt IT-tööstuse kujunemisega ja selle aja jooksul õnnestus neil läbi viia üsna palju muudatusi. Ajalooliselt sai kõik alguse EBCDIC-st, mis oli vene häälduses üsna dissonantne, mis võimaldas kodeerida ladina tähestiku tähti, araabia numbreid ja kirjavahemärke koos juhtmärkidega.

Kuid ikkagi tuleks kaasaegsete tekstikodeeringu väljatöötamise lähtepunktiks pidada kuulsat ASCII(Ameerika standardkood teabevahetuseks, mida vene keeles hääldatakse tavaliselt kui "aski"). See kirjeldab inglise keelt kõnelevate kasutajate seas kõige sagedamini kasutatavaid 128 tähemärki – ladina tähti, araabia numbreid ja kirjavahemärke.

Isegi nendes 128 ASCII-s kirjeldatud märgis olid mõned teenindusmärgid, nagu sulud, tulbad, tärnid jne. Tegelikult näete neid ise:

Just need 128 tähemärki ASCII algversioonist on saanud standardiks ja mis tahes muus kodeeringus kohtate neid kindlasti ja need seisavad selles järjekorras.

Kuid tõsiasi on see, et ühe teabebaidi abil on võimalik kodeerida mitte 128, vaid koguni 256 erinevat väärtust (kaks kaheksa astmega võrdub 256), seega järgides põhiversioon Asuka ilmus number laiendatud ASCII kodeeringud, millesse sai lisaks 128 põhimärgile kodeerida ka rahvusliku kodeeringu (näiteks vene) sümboleid.

Siinkohal tasub ilmselt veidi lähemalt rääkida kirjelduses kasutatud numbrisüsteemidest. Esiteks, nagu te kõik teate, töötab arvuti ainult kahendsüsteemis olevate numbritega, nimelt nullide ja ühtedega ("Boole'i algebra", kui keegi õppis instituudis või koolis). , millest igaüks on astmes kaks, mis algab nullist, ja kuni kaks seitsmendas:

Ei ole raske mõista, et sellises konstruktsioonis saab kõiki võimalikke nullide ja ühtede kombinatsioone olla ainult 256. Tõlkida arv alates kahendsüsteem kümnendkohani on üsna lihtne. Peate lihtsalt liitma kõik kahe võimsused, mille üle on üks.

Meie näites on see 1 (2 nulli astmeni) pluss 8 (kaks 3 astmeni), pluss 32 (kaks viiendani), pluss 64 (kuuendani), pluss 128 (seitsmendani) . Kokku saab 233 tolli kümnendsüsteem arvestus. Nagu näete, on kõik väga lihtne.

Kuid kui vaatate ASCII-märkide tabelit lähemalt, näete, et need on esitatud kuueteistkümnendsüsteemis. Näiteks "tärn" vastab Asci keeles kuueteistkümnendsüsteemi numbrile 2A. Tõenäoliselt teate seda kuueteistkümnendsüsteem kasutatakse numbreid, lisaks araabia numbritele ka ladina tähti A-st (tähendab kümmet) kuni F-ni (tähendab viisteist).

Noh, selleks teisendada binaarne kuueteistkümnendsüsteemi kasutada järgmist lihtsat ja visuaalset meetodit. Iga teabebait on jagatud kaheks neljabitiseks osaks, nagu on näidatud ülaltoodud ekraanipildil. See. igas poolbaidis saab kahendkoodina kodeerida ainult kuusteist väärtust (kahest kuni neljanda astmeni), mida saab hõlpsasti esitada kuueteistkümnendarvuna.

Veelgi enam, baidi vasakus pooles on vaja kraade uuesti lugeda, alustades nullist, mitte nagu ekraanipildil. Selle tulemusena saame lihtsate arvutustega, et ekraanipildil on kodeeritud arv E9. Loodan, et minu arutluskäik ja selle mõistatuse lahendus osutusid teile selgeks. Noh, jätkame nüüd tegelikult teksti kodeeringutest rääkimist.

Asuka - CP866 ja KOI8-R kodeeringu laiendatud versioonid koos pseudograafiaga

Niisiis hakkasime rääkima ASCII-st, mis oli justkui kõigi kaasaegsete kodeeringute (Windows 1251, Unicode, UTF 8) arendamise lähtepunkt.

Algselt sisaldas see ainult 128 ladina tähestikku, araabia numbreid ja midagi muud, kuid laiendatud versioonis sai võimalikuks kasutada kõiki 256 väärtust, mida saab ühe teabebaidi sisse kodeerida. Need. sai võimalikuks lisada Ascisse oma keele tähtede tähemärke.

Siin on vaja veel kord kõrvale kalduda, et selgitada - Miks sul üldse kodeerimist vaja on? tekstid ja miks see nii oluline on. Arvutiekraanil olevad märgid moodustatakse kahe asja põhjal - kõikvõimalike märkide vektorkujundite komplektid (esitlused) (need on kaasfailides) ja kood, mis võimaldab teil sellest vektorkujundite komplektist välja tõmmata ( fondifail) täpselt see märk, mille peate õigesse kohta sisestama.

On selge, et vektorvormide eest vastutavad fondid ise, kuid kodeerimise eest vastutab operatsioonisüsteem ja selles kasutatavad programmid. Need. mis tahes tekst teie arvutis on baitide komplekt, millest igaüks kodeerib selle teksti ühe märgi.

Programm, mis seda teksti ekraanil kuvab (tekstiredaktor, brauser jne), loeb koodi sõelumise ajal järgmise märgi kodeeringut ja otsib vastavat vektorvormi soovitud fail font, mis on selle tekstidokumendi kuvamiseks ühendatud. Kõik on lihtne ja banaalne.

See tähendab, et mis tahes meile vajaliku märgi kodeerimiseks (näiteks rahvustähestikust), peab olema täidetud kaks tingimust – selle märgi vektorkuju peab olema kasutatud fondis ja see märk võib olla kodeeritud laiendatud ASCII kodeeringus ühes baidis. Seetõttu on selliseid võimalusi terve hulk. Ainult vene keele märkide kodeerimiseks on laiendatud Aska mitut tüüpi.

Näiteks esialgu oli CP866, milles oli võimalik kasutada vene tähestiku tähemärke ja see oli ASCII laiendatud versioon.

Need. selle ülemine osa langes täielikult kokku Asuka põhiversiooniga (128 ladina tähemärki, numbreid ja muud jama), mis on näidatud ülaloleval ekraanipildil, kuid CP866 kodeeringuga tabeli alumine osa oli täpselt alloleval ekraanipildil näidatud kujul. ja lubati kodeerida veel 128 märki (seal vene tähed ja igasugune pseudograafia):

Näete, et paremas veerus algavad numbrid 8-ga, sest numbrid 0 kuni 7 viitavad ASCII põhiosale (vt esimest ekraanipilti). See. vene tähe "M" CP866-s on kood 9C (see asub kuueteistkümnendsüsteemis numbriga C vastava rea ja numbriga C ristumiskohas), mille saab kirjutada ühe baidi teabega, ja kui on sobiv vene tähtedega font, kuvatakse see täht probleemideta tekstis.

Kust see summa tuli? pseudograafia CP866-s? Asi on selles, et see venekeelse teksti kodeering töötati välja neil karvastel aastatel, kui graafiliste operatsioonisüsteemide sellist levitamist nagu praegu ei olnud. Ja Dosas ja sarnastes tekstioperatsioonisüsteemides võimaldas pseudograafika tekstide kujundust kuidagi mitmekesistada ning seetõttu on selles rohkesti CP866 ja kõiki teisi Asuka laiendatud versioonide kategooriast.

CP866 levitas IBM, kuid lisaks sellele töötati välja hulk kodeeringuid vene tähemärkide jaoks, näiteks võib omistada sama tüüpi (laiendatud ASCII) KOI8-R:

Selle tööpõhimõte jääb samaks, mis veidi varem kirjeldatud CP866-l - teksti iga märk on kodeeritud ühe baidiga. Ekraanitõmmis näitab KOI8-R tabeli teist poolt, kuna esimene pool vastab täielikult põhilisele Asukale, mis on näidatud selle artikli esimesel ekraanipildil.

KOI8-R kodeeringu omaduste hulgas võib märkida, et selle tabelis olevad vene tähed ei ole tähestikulises järjekorras, nagu tehti näiteks CP866-s.

Kui vaatate kõige esimest ekraanipilti (alusosast, mis sisaldub kõigis laiendatud kodeeringus), märkate, et KOI8-R-is asuvad vene tähed tabeli samades lahtrites kui ladina tähestiku kaashääliku tähed. nendega tabeli esimesest osast. Seda tehti vene tähtedelt ladina tähtedele ülemineku mugavuse huvides, jättes kõrvale ainult ühe biti (kaks seitsmenda astmeni ehk 128).

Windows 1251 - ASCII kaasaegne versioon ja miks krakozyabry välja roomab

Tekstikodeeringu edasiarendamine oli tingitud asjaolust, et graafilised operatsioonisüsteemid kogusid populaarsust ja vajadus neis pseudograafia kasutamise järele kadus lõpuks ära. Selle tulemusena tekkis terve grupp, mis sisuliselt olid ikkagi Asuka laiendatud versioonid (üks märk tekstist on kodeeritud vaid ühe baidi teabega), kuid ilma pseudograafilisi märke kasutamata.

Need kuulusid nn ANSI-kodeeringutesse, mille töötas välja Ameerika Standardiinstituut. Tavakeeles kasutati kirillitsat ka vene keele toega variandi kohta. Selle näide võib olla kasulik.

See on võrreldav varem kasutatud CP866 ja KOI8-R-ga selle poolest, et pseudograafiliste sümbolite koha hõivasid vene tüpograafia puuduvad sümbolid (peale aktsendimärgi), aga ka slaavi keeltes kasutatavad sümbolid. vene keel (ukraina, valgevene jne).)

Tänu sellisele venekeelsete kodeeringute rohkusele fonditootjad ja -tootjad tarkvara peavalu tekkis pidevalt ja meie, kallid lugejad, saime sageli samad kurikuulsad krakozyabry kui tekkis segadus tekstis kasutatud versiooniga.

Väga sageli said nad välja sõnumite saatmisel ja vastuvõtmisel e-mail, millega kaasnes väga keeruliste teisendustabelite loomine, mis tegelikult ei suutnud seda probleemi juurtes lahendada, ja sageli kasutasid kasutajad kirjavahetust, et vältida kurikuulsaid krakozyabrse, kui kasutati venekeelseid kodeeringuid, nagu CP866, KOI8-R või Windows 1251.

Tegelikult oli tulemuseks venekeelse teksti asemel välja roniv krakozyabry ebaõige kasutamine kodeeringud antud keel, mis ei ühtinud sellega, millesse see oli kodeeritud tekstisõnum esialgu.

Oletame, et CP866-ga kodeeritud märgid proovivad kuvada kasutades kooditabel Windows 1251, siis tulevad need samad krakozyabry (mõttetu tähemärkide komplekt) välja, asendades täielikult sõnumi teksti.

Sarnane olukord tekib väga sageli foorumites või ajaveebides, kui vene tähtedega tekst salvestatakse ekslikult valesse kodeeringusse, mida saidil vaikimisi kasutatakse, või vales kodeeringus. tekstiredaktor, mis lisab koodile gag’i, mis pole palja silmaga nähtav.

Lõpuks tüdinesid paljud sellisest olukorrast rohkete kodeeringute ja pideva krakozyabry väljatulekuga, olid eeldused uue universaalse variatsiooni loomiseks, mis asendaks kõik olemasolevad ja lahendaks lõpuks probleemi loetamatute tekstide ilmumisega. . Lisaks oli probleem selliste keelte puhul nagu hiina keel, kus keele tähemärke oli palju rohkem kui 256.

Unicode (Unicode) - universaalsed kodeeringud UTF 8, 16 ja 32

Neid tuhandeid Kagu-Aasia keelerühma tähemärke ei saanud kuidagi kirjeldada ühes teabebaidis, mis eraldati märkide kodeerimiseks ASCII laiendatud versioonides. Selle tulemusena moodustas konsortsium nimega Unicode(Unicode - Unicode Consortium) koostöös paljude IT-valdkonna juhtidega (need, kes toodavad tarkvara, kes kodeerivad riistvara, kes loovad fonte), kes olid huvitatud universaalse tekstikodeeringu tekkimisest.

Esimene Unicode'i konsortsiumi egiidi all välja antud variatsioon oli UTF-32. Arv kodeeringu nimes tähendab bittide arvu, mida kasutatakse ühe märgi kodeerimiseks. 32 bitti on 4 baiti teavet, mida on vaja ühe märgi kodeerimiseks uues universaalses kodeeringus UTF-is.

Selle tulemusena on sama tekstiga fail, mis on kodeeritud ASCII laiendatud versioonis ja UTF-32, viimasel juhul neli korda suurem. See on halb, kuid nüüd on meil võimalus UTF-i abil kodeerida tähemärkide arv, mis on võrdne kahe kolmekümne sekundi astmega ( miljardeid tegelasi, mis katab igasuguse tõeliselt vajaliku väärtuse tohutu varuga).

Kuid paljud riigid, kus on Euroopa rühma keeli, ei pidanud kodeeringus üldse kasutama nii suurt hulka märke, kuid UTF-32 kasutamisel said nad ilma asjata neljakordse kaalutõusu. tekstidokumendid, ning selle tulemusena Interneti-liikluse ja salvestatud andmete hulga suurenemine. Seda on palju ja keegi ei saaks sellist raiskamist endale lubada.

Unicode'i arendamise tulemusena UTF-16, mis osutus nii edukaks, et see võeti vastu kõigi meie kasutatavate märkide vaikepõhiruumina. See kasutab ühe märgi kodeerimiseks kahte baiti. Vaatame, kuidas see asi välja näeb.

IN operatsioonisüsteem Windows, võite minna mööda teed "Start" - "Programmid" - "Aksessuaarid" - "Utiliidid" - "Tähemärkide tabel". Selle tulemusena avaneb tabel kõigi teie süsteemi installitud fontide vektorkujudega. Kui valite jaotises " Lisavalikud» Unicode märgikomplekt, näete iga fondi jaoks eraldi kogu selles sisalduvat märkide valikut.

Muide, mõnel neist klõpsates näete selle kahebaiti kood UTF-16 formaadis, mis koosneb neljast kuueteistkümnendnumbrist:

Mitu tähemärki saab UTF-16-s kodeerida, kasutades 16 bitti? 65536 (kaks astmega kuusteist) ja just see number võeti Unicode'i baasruumina. Lisaks on viise, kuidas sellega kodeerida umbes kaks miljonit tähemärki, kuid see on piiratud miljoni tähemärgi pikkuse tekstiruumiga.

Kuid isegi see Unicode'i kodeeringu edukas versioon ei pakkunud erilist rahulolu neile, kes kirjutasid näiteks programme ainult inglise keel, sest pärast üleminekut ASCII laiendatud versioonilt UTF-16-le kahekordistus dokumentide kaal (Asci puhul üks bait märgi kohta ja UTF-16 puhul kaks baiti tähemärgi kohta).

See on kõik, et kõik ja kõik Unicode'i konsortsiumis rahul oleks, otsustati välja mõelda muutuva pikkusega kodeering. Seda nimetatakse UTF-8. Vaatamata nimes olevale kaheksale on see tõesti muutuva pikkusega, st. iga tekstimärgi saab kodeerida ühest kuni kuuebaidiseks jadaks.

Praktikas kasutatakse UTF-8-s ainult vahemikku ühest kuni neljabaidini, sest nelja baidi koodi taga pole midagi isegi teoreetiliselt võimalik ette kujutada. Kõik selles olevad ladina tähed on kodeeritud ühte baidi, täpselt nagu vanas heas ASCII-s.

Tähelepanuväärne on see, et ainult ladinakeelse kodeerimise korral loevad ka need programmid, mis Unicode'ist aru ei saa, ikkagi UTF-8 kodeeringut. Need. Asuka põhiosa läks lihtsalt Unicode'i konsortsiumi vaimusünnitusse.

UTF-8 kirillitsa märgid on kodeeritud kahes baidis ja näiteks gruusia tähed kolmes baidis. Unicode'i konsortsium lahendas pärast UTF 16 ja 8 loomist põhiprobleemi – nüüd on meil fontidel on üks koodiruum. Ja nüüd saavad nende tootjad seda täita ainult tekstimärkide vektorvormidega, lähtudes nende tugevustest ja võimalustest. Nüüd isegi komplektidena.

Ülaltoodud "Tähemärkide tabelis" näete, et erinevad fondid toetavad erinevat arvu märke. Mõned Unicode-rikkad fondid võivad olla väga suured. Kuid nüüd ei erine need mitte selle poolest, et need loodi erinevate kodeeringute jaoks, vaid selle poolest, et fonditootja täitis või ei täitnud ühe koodiruumi ühe või teise vektorvormiga lõpuni.

Krakozyabry vene tähtede asemel - kuidas parandada

Vaatame nüüd, kuidas teksti asemel ilmuvad krakozyabras ehk teisisõnu, kuidas valitakse venekeelse teksti jaoks õige kodeering. Tegelikult määratakse see programmis, milles loote või redigeerite sama teksti või koodi, kasutades tekstifragmente.

Redigeerimiseks ja loomiseks tekstifailid Mina isiklikult kasutan enda arvates väga head. Küll aga suudab see esile tuua veel hea saja programmeerimis- ja märgistuskeele süntaksi ning seda on võimalik ka pluginate abil laiendada. Lugege üksikasjalik ülevaade see suurepärane programm toodud lingil.

Notepad ++ ülemises menüüs on üksus "Kodeeringud", kus saate olemasoleva valiku teisendada teie saidil vaikimisi kasutatavaks:

Joomla 1.5 ja uuemate versioonidega saidi puhul, samuti WordPressi ajaveebi puhul valige vigade ilmnemise vältimiseks valik UTF8 ilma BOM-ita. Mis on eesliide BOM?

Fakt on see, et kui UTF-16 kodeering töötati välja, otsustasid nad mingil põhjusel sellele lisada sellise asja nagu märgikoodi kirjutamise võimalus nii otseses järjestuses (näiteks 0A15) kui ka vastupidises järjekorras (150A). . Ja selleks, et programmid aru saaksid, millises järjekorras koode lugeda, leiutati see BOM(Byte Order Mark ehk teisisõnu signatuur), mis väljendus kolme täiendava baidi lisamises dokumentide päris algusesse.

UTF-8 kodeeringus ei olnud Unicode'i konsortsiumis BOM-i ette nähtud ja seetõttu allkirja lisamine (need kõige kurikuulsamad täiendavad kolm baiti dokumendi algusesse) lihtsalt takistab mõnel programmil koodi lugemist. Seetõttu peame UTF-vormingus failide salvestamisel alati valima valiku ilma BOM-ita (ilma allkirjata). Nii et liigute edasi kaitsta end indekseerimise krakozyabry.

Märkimisväärne on see, et mõned Windowsi programmid ei tea, kuidas seda teha (nad ei saa UTF-8-s teksti salvestada ilma BOM-ita), näiteks sama kurikuulus Windowsi märkmik. See salvestab dokumendi UTF-8 vormingus, kuid lisab siiski allkirja (kolm lisabaiti) selle algusesse. Veelgi enam, need baidid on alati samad - lugege koodi otseses järjestuses. Kuid serverites võib selle pisiasja tõttu tekkida probleem - krakozyabry tuleb välja.

Seetõttu mitte mingil juhul ärge kasutage tavalist Windowsi märkmikku oma saidi dokumentide redigeerimiseks, kui te ei soovi krakozyabrovi ilmumist. Pean parimaks ja lihtsamaks võimaluseks juba mainitud Notepad ++ redaktorit, millel praktiliselt puuduvad puudused ja mis koosneb vaid eelistest.

Notepad++-s on teil kodeeringu valimisel võimalus teisendada tekst UCS-2 kodeeringusse, mis on oma olemuselt väga lähedane Unicode'i standardile. Ka Notepadis saab olema võimalik teksti kodeerida ANSI-s, st. vene keelega seoses on selleks Windows 1251, mida oleme juba veidi eespool kirjeldanud. Kust see teave pärineb?

See on registreeritud teie operatsioonitoa registris Windowsi süsteemid- milline kodeering valida ANSI puhul, milline OEM puhul (vene keele puhul on see CP866). Kui installite arvutisse mõne muu vaikekeele, asendatakse need kodeeringud sama keele jaoks sarnaste ANSI või OEM-kategooria kodeeringutega.

Pärast dokumendi salvestamist Notepad ++ vajalikus kodeeringus või dokumendi saidilt redigeerimiseks avamist, näete selle nime redaktori paremas alanurgas:

Krakozyabrovi vältimiseks, on lisaks ülalkirjeldatud toimingutele kasulik kirjutada selle kodeeringu kohta teave saidi kõigi lehtede lähtekoodi päisesse, et serveris või kohalikus hostis ei tekiks segadust.

Üldiselt kasutatakse kõigis hüperteksti märgistuskeeltes, välja arvatud HTML, spetsiaalset xml-deklaratsiooni, mis määrab teksti kodeeringu.

Enne koodi sõelumist teab brauser, millist versiooni kasutatakse ja kuidas täpselt selle keele märgikoode tõlgendada. Kuid mis on tähelepanuväärne, kui salvestate dokumendi vaikimisi unicode'i, siis võib selle xml-deklaratsiooni ära jätta (BOM-i puudumisel peetakse kodeeringut UTF-8 või BOM-i olemasolul UTF-16).

Dokumendi puhul HTML-i keel kasutatakse kodeeringu määramiseks Meta element, mis on kirjutatud ava- ja sulgemissildi Head vahele:

... ...

See kirje erineb üsna aastal vastuvõetavast, kuid on täielikult kooskõlas uue Html 5 standardiga, mida hakatakse tasapisi kasutusele võtma, ja sellest saavad kõik, kes seda kasutavad, täiesti õigesti aru. Sel hetkel brauserid.

Teoreetiliselt Meta element koos kodeeringuga html dokumenti parem oleks panna võimalikult kõrgele dokumendi päises nii et kohtumise ajal esimese tähemärgi tekstis, mis ei ole põhi-ANSI-st (mida loetakse alati õigesti ja mis tahes variatsioonis), peaks brauseril juba olema teave selle kohta, kuidas nende märkide koode tõlgendada.

Edu sulle! Kohtumiseni ajaveebi lehtedel

Võib-olla olete huvitatud

Mis on juhtunud URL-aadress Mis vahe on saidi absoluutsetel ja suhtelistel linkidel?
OpenServer – kaasaegne kohalik server ja näide selle kasutamisest WordPressi installid arvutis
Mis on Chmod, milliseid õigusi failidele ja kaustadele (777, 755, 666) määrata ja kuidas seda teha PHP kaudu
Yandexi otsing saidil ja veebipoes

Püüdes seda või teist Interneti-funktsiooni konfigureerida, peab iga kasutaja olema kohanud sellist mõistet nagu "Unicode". Et teada saada, mida see mõiste tähendab, lugege see artikkel lõpetama.

"Unicode": määratlus

Mõiste "Unicode" viitab tänapäeval märgikodeeringu standardile. See standard pakkus välja 1991. aastal mittetulundusühing Unicode Inc. Unicode'i standard oli mõeldud suure hulga erinevate märkide ühendamiseks ühes dokumendis. Sellise kodeeringu alusel loodud leht võib sisaldada hieroglüüfe, tähti ja matemaatilisi sümboleid. Selles kodeeringus kuvatakse kõik märgid probleemideta.

"Unicode": loomise põhjused

Ammu enne Unicode'i süsteemi tulekut valiti kodeeringud lähtuvalt dokumendi autori eelistustest. Sageli oli sel põhjusel ühe dokumendi lugemiseks vaja kasutada erinevaid tabeleid. Seda tuli aga mitu korda teha. See raskendab oluliselt tavakasutajate elu. Nagu varem mainitud, asus 1991. aastal selle probleemi lahendamiseks mittetulundusühing Unicode Inc. tegi ettepaneku kasutada uut tüüpi teabe kodeerimist. Seda tüüpi kodeerimine loodi erinevate standardite kombineerimiseks. Unicode'i kodeering võimaldas saavutada võimatut: luua tööriist, mis toetab tohutult erinevaid märke. Tulemus ületas ootusi: saadi dokumendid, mis võisid üheaegselt sisaldada nii vene- kui ingliskeelset teksti, aga ka matemaatilisi väljendeid ja ladina keelt. Enne loomist ühtne süsteem kodeeringu arendajad pidid lahendama mitmeid probleeme, mis tulenevad tohutu hulga standardite olemasolust, mis olid juba olemas. Sel hetkel. Kõige levinumad neist probleemidest olid märgistiku piirangud, elfish-skriptid, fontide dubleerimine ja erinevate kodeeringute teisendamise probleem.

"Unicode": kõrvalepõik ajalukku

Kujutage ette järgmist pilti: 80ndate õuel pole arvutitehnoloogia veel nii laialt levinud ja on tänasest erineva välimusega. Iga operatsioonisüsteem on omal moel ainulaadne ja entusiastid on seda teatud konkreetsete vajaduste jaoks kohandanud. Selle tulemusena on teabevahetuse vajadus toonud kaasa täiendavaid täiustusi. Püüdes lugeda mõnes teises operatsioonisüsteemis loodud dokumenti, ilmusid ekraanile tavaliselt kummalised märgistikud. See nõudis edasist tööd kodeeringuga, mida ei olnud alati võimalik kiiresti lõpule viia. Mõnikord kulus vajaliku dokumendi vormistamiseks mitu kuud. Kasutajad, kes peavad sageli teavet vahetama, hakkasid ise looma spetsiaalseid teisendustabeleid. Selliste tabelitega töötades ilmnes üks huvitav omadus: selliseid tabeleid on vaja luua samaaegselt kahes suunas. Masin ei saa arvutusi banaalselt ümber pöörata. Selle jaoks kirjutatakse lähtefail paremasse veergu ja tulemus vasakule. Vastupidi, neid ei saa ümber korraldada. Kui peate dokumendis kasutama erimärke, peate need esmalt lisama ja seejärel teisele kasutajale selgitama, mida nendega teha, et need ei muutuks "pragudeks". Samuti tasub arvestada, et iga kodeering pidi välja töötama oma fondid. See tõi kaasa tohutu hulga duplikaate loomise operatsioonisüsteemis. Nii võis kasutaja näiteks ühel lehel näha tosinat fonti, mis on identsed standardse Times New Romaniga, kuid tähistatud UCS-2, UTF-16, UTF-8, ANSI-ga. Seega on vaja välja töötada universaalne standard.

"Unicode": loojad

"Unicode'i" loomise ajaloo alguseks võib pidada 1987. aastat. See oli siis, kui Joe Becker Xeroxist koos Mark Davise ja Lee Collinsiga Apple'ist alustas universaalse kodeeringu praktilise arendamise uuringuid. 1988. aastal avaldas Joe Becker rahvusvahelise mitmekeelse kodeeringu kavandi. Mõni kuu hiljem laiendati töötavat Unicode'i arendusgruppi. Sellesse kuulusid sellised eksperdid nagu Glenn Wright Sun Microsystemsist, Mike Kernegan ja Ken Whistler RLG-st. See võimaldas lõpule viia ühe kodeerimisstandardi esialgse moodustamise.

"Unicode": üldine kirjeldus

Unicode põhineb üldine kontseptsioon sümbol. Seda definitsiooni mõistetakse kui abstraktset nähtust, mis eksisteerib kirjutamise vormis, realiseerub grafeemide kaudu. Unicode'is on igale märgile määratud unikaalne kood, mis kuulub ühte või teise standardi plokki. Nii näiteks on grafeem "B" olemas nii inglise kui ka vene keeles, kuid see vastab kahele erinevale tähemärgile. Neid märke saab ka väiketähtedeks teisendada. See tähendab, et kõiki neid sümboleid kirjeldatakse võtme, omaduste komplekti ja nimega.

"Unicode": eelised

Unicode erineb teistest kaasaegsetest kodeerimissüsteemidest tohutu hulga tähemärkide poolest erinevate märkide "krüpteerimiseks". Asi on selles, et eelmistel kodeeringustel oli ainult 8 bitti. See tähendab, et need toetasid ainult 28 tähemärki. Uues arenduses oli 216 tähemärki, mis oli suur samm edasi. Nii sai võimalikuks peaaegu kõigi olemasolevate tähestike kodeerimine. "Unicode'i" tulekuga on kadunud vajadus kasutada teisendustabeleid. Ühtse standardi olemasolu vähendas nende kasulikkuse lihtsalt nullini. Samal ajal kadus ka "kryakozyabry". Uue standardi tekkimine muutis nende olemasolu võimatuks. Samuti kaotati vajadus luua dubleerivaid fonte.

"Unicode": arendus

Hoolimata asjaolust, et areng ei seisa paigal, hoiab Unicode'i kodeering jätkuvalt maailmas juhtivat positsiooni. See sai võimalikuks suuresti tänu sellele, et see sai hõlpsasti rakendatavaks ja laialdaselt kasutusele võetud. Siiski ei tasu arvata, et tänapäeval kasutatakse sama Unicode'i kodeeringut, mis 25 aastat tagasi. Tänapäeval kasutatakse versiooni 5.x.x. Kodeeritud märkide arv on kasvanud 231-ni. Alates selle loomisest kuni versiooni 2.0.0 tulekuni on Unicode-kodeering selles sisalduvate märkide arvu peaaegu kahekordistunud. Järgnevatel aastatel see võimaluste kasv jätkus. Versiooni 4.0.0 ilmumise ajaks tekkis vajadus standardit ennast suurendada. Selle tulemusel võttis Unicode'i kodeering sellise kuju, nagu me seda täna tunneme.

Mis veel Unicode'is kasulik on? Lisaks tohutule, pidevalt kasvavale tähemärkide arvule on Unicode-kodeeringul üks üsna kasulik funktsioon. See on normaliseerimine. Kodeering ei raiska arvutiressursse sama tähemärgi regulaarsele kontrollimisele, kuna sellel võib erinevates tähestikes olla sarnane kirjapilt. Selleks kasutatakse spetsiaalset algoritmi, mis võimaldab sarnaseid märke veerus eraldi kuvada ja neile juurde pääseda, mitte kogu teavet iga kord kontrollida. Kokku on välja töötatud ja rakendatud neli sellist algoritmi. Igaühe neist toimub ümberkujundamine teatud põhimõtte kohaselt, mis erineb teistest.

Iga Interneti-kasutaja, püüdes üht või teist oma funktsiooni konfigureerida, nägi vähemalt korra ekraanil kirjutatud sõna "Unicode". Mis see on, saate teada, lugedes seda artiklit.

Definitsioon

Unicode on märgikodeeringu standard. Selle pakkus välja mittetulundusühing Unicode Inc. aastal 1991. Standard töötati välja eesmärgiga koondada ühte dokumenti võimalikult palju erinevat tüüpi tähemärke. Sellel põhinev leht võib sisaldada eri keelte tähti ja hieroglüüfe (vene keelest korea keelde) ja matemaatilisi sümboleid. Sel juhul kuvatakse kõik selle kodeeringu märgid probleemideta.

Loomise põhjused

Kunagi ammu enne ühtse Unicode'i süsteemi tulekut valiti kodeering dokumendi autori eelistuste põhjal. Sel põhjusel ei olnud haruldane lugeda ka ühte dokumenti kasutades erinevad lauad. Mõnikord tuli seda teha mitu korda, mis muutis tavakasutaja elu oluliselt keerulisemaks. Nagu juba mainitud, pakkus sellele probleemile lahenduse 1991. aastal mittetulundusühing Unicode Inc., kes pakkus välja uut tüüpi märgikodeeringu. Selle eesmärk oli ühendada vananenud ja mitmekesised standardid. "Unicode" on kodeering, mis võimaldas saavutada tol ajal mõeldamatut: luua tööriist, mis toetab tohutul hulgal märke. Tulemus ületas paljusid ootusi – ilmusid dokumendid, mis sisaldasid korraga nii inglis- kui venekeelset teksti, ladina ja matemaatilisi väljendeid.

Kuid ühtse kodeeringu loomisele eelnes vajadus lahendada mitmeid probleeme, mis tekkisid sel ajal juba eksisteerinud standardite tohutu mitmekesisuse tõttu. Kõige levinumad neist:

haldjatähed või "krakozyabry";
piiratud hulk tähemärke;
kodeerimise teisendamise probleem;
topeltfonte.

Väike ajalooline ekskursioon

Kujutage ette, et see on 80ndatel. Arvutitehnoloogia pole veel nii levinud ja välimus on teistsugune kui praegu. Sel ajal on iga OS omal moel ainulaadne ja iga entusiast on seda kohandanud vastavalt konkreetsetele vajadustele. Vajadus jagada teavet muutub täiendavaks viimistlemiseks kõigele maailmas. Teise OS-i all loodud dokumendi lugemise katsel kuvatakse ekraanil sageli arusaamatu tähemärkide komplekt ja algavad mängud kodeeringuga. Alati ei ole võimalik seda kiiresti teha ja mõnikord saab vajaliku dokumendi avada kuue kuu pärast või isegi hiljem. Sageli teavet vahetavad inimesed loovad enda jaoks teisendustabeleid. Ja nende kallal töötamine näitab huvitav detail: peate need looma kahes suunas: "minu omast sinu omani" ja vastupidi. Masin ei saa arvutustes banaalset ümberpööramist teha, sest selle jaoks on allikas paremas veerus ja tulemus vasakul, kuid mitte vastupidi. Kui dokumendis tekkis vajadus kasutada mingeid erimärke, tuleb need esmalt lisada ja seejärel ka partnerile selgitada, mida ta peab tegema, et need märgid "hulluks" ei läheks. Ja ärgem unustagem, et iga kodeeringu jaoks pidime välja töötama või juurutama oma fondid, mis viis OS-i tohutu hulga duplikaatide loomiseni.

Kujutage ette ka seda, et fontide lehel näete 10 tükki identset Times New Romani väikeste märkidega: UTF-8, UTF-16, ANSI, UCS-2 jaoks. Kas saate nüüd aru, et universaalse standardi väljatöötamine oli tungiv vajadus?

"Loojast isad"

Unicode'i päritolu võib ulatuda aastasse 1987, mil Joe Becker Xeroxist koos Lee Collinsi ja Mark Davisega Apple'ist alustas universaalse märgistiku praktilise loomise uurimist. 1988. aasta augustis avaldas Joe Becker 16-bitise rahvusvahelise mitmekeelse kodeerimissüsteemi ettepaneku eelnõu.

Mõne kuu pärast töögrupp Unicode'i laiendati, et hõlmata Ken Whistler ja Mike Kernegan RLG-st, Glenn Wright Sun Microsystemsist ja veel mõned, mis lõpetasid eeltöö ühe kodeerimisstandardi kallal.

üldkirjeldus

Unicode põhineb tähemärgi kontseptsioonil. See määratlus viitab abstraktsele nähtusele, mis eksisteerib teatud tüüpi kirjutises ja realiseeritakse grafeemide (selle "portreede") kaudu. Iga märk on "Unicode'is" määratletud unikaalse koodiga, mis kuulub standardi konkreetsesse plokki. Näiteks grafeem B on olemas nii inglise kui ka vene tähestikus, kuid Unicode'is on sellel 2 erinevat märki. Neile rakendatakse teisendus, st igaüht neist kirjeldatakse andmebaasivõtme, atribuutide komplekti ja täisnimega.

Unicode'i eelised

Teistest kaasaegsetest eristas Unicode'i kodeering märkide "krüpteerimiseks" mõeldud tohutu hulga tähemärkidega. Fakt on see, et selle eelkäijatel oli 8 bitti, see tähendab, et nad toetasid 28 tähemärki, kuid uus arendus oli juba 216 tähemärki, mis oli hiiglaslik samm edasi. See võimaldas kodeerida peaaegu kõik olemasolevad ja levinud tähestikud.

"Unicode'i" tulekuga pole vaja kasutada teisendustabeleid: kuidas ühtne standard ta lihtsalt eitas nende vajaduse. Samamoodi on unustusehõlma vajunud "crakozyabry" – ühtne standard muutis need võimatuks, samuti kaotas vajaduse luua topeltfonte.

Unicode'i arendamine

Loomulikult ei seisa edusammud paigal ja esimesest esitlusest on möödas 25 aastat. Unicode'i kodeering hoiab aga kangekaelselt oma positsiooni maailmas. See sai paljuski võimalikuks tänu sellele, et see sai hõlpsasti juurutatavaks ja levikuks, olles tunnustatud patenteeritud (tasulise) ja avatud lähtekoodiga tarkvara arendajate poolt.

Samas ei tasu eeldada, et täna on meile saadaval sama Unicode'i kodeering, mis veerand sajandit tagasi. Hetkel on selle versioon muutunud versiooniks 5.xx ja kodeeritud märkide arv on kasvanud 231-ni. Loobuti võimalusest kasutada suuremat tähemärkide varu, et säilitada endiselt tugi Unicode-16 (kodeering, kus nende maksimaalne arv oli 216). Alates selle loomisest ja kuni versioonini 2.0.0 on "Unicode Standard" suurendanud selles sisalduvate märkide arvu peaaegu 2 korda. Võimaluste kasv jätkus ka järgnevatel aastatel. Versiooniks 4.0.0 tekkis juba vajadus standardit ennast tõsta, mis ka tehti. Selle tulemusena omandas "Unicode" sellise vormi, nagu me seda täna tunneme.

Mis veel Unicode'is on?

Lisaks tohutule, pidevalt täienevale tähemärkide arvule on sellel veel üks kasulik funktsioon. See on nn normaliseerimine. Selle asemel, et kogu dokumenti tähemärgi haaval läbi kerida ja otsingutabelist vastavad ikoonid asendada, kasutatakse üht olemasolevatest normaliseerimisalgoritmidest. Millest me räägime?

Selle asemel, et raisata arvutiressursse sama tähemärgi regulaarsele kontrollimisele, mis võib olla erinevates tähestikes sarnane, kasutatakse spetsiaalset algoritmi. See võimaldab sarnased märgid asendustabeli eraldi veerus välja võtta ja neile juba viidata ning mitte kõiki andmeid ikka ja jälle uuesti kontrollida.

Välja on töötatud ja rakendatud neli sellist algoritmi. Igas neist toimub transformatsioon rangelt määratletud põhimõtte järgi, mis erineb teistest, mistõttu ei saa ühtki neist kõige tõhusamaks nimetada. Igaüks neist töötati välja konkreetsete vajaduste jaoks, viidi ellu ja kasutati edukalt.

Standardi levitamine

Unicode on oma 25-aastase ajaloo jooksul ilmselt kõige laialdasemalt kasutatav kodeering maailmas. Sellele standardile on kohandatud ka programmid ja veebilehed. Asjaolu, et Unicode'i kasutab tänapäeval enam kui 60% Interneti-ressurssidest, võib rääkida rakenduse laiusest.

Nüüd teate, millal Unicode'i standard ilmus. Mis see on, teate ja oskate hinnata ka Unicode Inc. spetsialistide rühma tehtud leiutise täit tähtsust. üle 25 aasta tagasi.

See sait vajab korrektseks töötamiseks JavaScripti. Palun lubage oma brauseri seadetes JavaScript.

Unicode märgitabel

Näita kõike
Vahemik: 0000-001F: C0 juhtmärgid 0020-007F: põhilised ladina tähed 0080-009F: C1 juhtmärgid 00A0-00FF: ladina-1 lisamärgid 0100-017F: ladina keel laiendatud-A 0180-024F: AF Ladina keel : laiendatud rahvusvaheline foneetiline tähestik 02B0-02FF: mittekombineeritavad laiendatud modifikatsioonimärgid 0300-036F: kombineeritavad diakriitilised tähed 0370-03FF: kreeka ja kopti tähed 0400-04FF: kirillitsa 0500-052F: täiendavad tähemärgid : heebrea 0600-06FF: araabia 0700-074F: süüria 0750-077F: täiendav araabia 0780-07BF: tana (Maldiivid) 07C0-07FF: Nko 0800-083F: samariitlane 0800-083F: samariitlane 0800-083F: samarialane 0800-083 -097F: Devanagari 0980-09FF: bengali 0A00-0A7F: Gurmukhi 0A80-0AFF: gudžarati 0B00-0B7F: oriya 0B80-0BFF: tamili 0C00-0C7F: telugu 0C80-0CFF: kannada 0D00-0D7F: malajalami 0D80-0DFF: singali 0E00-0E7F: tai 0E80-0EFF: lao 0F00-0FFF: tiibeti 1000-109F: Korea 1000-109F: Korea kiri (Gruusia 1:FF0ulhang1:10FF001) -137F: Etioopia silb 1380-139F: Etioopia keele lisamärgid 13A0-13FF: tšeroki kiri 1400-167F: kanada silb 1680-169F: ogham 16A0-16FF: ruunikiri 16A0-16FF: ruunikiri 17A0-17o0-log 17-310-17o-17-10-17-10-17-17-10-17-10-17-10-17-10-17-10-17F-01-17-10-17-10-17-13F-170-13F -175F: Buhid 1760-177F: Tagbanwa 1780-17FF: khmeeri kiri 1800-18AF: vana-mongoolia kiri 18B0-18FF: laiendatud kanada silb 1900-194F: limbu skript 1950-194F: limbu skript 1950-194 tai skript 1950-8-197F 19E0-19FF: khmeeri tähemärgid 1A00-1A1F: bugi kiri (Lontara) 1A20-1AAF: vana Tai Ly kiri (Tai Tham) 1B00-1B7F: Bali kiri 1B80-1 BBF: Sundaani kiri 1BC0-1BFF: Bataki kiri 1C00-1C4F: Lepcha skript (Rong) 1C50-1C7F: Ol Chiki kiri 1CD0-1CFF: Veeda tähed 1D00-1D7F: Foneetilised laiendid 1D80-1D7F: Täiendavad telefonilaiendid 1D80-1DBDF:1: Täiendavad telefoninumbrid kombineeritavad diakriitilised tähised 1E00-1EFF: Ladina laiendatud lisa 1F00-1FFF: kreeka tähemärgid laiendatud 2000-206F: kirjavahemärgid 2070-209F: üla- ja alaindeksid 20A0-20CF: Valuuta sümbolid Tähemärgid 20:F0-sarnased 20:4D0-20critics20:0 märgid 2150-218F: numbrilised vormid 2190-21FF: nooled 2200-22FF: matemaatilised tehtemärgid 2300-23FF: mitmesugused tehnilised märgid 2400-243F: juhtkoodi ikoonid 2440-245F: OCR-i tähemärgid 2440-245F: OCR-i tähed-225-5-225:60-tähed 227-25:60 Ääriste sümbolid 2580-259F: täitesümbolid 25A0-25FF: geomeetrilised kujundid 2600-26FF: mitmesugused sümbolid 27 00-27BF: Dingbats 27C0-27EF: mitmesugused matemaatilised sümbolid-A 27F0-27FF: lisanooled-A 2800-28FF: punktkirjas 2900-297F: lisanooled-B 2980-29FF: muu-BAFF-sümbol0. Operaatorid 2B00-2BFF: Mitmesugused sümbolid ja nooled 2C00-2C5F: Glagoliit 1AB0-1AFF: Kombineeritud diakriitika (laiend A) 1CC0-1CCF: laiendatud sundaani tähemärgikomplekt A9E0-A9FF: Myanmari skript AFFtenacter Komplekt AB30-AB8F: Ladina laiendatud-E AB30-AB6F: Varang-Kshiti AB90-ABBF: Beria Zaghawa skript 2C60-2C7F: Ladina Extended-C 2C80-2CFF: Kopti skript 2D00-2D2F: Täiendav gruusia skript 2Dgh2D7F8D0-fin -2DDF: etioopiline laiendatud märgikomplekt 2DE0-2DFF: laiendatud kirillitsa-A 2E00-2E7F: Täiendavad märgid kirjavahemärgid 2E80-2EFF: täiendavad CJK-märgid 2F00-2FDF: Kangxi märgiklahvid 2FF0-2FFF: tähemärgi kirjeldusmärgid 3000-303F: CJK-märgid ja kirjavahemärgid 3040-309F: Hiragana 30A0-309F: Hiragana 30A0-30FF: 318F: Chamo koos hanguliga 3190-319F: kambunas kasutatavad märgid 31A0-31BF: Bopomofo laiendatud märgistik 31C0-31EF: CJK funktsioonid 31F0-31FF: Katakana foneetilised laiendid 3200-32FF: pesastatud tähed 3200-32FF: pesastatud tähed CJ-JK 3:3 kuud ja 3:3 kuud. Ühilduvusmärgid 3400-4DBF: CJK ühendatud märgid (laiend A) 4DC0-4DFF: I Ching heksagrammid 4E00-9FFF: CJK ühtsed märgid A000-A48F: silbid ja A490-A4CF: radikaalid ja A490-A4CF: radikaalid ja A4Abeet A4D5-0uA4AFhabet A4D5-0u Silbik A640-A69F: Kirillitsa laiendatud-B A6A0-A6FF: Bamum-skript A700-A71F: Tooni muutmise sümbolid A720-A7FF: Ladina laiendatud-D A800-A82F: Siloti Nagri A830-A83F: India numbriline ruut A8: Pii Phagba Lama A880-A8DF: Saurashtra A8E0-A8FF: Devanagari laiendatud märk A900-A92F: Kayah Li A930-A95F: Rejang A960-A97F: Hangul (laiendus A) A980-A9DF: jaava keel A980-A9DF: Javanese A:070-AFAA5 A:0mar (Laiend A) AA80-AADF: tai vieti skript AB00-AB2F: etioopia skript (laiend A) ABC0-ABFF: meitei/manipuri AC00-D7AF: hanguli silbid D800-DB7F: DB80 asenduspaaride ülaosa -DBFF: privaatsete asenduspaaride ülemine osa kasutage asenduspaare DC00-DFFF: asenduspaaride alumine osa E000-F8FF: privaatne kasutusala F900-FAFF: CJK-ga ühilduvad märgid FB00-FB4F: tähestikulised esitusvormid FB50-FDCF: araabia tähe-A esitusvormid FDF0-FDFF: Esitusvormid FE00-FE0F: stiilivariantide valijad FE10-FE1F: vertikaalsed vormid FE20-FE2F: kombineeritavad märkide pooled FE30-FE4F: CJC ühilduvusvormid FE50-FE6F: väikese suurusega variandid FE70-FE FF: araabia tähe-B vormid FF00-FFEF: pool- ja täislaiused vormid FFF0-FFFF: erimärgid

Mis on Unicode?

Unicode(Inglise) Unicode) on universaalne tähemärgikodeeringu standard, mis võimaldab teil esitada tähemärke kõigist maailma keeltest.

Erinevalt ASCII-st on üks märk kodeeritud kahe baidina, mis võimaldab kasutada 65 536 tegelased, vastu 256 .

Nagu teate, on üks bait täisarv alates null enne 255 . Bait omakorda koosneb kaheksa bitid, mis salvestavad arvväärtusi binaarsel kujul, kus iga järgmine praeguse biti ühik on eelmise biti väärtus kaks korda suurem. Seega saab kaks baiti salvestada numbri alates null enne 65 535 , mis võimaldab kasutada 65 536 tähemärki (null + 65 535 , null on samuti arv, see pole mitte midagi).

Unicode-märgid on jagatud osadeks. Esiteks 128 tähemärgid kordavad tabelit ASCII.

Märkide kuvamise eest vastutab kodeeringu perekond. Unicode (Unicode'i teisendusvorming – UTF). Kõige kuulsam ja laialdasemalt kasutatav kodeering on UTF-8.
Kuidas lauda kasutada?

Sümboleid esitatakse 16 tk rea kohta. Ülevalt on näha kuueteistkümnendsüsteem alates 0 enne 16 . Vasakul sarnased numbrid kuueteistkümnendsüsteemis alates 0 enne FFF.
Ühendades vasakpoolse numbri üleval oleva numbriga, saate teada märgi koodi. Näiteks: inglise kiri F asub liinil 004 , veerus 6 : 004 + 6 = märgi kood 0046 .

Siiski võite kursorit lihtsalt üle hõljutada spetsiifiline tegelane tabelis, et leida märgikood. Või klõpsake selle kopeerimiseks sümbolil või selle koodil ühes vormingus.

Otsinguväljale saab sisestada otsingumärksõnu, näiteks: nooled, päike, süda. Või saate määrata märgikoodi mis tahes vormingus, näiteks: 1123, 04BC, چ. Või sümbol ise, kui soovite teada sümboli koodi.

Otsingu järgi märksõnad on praegu väljatöötamisel, mistõttu ei pruugi see tulemusi anda. Kuid palju populaarseid sümboleid võib juba leida.

Uskuge või mitte, aga brauserisse on sisse ehitatud pildivorming. See vorming võimaldab teil pilte alla laadida enne, kui neid vaja läheb, pakub pildi renderdamist tavalisel või võrkkesta ekraanid ja võimaldab lisada css pildid. OK, see pole täiesti tõsi. See ei ole pildiformaat, kuigi kõik muu on endiselt kehtiv. Seda kasutades saate luua eraldusvõimest sõltumatuid ikoone, mille laadimine ei võta aega ja mida saab stiilida kasutades CSS-i.

Mis on Unicode?

Unicode on võimalus erinevate keelte tähti ja kirjavahemärke samal lehel õigesti kuvada. See on uskumatult kasulik: kasutajad saavad teie saidiga töötada kõikjal maailmas ja see näitab, mida soovite – see võib olla prantsuse keel diakriitikaga või Kanji .

Unicode areneb edasi: praegune versioon on 8.0, milles on üle 120 tuhande tähemärgi (2014. aasta alguses avaldatud algses artiklis oli jutt versioonist 6.3 ja 110 tuhandest tähemärgist).

Lisaks tähtedele ja numbritele on Unicode'is ka teisi märke ja ikoone. IN uusimad versioonid need sisaldasid emotikone, mida näete iOS Messengeris.

HTML-lehed luuakse Unicode'i märkide jadast ja teisendatakse võrgu kaudu saatmisel baitideks. Iga keele igal tähel ja sümbolil on oma kordumatu kood ja see kodeeritakse faili salvestamisel.

UTF-8 kodeeringusüsteemi kasutamisel saate Unicode'i tähemärke otse teksti sisestada, kuid võite lisada ka Unicode'i märke tekstile, määrates numbrilise sümboolse lingi. Näiteks on see südame sümbol ja saate seda sümbolit kuvada, lisades lihtsalt märgistusele koodi.

Seda numbrilist viidet saab määrata nii kümnend- kui ka kuueteistkümnendsüsteemis. Kümnendvormingus tuleb algusesse lisada täht x, kirje annab sama südame ( ), mis eelmine valik. (2665 on 9829 kuueteistkümnendsüsteem).

Kui lisate CSS-iga Unicode'i märgi, saate kasutada ainult kuueteistkümnendsüsteemi väärtusi.

Mõnel sagedamini kasutataval Unicode'i märgil on numbrikoodide asemel meeldejäävamad tekstilised nimed või lühendid, näiteks ampersand (& - &). Selliseid sümboleid nimetatakse mnemoonika HTML-is, nende täielik nimekiri on Vikipeedias.

Miks peaksite kasutama Unicode'i?

Hea küsimus, siin on mõned põhjused:

Erinevate keelte õigete märkide kasutamine.
Ikoonide asendamiseks.
@font-face kaudu ühendatud ikoonide asendamiseks.
CSS-i klasside määramiseks

Õiged märgid

Esimene põhjustest ei nõua lisameetmeid. Kui HTML on salvestatud UTF-8 formaadis ja selle kodeering edastatakse üle võrgu UTF-8 kujul, peaks kõik toimima nii nagu peab.

Peab. Kahjuks ei toeta kõik brauserid ja seadmed kõiki Unicode'i märke ühtemoodi (täpsemalt ei toeta kõik fondid täielikku märgikomplekti). Näiteks äsja lisatud emotikonide märke ei toetata kõikjal.

UTF-8 toe jaoks HTML5-s lisage (kui teil pole juurdepääsu serveri sätetele, peaksite ka lisama ). Vana doktüüp kasutab ( ).

Ikoonid

Teine põhjus Unicode'i kasutamiseks on selle olemasolu suur hulk kasulikud sümbolid, mida saab kasutada ikoonidena. Näiteks , ≡ ja .

Nende ilmne eelis on see, et te ei vaja ühtegi täiendavaid faile et need lehele lisada, mis tähendab, et teie sait on kiirem. Samuti saate CSS-i abil muuta nende värvi või lisada varju. Ja üleminekuid lisades (css-i üleminek) saab ilma lisapiltideta sujuvalt muuta ikooni värvi, kui hõljutada selle kohal.

Oletame, et tahan lisada oma lehele tärnidega reitinguindikaatori. Ma saan seda teha nii:

★ ★ ★ ☆ ☆

Saate järgmise tulemuse:

Kuid kui teil pole õnne, näete midagi sellist:

Sama reiting BlackBerry 9000-l

See juhtub siis, kui kasutatavad märgid ei ole brauseri või seadme fontis (õnneks on need tärnid suurepäraselt toetatud ja vana Blackberry telefonid on siin ainsaks erandiks).

Kui Unicode'i märki pole, saab selle asendada tähemärkidega, mis ulatuvad tühjast ruudust (□) kuni küsimärgiga (�) rombini.

Aga kuidas leida Unicode'i märk, mis võiks teie kujunduses kasutamiseks sobida? Saate seda otsida saidilt nagu Unicodinator, vaadates saadaolevaid märke, kuid neid on ka parim viis. - see suurepärane sait võimaldab teil joonistada otsitava ikooni ja seejärel pakub teile sarnaste Unicode'i märkide loendit.

Unicode'i kasutamine @font-face ikoonidega

Kui kasutate ikoone, mis on @font-face kaudu lingitud välise fondiga, saab Unicode'i tähemärke kasutada tagavarana. Nii saate näidata sarnast Unicode'i tähemärki seadmetes või brauserites, kus @font-face ei toetata:

Vasakul on Chrome'is Font Awesome'i ikoonid ja paremal Opera Mini Unicode'i asendusmärgid.

Paljud @font-face sobitamise tööriistad kasutavad Unicode'i märgivahemikku erakasutuse piirkonnast. Selle lähenemisviisi probleem seisneb selles, et kui @font-face ei toetata, edastatakse märgikoodid kasutajale ilma igasuguse tähenduseta.

Suurepärane ikoonikomplektide loomiseks @font-face'is ja võimaldab valida ikooni aluseks sobiva Unicode'i märgi.

Kuid olge ettevaatlik – mõnele brauserile ja seadmele ei meeldi üksikud Unicode'i märgid, kui neid kasutatakse koos @font-face . Unicode'i märgituge on mõttekas kontrollida rakendusega Unify – see rakendus aitab teil kindlaks teha, kui turvaline on @font-face ikoonikomplektis olevate tähemärkide kasutamine.

Unicode'i märkide tugi

Peamine probleem Unicode'i märkide kasutamisel tagavarana on kehv tugi ekraanilugerites (selle kohta leiab jällegi teavet Unifyst), mistõttu on oluline kasutatavaid märke hoolikalt valida.

Kui teie ikoon on vaid dekoratiivne element ekraanilugeja poolt loetava tekstisildi kõrval, ei pea te liigselt muretsema. Kui aga ikoon on omaette, tasub ekraanilugeja kasutajate abistamiseks lisada peidetud tekstisilt. Isegi kui ekraanilugeja loeb Unicode'i tähemärki, on tõenäoline, et see erineb oluliselt ettenähtud otstarbest. Näiteks ≡ (≡) loeb hamburgeriikooni VoiceOver iOS-is identseks.

Unicode CSS-klasside nimedes

Seda, et Unicode’i saab kasutada klassinimedes ja stiililehtedes, on teada juba 2007. aastast. Just siis kirjutas Jonathan Snook Unicode'i märkide kasutamisest abitundides ümarate nurkade paigutamisel. See idee pole palju levitatud, kuid tasub teada Unicode'i kasutamise võimalusest klassinimedes (erimärgid või kirillitsas).

Fondi valik

Vähesed fondid toetavad täielikku Unicode'i märgikomplekti, seega kontrollige fondi valimisel kindlasti soovitud tähemärke.

Segoe UI Symbolis või Arial Unicode MS-is on palju ikoone. Need fondid on saadaval nii arvutis kui ka Macis; Lucida Grandel on ka üsna palju Unicode'i märke. Saate lisada need fondid fondiperekonna deklaratsiooni, et jõustada Unicode'i märkide maksimaalne arv kasutajatele, kellel on need fondid installitud.