Unicode är en internationell teckenkodningsstandard som låter dig konsekvent visa texter på alla datorer i världen, oavsett systemspråk som används på den.

Grunderna

För att förstå varför en Unicode-karaktärstabell behövs, låt oss först titta på mekanismen för att visa text på en bildskärm. Datorn bearbetar, som vi vet, all information i digital form, och den måste matas ut i grafisk form för människans uppfattning. Så för att vi ska läsa den här texten måste vi lösa minst två problem:

• Koda tryckta tecken i digital form.
• Ge operativsystemet möjligheten att matcha digitala former med vektortecken, med andra ord hitta rätt bokstäver.

Första kodningarna

Fädern till alla kodningar anses vara amerikansk ASCII. Den beskrev det latinska alfabetet som används på engelska med skiljetecken och arabiska siffror. Det var 128 tecken som användes i det som blev grunden för efterföljande utvecklingar - de används till och med av den moderna Unicode-karaktärstabellen. Bokstäverna i det latinska alfabetet har sedan dess tagit de första positionerna i någon kodning.

Totalt tillät ASCII att spara 256 tecken, men eftersom de första 128 ockuperades av det latinska alfabetet började de återstående 128 att användas runt om i världen för att skapa nationella standarder. I Ryssland skapades till exempel CP866 och KOI8-R på grundval av detta. Sådana variationer kallades utökade versioner av ASCII.

Kodsidor och "Crack"

Vidareutveckling av teknik och utseendet på ett grafiskt gränssnitt ledde till det faktum att American Standardization Institute skapade ANSI-kodningen. Ryska användare, särskilt med erfarenhet, är dess version känd som Windows 1251. Begreppet "kodsida" användes först i den. Det var med hjälp av kodesidor som innehöll symboler för andra nationella alfabet än latin som ”ömsesidig förståelse” upprättades mellan datorer som användes i olika länder.

Närvaron av ett stort antal olika kodningar som används på ett språk började emellertid orsaka problem. Så kallad krakozyabry dök upp. De härrörde från ett missförhållande mellan källkodssidan där informationen skapades och den kortsida som användes som standard på slutanvändarens dator.

Som exempel är ovanstående kyrilliska kodning CP866 och KOI8-R. Bokstäverna i dem kännetecknades av kodpositioner och placeringsprinciper. I den första var de ordnade i alfabetisk ordning och i den andra i slumpmässig ordning. Du kan föreställa dig vad som hände framför en användares ögon som försökte öppna sådan text utan att ha den nödvändiga kodsidan eller om den var felaktig tolkad av datorn.

Unicode-skapelse

Spredningen av Internet och relaterad teknik, till exempel e-post, har lett till att situationen med textförvrängningen i slutändan upphörde att passa alla. Ledande IT-företag har bildat Unicode Consortium (Unicode Consortium). Karaktärstabellen, som presenterades 1991 under namnet UTF-32, tillät lagring av mer än en miljard unika karaktärer. Detta var ett avgörande steg mot avkodning av texterna.

Den första universella Unicode UTF-32-karaktärstabellen användes dock inte i stor utsträckning. Det främsta skälet var redundansen för lagrad information. Det beräknades snabbt att för länder som använder det latinska alfabetet kodat med den nya universella tabellen kommer texten att ta fyra gånger mer utrymme än när man använder den utökade ASCII-tabellen.

Unicode-utveckling

Följande Unicode UTF-16-karaktärstabell fixade problemet. Kodningen i den utfördes med hälften av antalet bitar, men samtidigt minskade antalet möjliga kombinationer. I stället för miljarder tecken låter det dig spara endast 65 536. Trots det visade det sig vara så framgångsrikt att enligt konsortiets beslut definierades detta nummer som Unicode-baslagringsutrymme.

Trots sådan framgång passade UTF-16 inte alla, eftersom mängden lagrad och överförd information fortfarande fördubblats. Den universella lösningen var UTF-8, en Unicode-karaktärstabell med variabel postlängd. Detta kan kallas ett genombrott på detta område.

Således, med införandet av de två sista standarderna, löst Unicode-karaktärstabellen problemet med ett enda kodutrymme för alla för närvarande använda teckensnitt.

Unicode för ryska

På grund av den variabla längden på koden som används för att visa tecken kodas latin i Unicode på samma sätt som i dess föregångare ASCII, det vill säga en bit. För andra alfabet kan bilden se annorlunda ut. Till exempel använder tecknen i det georgiska alfabetet tre byte för kodning, och tecknen i det kyrilliska alfabetet - två. Allt detta är möjligt inom ramen för att använda UTF-8 Unicode-standarden (symboltabell). Det ryska språket eller det kyrilliska alfabetet har 448 positioner i ett gemensamt kodutrymme, uppdelat i fem block.

Dessa fem block inkluderar det huvudsakliga kyrilliska och kyrkans slaviska alfabetet, samt ytterligare bokstäver i andra språk som använder det kyrilliska alfabetet. Ett antal positioner har tilldelats för att visa gamla former för att representera kyrilliska bokstäver, medan 22 positioner av det totala antalet förblir fria.

Nuvarande Unicode-version

Med lösningen på sin primära uppgift, som var att standardisera teckensnitt och skapa ett enda kodutrymme för dem, stoppade konsortiet inte sitt arbete. Unicode utvecklas och kompletteras ständigt. Den senaste nuvarande versionen av denna standard 9.0 släpptes 2016. Det inkluderade sex ytterligare alfabet och utvidgade listan över standardiserade emojis.

Jag måste säga att för att förenkla forskning läggs även de så kallade döda språken till Unicode. De fick det här namnet eftersom det inte finns några människor för vilka han skulle vara infödd. Denna grupp inkluderar också språk som har överlevt till vår tid endast i form av skriftliga monument.

I princip kan vem som helst ansöka om att lägga till tecken i den nya Unicode-specifikationen. Det är sant att du måste fylla i en anständig mängd källdokument och spendera mycket tid. Ett levande exempel på detta är berättelsen om programmeraren Terence Eden. 2013 ansökte han om inkludering i specifikationen av tecken relaterade till beteckningen av datorkraftkontrollknappar. De har använts i teknisk dokumentation sedan mitten av 70-talet av förra seklet, men tills specifikationen 9.0 dök upp var de inte en del av Unicode.

Karaktärstabell

På varje dator, oavsett vilket operativsystem som används, används en Unicode-karaktärstabell. Hur använder jag dessa tabeller, var hittar du dem och varför de kan vara användbara för en vanlig användare?

I Windows finns symboltabellen i menysektionen Verktyg. I Linux-operativsystemfamiljen finns det vanligtvis i underavsnittet "Standard" och på MacOS i tangentbordets inställningar. Huvudsyftet med denna tabell är att ange tecken i textdokument som inte finns på tangentbordet.

Du kan hitta den bredaste applikationen för sådana tabeller: från att ange tekniska symboler och ikoner för nationella monetära system till att skriva instruktioner för praktisk användning av Tarot-kort.

Avslutningsvis

Unicode används överallt och gick in i våra liv tillsammans med utvecklingen av Internet och mobil teknik. Tack vare dess användning har systemet för interetnisk kommunikation förenklats kraftigt. Vi kan säga att införandet av Unicode är ett avslöjande, men helt osynligt exempel på användningen av teknik för hela mänskligheten.

Idag pratar vi med dig om var krakozyabra kommer från på webbplatsen och i programmen, vilka textkodningar som finns och vilka av dem som ska användas. Vi tittar närmare på historien för deras utveckling, med utgångspunkt från den grundläggande ASCII, liksom dess utökade versioner CP866, KOI8-R, Windows 1251 och slutar med moderna Unicode UTF 16 och 8 kodningar.

• Utökade Asuka-versioner - CP866 och KOI8-R-kodningar
• Windows 1251 - ASCII-variation och varför crabbeats kryper ut

För vissa kan denna information tyckas överflödig, men du skulle veta hur många frågor som kom till mig om den genomsökta krakozyabry (en oläslig karaktärsuppsättning). Nu kommer jag att ha möjlighet att skicka alla till texten i den här artikeln och självständigt söka efter sina jambs. Tja, gör dig redo att ta upp informationen och försök följa historiens gång.

ASCII - grundläggande textkodning för latin

Utvecklingen av textkodningar skedde samtidigt med bildandet av IT-branschen, och under denna tid lyckades de genomgå en hel del förändringar. Historiskt började det hela med det ganska inkonsekventa EBCDIC-uttalet på ryska, som gjorde det möjligt för dig att koda latinska bokstäver, arabiska siffror och skiljetecken med kontrolltecken. Men ändå bör utgångspunkten för utvecklingen av moderna textkodningar betraktas som den berömda ASCII (Amerikansk standardkod för informationsutbyte, som på ryska vanligtvis uttalas som ”Asuka”). Den beskriver de första 128 tecknen i de mest använda av engelsktalande användare - latinska bokstäver, arabiska siffror och skiljetecken. Förutom dessa 128 tecken som beskrivs i ASCII, är några hjälpkaraktärer som parenteser, trellises, asterisker etc. Egentligen kan du själv se dem:
Det är dessa 128 tecken från den ursprungliga versionen av ASCII som har blivit standarden, och i någon annan kodning kommer du definitivt att möta dem och de kommer att stå i den ordningen. Men faktum är att med hjälp av en byte med information är det möjligt att koda inte 128, utan så många som 256 olika värden (en två i kraften på åtta är lika med 256), så efter basversionen av Asuka dök en hel serie upp utökade ASCII-kodningar, där det förutom 128 grundläggande tecken var möjligt att koda karaktärerna i den nationella kodningen (till exempel ryska). Här är det förmodligen värt att säga lite mer om nummersystemen som används i beskrivningen. För det första, som ni alla vet, fungerar en dator bara med siffror i det binära systemet, nämligen med nollor och sådana ("Boolean algebra," om någon var på college eller skola). En byte består av åtta bitar, som var och en är en två i kraft, börjar från noll, och till en två i det sjunde:
  Det är inte svårt att förstå att det endast kan finnas 256 av alla möjliga kombinationer av nollor och sådana i en sådan konstruktion. Att konvertera ett tal från binär till decimal är ganska enkelt. Du behöver bara lägga till alla grader av deus som de står över. I vårt exempel visar det sig vara 1 (2 till kraften i noll) plus 8 (två till kraften i 3), plus 32 (två i den femte kraften), plus 64 (i den sjätte kraften), plus 128 (i den sjunde kraften). Totalt blir 233 i decimal. Som ni ser är allt mycket enkelt. Men om du tittar på tabellen med ASCII-tecken ser du att de presenteras i hexadecimal kodning. Till exempel motsvarar en asterisk i Askey det hexadecimala antalet 2A. Du vet förmodligen att i den hexadecimala notationen, förutom arabiska siffror, används också latinska bokstäver, från A (betyder tio) till F (betyder femton). Tja, för konvertera binärt till hexadecimalt tillgripa följande enkla och intuitiva sätt. Varje byte av information är indelad i två delar av fyra bitar, som visas i bildskärmen ovan. sålunda i varje hälft av byten kan binär kod endast koda sexton värden (två till fjärde graden), vilket lätt kan representeras som ett hexadecimalt tal. Dessutom måste graderna i den vänstra halvan av byten räknas igen med början från noll och inte som visas på skärmdumpen. Som ett resultat får vi genom enkla beräkningar att numret E9 är kodat i skärmdumpen. Jag hoppas att min resonemang och lösningen på denna rebus var tydlig för dig. Nåväl, nu fortsätter vi faktiskt att prata om textkodningar.

Utökade versioner av Asuka - CP866 och KOI8-R-kodningar med pseudografik

Så vi började prata om ASCII, som var en slags utgångspunkt för utvecklingen av alla moderna kodningar (Windows 1251, Unicode, UTF 8). Ursprungligen innehöll den bara 128 tecken i det latinska alfabetet, arabiska siffror och något annat, men i den avancerade versionen blev det möjligt att använda alla 256 värden som kan kodas i en byte information. dvs Nu kan du lägga till bokstäver i ditt språk till Askey. Här måste du bli distraherad en gång till för att klargöra - varför behöver vi textkodningar och varför det är så viktigt. Symboler på skärmen på din dator bildas på grundval av två saker - uppsättningar av vektorformer (representationer) av alla typer av tecken (de finns i filer med teckensnitt som är installerade på din dator) och koden som låter dig dra ut från denna uppsättning vektorformer (teckensnittfil) tecken som ska infogas på rätt plats. Det är tydligt att teckensnitt är ansvariga för själva vektorformerna, men operativsystemet och programmen som används i det ansvarar för kodningen. dvs valfri text på din dator kommer att vara en uppsättning byte, i vilka var och en av dessa tecken är kodad. Programmet som visar den här texten på skärmen (textredigerare, webbläsare, etc.) läser kodningen för nästa tecken när den analyserar koden och söker efter motsvarande vektorform i önskad teckensnittsfil som är ansluten för att visa detta textdokument. Allt är enkelt och vanligt. Detta innebär att för att koda vilket tecken vi behöver (till exempel från det nationella alfabetet) måste två villkor uppfyllas - vektorns form av detta tecken måste vara i det teckensnitt som används och detta tecken kan kodas i utökade ASCII-kodningar i en byte. Därför finns det en hel massa sådana alternativ. Endast för kodning av symbolerna i det ryska språket finns det flera sorter av utökad Asuka. Till exempel visades ursprungligen CP866, där det var möjligt att använda symbolerna i det ryska alfabetet och det var en utökad version av ASCII. dvs dess övre del sammanföll fullständigt med basversionen av Asuka (128 latinska tecken, siffror och till och med någon skit), som presenteras i skärmdumpen ovan, men den nedre delen av tabellen med CP866-kodning hade den vy som anges i skärmdumpen nedan och tillät kodning av ytterligare 128 tecken (ryska bokstäver och alla pseudografier där):
  Du ser, i den högra kolumnen börjar siffrorna med 8, för siffrorna från 0 till 7 hänvisar till basdelen av ASCII (se den första skärmdumpen). sålunda den ryska bokstaven "M" i CP866 kommer att ha koden 9C (den är placerad i skärningspunkten mellan motsvarande rad med 9 och kolumnen med siffran C i det hexadecimala talsystemet), som kan skrivas i en byte med information, och om det finns ett lämpligt teckensnitt med ryska tecken, kommer denna bokstav utan problem kommer att visas i texten. Var kom detta belopp ifrån pseudografik i CP866? Saken är att denna kodning för den ryska texten utvecklades redan under de håriga åren då det inte fanns någon sådan spridning av grafiska operativsystem som det är nu. Och i Dos och liknande textbaserade operativsystem gjorde pseudografik det möjligt att på något sätt diversifiera utformningen av texter, och därför överflödar CP866 och alla dess samtida från kategorin utvidgade versioner av Asuka. CP866 distribuerades av IBM, men dessutom utvecklades ett antal kodningar för ryska språkkaraktärer, till exempel kan samma typ (utökad ASCII) tillskrivas KOI8-R:
Principen för dess drift förblir densamma som CP866 som beskrivs lite tidigare - varje tecken i texten är kodad med en enda byte. Skärmdumpen visar den andra halvan av KOI8-R-tabellen, som den första halvan överensstämmer helt med basen Asuka, som visas i den första skärmdumpen i denna artikel. Bland funktionerna i KOI8-R-kodningen kan det noteras att de ryska bokstäverna i tabellen inte går i alfabetisk ordning, som till exempel gjordes i CP866. Om du tittar på det allra första skärmdumpet (basdelen, som ingår i alla avancerade kodningar), kommer du att märka att ryska bokstäver i KOI8-R finns i samma celler i tabellen som bokstäverna i det latinska alfabetet stämmer med det från den första delen av tabellen. Detta gjordes för att underlätta övergången från ryska till latinska tecken genom att bara kasta en bit (två till den sjunde makten eller 128).

Windows 1251 - den moderna versionen av ASCII och varför crabbeats kommer ut

Vidareutveckling av textkodningar berodde på att grafiska operativsystem fick popularitet och behovet av att använda pseudografier i dem försvann med tiden. Som ett resultat uppstod en hel grupp, som i allt väsentligt var utökade versioner av Asuka (en karaktär i texten är kodad med bara en byte information), men utan användning av pseudo-grafiska tecken. De tillhörde de så kallade ANSI-kodningarna, som utvecklades av American Institute of Standardization. I vanligt parlance användes namnet kyrilliskt också för varianten med stöd av det ryska språket. Ett exempel på detta är Windows 1251. Det jämförs positivt med den tidigare använda CP866 och KOI8-R genom att platsen för de pseudografiska symbolerna i den togs av de saknade symbolerna i rysk typografi (förutom accentmärket), liksom symbolerna som används på slaviska språk nära ryska (ukrainska, vitryska, etc.) ):
På grund av ett sådant överflöd av ryska språkkodningar hade fonttillverkare och mjukvarutillverkare ständigt huvudvärk, och vi, kära läsare, fick ofta samma ökända krakozyabrynär det var förvirring med den version som används i texten. Mycket ofta kröp de ut när de skickade och tog emot meddelanden via e-post, vilket ledde till skapandet av mycket komplexa konverteringstabeller, som faktiskt inte kunde lösa detta problem, och ofta använde användare latinska bokstäver för korrespondens för att undvika den ökända krakozyabra användningen av ryska kodningar som CP866, KOI8-R eller Windows 1251. Faktum är att krakozyabry som klättrade ut istället för den ryska texten var resultatet av felaktig användning av kodningen för detta språk, vilket inte motsvarar ala den där den ursprungligen kodat textmeddelande. Antag att om du försöker visa tecken kodade med CP866 med kodtabellen Windows 1251, kommer samma krakozyabras (en meningslös uppsättning tecken) att komma ut och ersätta meddelandetexten helt. En liknande situation inträffar ofta när man skapar och konfigurerar webbplatser, forum eller bloggar, när text med ryska karaktärer felaktigt sparas i fel kodning som används på webbplatsen som standard, eller i fel textredigerare som lägger till en osynlig gag till koden med blotta ögat. I slutändan var en sådan situation med många kodningar och ständigt genomsökning av krakozyabras irriterande för många, det fanns förutsättningar för att skapa en ny universell variation som skulle ersätta alla befintliga och slutligen lösa problemet till roten med utseende av oläsliga texter. Dessutom var det ett problem med språk som kinesiska, där det fanns mycket fler språkkaraktärer än 256.

Unicode (Unicode) - universella kodningar UTF 8, 16 och 32

Dessa tusentals tecken i språkgruppen i Sydostasien kunde inte beskrivas i en byte med information som tilldelades för teckenkodning i utökade versioner av ASCII. Resultatet blev ett konsortium som heter Unicode  (Unicode - Unicode Consortium) i samarbete med många ledare inom IT-branschen (de som producerar mjukvara, som kodar hårdvara, som skapar teckensnitt) som var intresserade av uppkomsten av en universell textkodning. Den första variationen som släpptes under regi av Unicode-konsortiet var Utf 32. Siffran i kodningsnamnet betyder antalet bitar som används för att koda ett tecken. 32 bitar utgör 4 byte information som kommer att behövas för att koda ett enda tecken i den nya universella UTF-kodningen. Som ett resultat kommer samma textfil som är kodad i den utökade versionen av ASCII och i UTF-32, i det senare fallet att ha en storlek (vikt) fyra gånger den. Det här är dåligt, men nu har vi möjlighet att koda med UTF antalet tecken lika med två i trettio sekunder grad ( miljarder teckensom täcker alla verkligt nödvändiga värden med en enorm marginal). Men många länder med den europeiska gruppens språk behövde inte använda ett så stort antal tecken i kodningen, men när de använder UTF-32, skulle de aldrig få en fyrfaldig ökning i vikten av textdokument, och som ett resultat, en ökning av Internettrafiken och volymen lagrade data. Det här är mycket, och ingen hade råd med sådana slösa. Som ett resultat av utvecklingen av Unicode dök upp UTF-16, som visade sig vara så framgångsrikt att det som standard accepterades som basutrymme för alla tecken som vi använder. Den använder två byte för att koda ett tecken. Låt oss se hur den här saken ser ut. I operativsystemet Windows kan du följa sökvägen "Start" - "Program" - "Standard" - "Verktyg" - "Karaktärstabell". Som ett resultat öppnas en tabell med vektorformer för alla teckensnitt installerade i ditt system. Om du väljer Unicode-teckenuppsättningen i Avancerade alternativ, kan du se för varje teckensnitt individuellt hela utbudet av tecken som ingår i det. Förresten, genom att klicka på någon av dem, kan du se dess dubbelbyte uTF-16-kodbestående av fyra hexadecimala siffror: Hur många tecken kan kodas i UTF-16 med 16 bitar? 65 536 (två till makten på sexton), och det var detta nummer som togs som basutrymmet i Unicode. Dessutom finns det sätt att koda med det cirka två miljoner tecken, men begränsat till ett utökat utrymme på en miljon tecken i texten. Men till och med den framgångsrika versionen av Unicode-kodningen gav inte mycket tillfredsställelse för dem som skrev till exempel bara program på engelska, eftersom efter att ha flyttat från den utökade versionen av ASCII till UTF-16 fördubblades dokumentens vikt (en byte per en karaktär i Askey och två byte för samma tecken i UTF-16). Det var det, för att tillfredsställa alla och allt i Unicode-konsortiet, beslutades det komma med en kodning  variabel längd. Hon kallades UTF-8. Trots siffran åtta i titeln har den verkligen en variabel längd, dvs. varje karaktär i texten kan kodas i en sekvens med en till sex byte i längd. I praktiken använder UTF-8 bara ett intervall från en till fyra byte, för utöver fyra byte med kod är det redan teoretiskt omöjligt att föreställa sig något. Alla latinska tecken i den är kodade i en byte såväl som i den gamla gamla ASCII. Vad som är anmärkningsvärt, när det gäller att bara koda latinska bokstäver, kommer även de program som inte förstår Unicode att läsa vad som är kodat i UTF-8. dvs Asukas bas flyttade helt enkelt in i detta hjärnsköld till Unicode-konsortiet. Kyrilliska tecken i UTF-8 kodas i två byte, och till exempel georgiska tecken i tre byte. Unicode Consortium, efter att ha skapat UTF 16 och 8, löst det största problemet - nu har vi det teckensnitt det finns ett enda kodutrymme. Och nu kan deras producenter bara fylla i med sin styrka och kapacitet att fylla det med vektorformer av texttecken. I ”Karaktärstabellen” precis ovan ser man att olika teckensnitt stöder ett annat antal tecken. Vissa Unicode-rika teckensnitt kan väga mycket anständigt. Men nu skiljer de sig inte i det faktum att de skapades för olika kodningar, utan i det faktum att teckensnittstillverkaren fyllde eller inte fyllde det enda kodutrymmet med en eller annan vektorform till slutet.

Krakozyabra istället för ryska bokstäver - hur man fixar

Låt oss nu titta på hur skurkarna ser ut istället för texten, eller med andra ord, hur rätt kodning för den ryska texten är vald. Egentligen är det inställt i programmet där du skapar eller redigerar just denna text, eller koden med textfragment. För att redigera och skapa textfiler använder jag personligen det mycket bra, enligt min mening, Html- och PHP-editor Notepad ++. Det kan emellertid markera syntaxen för hundra programmerings- och markeringsspråk och har också möjligheten att expandera med plugins. Läs en detaljerad recension av det här fantastiska programmet på länken. I toppmenyn för Notepad ++ finns ett objekt "Kodningar", där du har möjlighet att konvertera en befintlig version till den som används som standard på din webbplats:
När det gäller en webbplats på Joomla 1.5 och högre, såväl som för en blogg på WordPress, bör du välja alternativet för att undvika skurkens utseende UTF 8 utan BOM. Och vad är BOM-prefixet? Faktum är att när de utvecklade UTF-16-kodningen, beslutade de av någon anledning att fästa till det så att förmågan att spela in teckenkoden, både i direkt sekvens (till exempel 0A15) och i omvänd (150A). Och för att programmen ska förstå i vilken sekvens de ska läsa koderna uppfanns det BOM  (Byte Order Mark, eller med andra ord signatur), som uttrycktes genom att lägga till ytterligare tre byte till början av dokumenten. I UTF-8-kodningen fanns inga BOM: er i Unicode-konsortiet, och därför lägger man till vissa program från att läsa koden genom att lägga till program (samma samma ökända tre byte i början av dokumentet). Därför bör vi alltid spara alternativet utan BOM (utan signatur) när vi sparar filer i UTF. Så du går vidare skydda dig från att krypa ut. Det som är anmärkningsvärt, vissa program i Windows vet inte hur man gör detta (de vet inte hur man sparar text i UTF-8 utan BOM), till exempel samma beryktade Windows-anteckningar. Det sparar dokumentet i UTF-8, men det lägger fortfarande till en signatur (tre ytterligare byte) till dess början. Dessutom är dessa byte alltid desamma - för att läsa koden i direkt sekvens. Men på servrarna, på grund av denna bagatell, kan ett problem uppstå - krakozyabry kommer ut. Därför inte i något fall använd inte Windows anteckningsblock för att redigera dokumenten på din webbplats om du inte vill att krakozyabry ska se ut. Det bästa och enklaste alternativet anser jag att den redan nämnda redaktören Notepad ++ har praktiskt taget inga brister och består av bara fördelar. När du väljer en kodning i Notepad ++ har du möjlighet att konvertera text till UCS-2-kodning, som i dess väsentlighet är mycket nära Unicode-standarden. I Notepad kommer det också att vara möjligt att koda text i ANSI, dvs. i relation till det ryska språket kommer det redan att beskrivas av oss strax ovanför Windows 1251. Var kommer den här informationen från? Det är registrerat i registret för ditt Windows-operativsystem - vilken kodning du ska välja för ANSI, vilket du ska välja för OEM (för det ryska språket kommer det att vara CP866). Om du installerar ett annat standardspråk på din dator kommer dessa kodningar att ersättas av samma från ANSI- eller OEM-kategorin för samma språk. När du har sparat dokumentet i den kodning du behöver i Notepad ++ eller öppnat dokumentet från webbplatsen för redigering kan du se dess namn i det nedre högra hörnet av redigeraren: För att undvika gibberish, utöver de åtgärder som beskrivs ovan, kommer det att vara användbart att skriva i sin rubrik källkoden för alla sidor på webbplatsinformationen om denna kodning så att det inte finns någon förvirring på servern eller den lokala värden. I allmänhet använder alla hypertextmarkeringsspråk förutom Html en speciell xml-deklaration som anger kodning av texten.< ? xml version= "1.0" encoding= "windows-1251" ? >   Innan webbläsaren börjar analysera, kommer webbläsaren att ta reda på vilken version som används och hur man tolkar karaktärskoderna på detta språk. Men det som är anmärkningsvärt, om du sparar dokumentet i standard Unicode, kan denna xml-deklaration utelämnas (kodningen kommer att betraktas som UTF-8 om det inte finns någon BOM eller UTF-16 om det finns en BOM). För ett Html-dokument används kodningen för att ange kodningen meta-element, som skrivs mellan öppnings- och stängningshuvudtaggarna: < head> . . . < meta charset= "utf-8" > . . . < / head>   Den här posten är helt annorlunda än den som antogs i standarden i Html 4.01, men uppfyller helt den nya Html 5-standarden, som implementeras långsamt och kommer att förstås fullständigt av alla webbläsare som för närvarande används. I teorin kommer ett Meta-element med en indikation på kodningen av Html-dokumentet att placeras bättre så högt som möjligt i dokumenthuvudetså att vid tidpunkten för mötet i texten till det första tecknet inte från den grundläggande ANSI (som kommer att läsas korrekt alltid och i alla variationer), bör webbläsaren redan ha information om hur man tolkar koderna för dessa tecken. Länk till det första

Unicode är en mycket stor och komplex värld, eftersom standarden låter dig representera och arbeta på en dator med alla grundläggande skrivsystem i världen. Vissa skrivsystem har funnits i mer än tusen år, och många av dem har utvecklats nästan oberoende av varandra i olika delar av världen. Människor har kommit med så många saker och det är ofta så till skillnad från varandra att det var en extremt svår och ambitiös uppgift att kombinera allt detta till en enda standard.

För att verkligen hantera Unicode måste du åtminstone ha en ytlig förståelse för funktionerna i alla skrivsystem som standarden tillåter dig att arbeta med. Men är det vad varje utvecklare behöver? Vi kommer att säga nej. För att använda Unicode i de flesta vardagliga uppgifter räcker det att ha ett rimligt minimum av information och sedan gå djupare in i standarden efter behov.

I den här artikeln kommer vi att prata om de grundläggande principerna för Unicode och lyfta fram de viktiga praktiska frågor som utvecklarna säkert kommer att stöta på i sitt dagliga arbete.

Varför behövde du Unicode?

Innan Unicode användes enkebytkodningar nästan universellt, där gränsen mellan karaktärerna själva, deras representation i datorns minne och skärmen på skärmen var ganska godtycklig. Om du arbetade med ett eller annat nationellt språk installerades de lämpliga kodningsteckensnitten på ditt system, vilket gjorde det möjligt att dra byte från disken på skärmen på ett sådant sätt att de var vettiga för användaren.

Om du skrev ut en textfil på en skrivare och såg en uppsättning med oklara skurkar på en papperssida, innebar detta att motsvarande teckensnitt inte laddades i utskriftsenheten och det tolkade byte annorlunda än hur du vill ha det.

Detta tillvägagångssätt som en helhet och en-byte-kodning hade i synnerhet ett antal betydande nackdelar:

1. Det var möjligt att arbeta med endast 256 tecken åt gången, de första 128 var reserverade för latinska och kontrolltecken, och under andra hälften, utöver det nationella alfabetet, var det nödvändigt att hitta en plats för pseudo-grafiska tecken (╔ ╗).
2. Teckensnitt var bundna till en specifik kodning.
3. Varje kodning representerade sin egen teckenuppsättning och konvertering från en till en annan var endast möjlig med partiella förluster när saknade tecken ersattes med grafiskt liknande.
4. Att överföra filer mellan enheter som kör olika operativsystem var svårt. Det var nödvändigt antingen att ha ett konverteringsprogram eller att ha ytterligare typsnitt tillsammans med filen. Existensen av Internet som vi känner till var omöjligt.
5. Icke-alfabetiska skrivningssystem (hieroglyfiska skrifter) finns i världen, som i princip inte kan representeras vid kodning av enbyte.

Unicode Fundamentals

Vi förstår alla perfekt att datorn inte känner till några ideala enheter utan fungerar med bitar och byte. Men datorsystem skapas fortfarande av människor, inte maskiner, och det är ibland bekvämare för dig och mig att arbeta med spekulativa begrepp och sedan gå vidare från abstrakt till konkret.

Viktigt!En av de centrala principerna i Unicode-filosofin är en tydlig åtskillnad mellan symboler, deras representation på en dator och deras display på en utgångsenhet.

Begreppet en abstrakt Unicode-symbol introduceras, som exklusivt finns i form av ett spekulativt begrepp och ett avtal mellan människor, fastställt av standarden. Varje Unicode-karaktär är associerat med ett icke-negativt heltal som kallas kodpunkten.

Så till exempel är Unicode-karaktären U + 041F det huvudsakliga kyrilliska bokstaven P. Det finns flera sätt att representera detta tecken i datorns minne, precis som flera tusen sätt att visa det på skärmen. Men samtidigt kommer P att vara P eller U + 041F också i Afrika.

Detta är en välkänd inkapsling eller separering av gränssnittet från implementeringen - ett koncept som har bevisat sig i programmering.

Det visar sig att, med hjälp av standarden, kan valfri text kodas som en sekvens av Unicode-tecken

Hej U + 041F U + 0440 U + 0438 U + 0432 U + 0435 U + 0442

skriva på ett papper, packa det i ett kuvert och skicka det till valfri ände på jorden. Om de vet om existensen av Unicode, kommer texten att accepteras av dem på exakt samma sätt som du och jag. De kommer inte att ha det minsta tvivel om att den näst sista karaktären är exakt den kyrilliska gemener e  (U + 0435) snarare än att säga latin liten e  (U + 0065). Observera att vi inte sa ett ord om bytepresentationen.

Unicode-kodutrymme

Unicode-kodutrymmet består av 1 114,112 kodpositioner i intervallet 0 till 10FFFF. Av dessa tilldelas endast 128 237 värden till den nionde versionen av standarden. En del av utrymmet är reserverat för privat bruk och Unicode-konsortiet lovar att aldrig tilldela värden till positioner från dessa specialområden.

För enkelhets skull är hela utrymmet indelat i 17 plan (sex av dem är nu involverade). Fram till nyligen var det vanligt att säga att du troligtvis bara kommer att behöva ta itu med det grundläggande flerspråkiga planet (Basic Multilingual Plane, BMP), som inkluderar Unicode-tecken från U + 0000 till U + FFFF. (Ser lite framåt: tecken från BMP representeras i UTF-16 av två byte, inte fyra). 2016 är denna avhandling redan i tvivel. Till exempel kan populära Emoji-tecken mycket väl visas i ett användarmeddelande och du måste kunna hantera dem korrekt.

kodningar

Om vi \u200b\u200bvill skicka text över Internet måste vi koda en sekvens med Unicode-tecken som en sekvens av byte.

Unicode-standarden innehåller en beskrivning av ett antal Unicode-kodningar, såsom UTF-8 och UTF-16BE / UTF-16LE, som låter dig koda hela utrymmet för kodpositioner. Konvertering mellan dessa kodningar kan fritt utföras utan förlust av information.

Dessutom avbröt ingen kodning av enbyte, men de låter dig koda din individuella och mycket smala bit av Unicode-spektrumet - 256 eller färre kodpositioner. För sådana kodningar finns tabeller och är tillgängliga för alla händelser, där varje värde för en enda byte är associerad med ett Unicode-tecken (se till exempel CP1251.TXT). Trots begränsningarna visar kodningar med en byte vara mycket praktiska när det gäller att arbeta med ett stort antal monolingual textinformation.

Av Unicode-kodningarna är den vanligaste på Internet UTF-8 (den vann handflatan 2008), främst på grund av dess kostnadseffektivitet och transparenta kompatibilitet med sju-bitars ASCII. Latin och servicetecken, grundläggande skiljetecken och siffror - dvs alla sju-bitars ASCII-tecken är kodade i UTF-8 med en byte, samma som i ASCII. Symboler för många grundläggande skript, förutom några mer sällsynta hieroglyfiska tecken, representeras i det av två eller tre byte. Den största av standardkodpositionerna - 10FFFF - är kodad i fyra byte.

Observera att UTF-8 är en variabel längdkodning. Varje Unicode-karaktär i den representeras av en sekvens av kodkvanta med en minsta längd på ett kvantum. Siffran 8 betyder kodenhetens bitlängd - 8 bitar. För UTF-16-kodningsfamiljen är kodkvantstorleken 16 bitar. För UTF-32, 32 bitar.

Om du skickar en HTML-sida med kyrillisk text över nätverket kan UTF-8 ge en mycket konkret förstärkning, eftersom all markering, såväl som JavaScript och CSS-block, kommer att kodas effektivt i en byte. Till exempel är startsidan för Habr i UTF-8 139Kb, och i UTF-16 är den redan 256Kb. Som jämförelse, om du använder win-1251 med förlusten av förmågan att spara vissa tecken, kommer storleken att minska med endast 11 kb.

För att lagra stränginformation i applikationer används 16-bitars Unicode-kodningar ofta på grund av deras enkelhet, liksom det faktum att karaktärerna i huvudvärldsskrivsystemen är kodade med en sexton-bitars kvantitet. Så till exempel använder Java framgångsrikt UTF-16 för internrepresentation av strängar. Windows-operativsystemet i sig själv använder också UTF-16.

I vilket fall som helst, medan vi förblir i Unicode-utrymmet, är det inte så viktigt hur stränginformationen lagras i en separat applikation. Om det interna lagringsformatet tillåter dig att korrekt koda alla miljoner eller fler kodpositioner vid applikationsgränsen, till exempel när du läser från en fil eller kopierar till urklippet, finns det ingen förlust av information, då är allt bra.

För korrekt tolkning av text som läses från en disk eller från ett nätverkskontakt måste du först bestämma dess kodning. Detta görs antingen med hjälp av metainformation som tillhandahålls av användaren, inspelad i eller bredvid texten eller bestämd heuristiskt.

I den torra återstoden

Det finns mycket information och det är vettigt att ge en kort pressning av allt som skrivits ovan:

• Unicode postulerar en tydlig åtskillnad mellan tecken, deras representation på datorn och deras skärm på utgångsenheten.
• Unicode-kodutrymmet består av 1 114,112 kodpositioner i intervallet 0 till 10FFFF.
• Det grundläggande flerspråkiga planet inkluderar Unicode-tecken från U + 0000 till U + FFFF, som kodas i UTF-16 av två byte.
• Varje Unicode-kodning låter dig koda hela utrymmet för Unicode-kodpositioner och konvertering mellan olika sådana kodningar utförs utan förlust av information.
• Enbyte-kodning låter dig koda bara en liten del av Unicode-spektrumet, men kan vara användbart när du arbetar med en stor mängd enspråkig information.
• UTF-8- och UTF-16-kodningarna har en variabel kodlängd. I UTF-8 kan varje Unicode-tecken kodas i en, två, tre eller fyra byte. I UTF-16, två eller fyra byte.
• Det interna formatet för att lagra textinformation i en separat applikation kan vara godtyckligt under förutsättning att det fungerar korrekt med hela utrymmet för Unicode-kodpositioner och det går inte att förlora under gränsöverskridande dataöverföring.

En kort anteckning om kodning

Det kan vara viss förvirring med termen kodning. Inom Unicode sker kodningen två gånger. Första gången en Unicode-teckenuppsättning kodas, i den meningen att varje Unicode-tecken tilldelas en kodposition. Som en del av denna process omvandlas Unicode-teckenuppsättningen till en kodad teckenuppsättning. Andra gången konverteras en sekvens med Unicode-tecken till en byte-sträng och denna process kallas också kodning.

I engelska terminologin finns det två olika verb, att koda och att koda, men även modersmål är ofta förvirrade. Dessutom används termen teckenuppsättning eller charset som en synonym för termen kodad teckenuppsättning.

Allt detta säger vi att det är vettigt att uppmärksamma kontexten och skilja mellan situationer när det gäller kodpositionen för en abstrakt Unicode-symbol och när det gäller dess bytepresentation.

Avslutningsvis

Det finns så många olika aspekter på Unicode att det är omöjligt att täcka allt i en artikel. Ja, och onödigt. Ovanstående information är tillräckligt för att inte bli förvirrad i de grundläggande principerna och arbeta med text i de flesta dagliga uppgifter (läs: utan att gå längre än BMP). I följande artiklar kommer vi att prata om normalisering, ge en mer fullständig historisk översikt över utvecklingen av kodningar, prata om problemen med ryskspråkiga Unicode-terminologier, och också göra material om de praktiska aspekterna av att använda UTF-8 och UTF-16.

Unicode: UTF-8, UTF-16, UTF-32.

Unicode är en uppsättning grafiska tecken och en metod för att koda dem för datorbehandling av textdata.

Unicode tilldelar inte bara en unik kod till varje tecken, utan definierar också olika karaktärsdrag för detta tecken, till exempel:

karaktärstyp (versaler, små bokstäver, siffror, skiljetecken, etc.);

symbolattribut (visning från vänster till höger eller från höger till vänster, utrymme, radbrytning, etc.);

motsvarande stora eller små bokstäver (för gemener och versaler);

motsvarande numeriskt värde (för digitala tecken).

standarder UTF  (förkortning Unicode Transformation Format) för att representera tecken:

UTF-16: Vid Windows-inställning, acceleration, ofta Vista-frågor används UTF-16-kodning för att representera alla Unicode-tecken. I UTF-16 representeras tecken av två byte (16 bitar). Denna kodning används i Windows, eftersom 16-bitarsvärden kan representera de tecken som utgör alfabeten i de flesta språk i världen, vilket gör att program kan bearbeta strängar snabbare och beräkna deras längd. 16 bitar räcker emellertid inte för att representera alfabetstecken på vissa språk. I sådana fall stöder UTE-16 "surrogat" -kodningar, vilket gör att tecken kan kodas med 32 bitar (4 byte). Det finns dock få applikationer som måste ta itu med tecknen på sådana språk, så UTF-16 är en bra kompromiss mellan att spara minne och enkel programmering. Observera att i .NET Framework kodas alla tecken med UTF-16, så att använda UTF-16 i Windows-applikationer förbättrar prestanda och minskar minnesförbrukningen vid överföring av strängar mellan inbyggd och hanterad kod.

UTF-8: I UTF-8-kodning kan olika tecken representeras av 1,2,3 eller 4 byte. Tecken med värden mindre än 0x0080 komprimeras till 1 byte, vilket är mycket bekvämt för tecken som används i USA. Tecken som motsvarar värden från intervallet 0x0080-0x07FF konverteras till 2-byte värden, vilket fungerar bra med alfabet i europeiska och Mellanösterns språk. Tecken med högre värden konverteras till 3-byte-värden, bekvämt när du arbetar med centralasiatiska språk. Slutligen spelas "surrogat" -par in i 4-byte-format. UTF-8 är en extremt populär kodning. Dock är dess effektivitet lägre jämfört med UTF-16, om tecken med värden 0x0800 och högre ofta används.

UTF-32: I UTF-32 representeras alla tecken av 4 byte. Denna kodning är bekväm för att skriva enkla algoritmer för att räkna upp tecken på vilket språk som helst som inte kräver bearbetning av tecken representerade av ett annat antal byte. När du till exempel använder UTF-32 kan du glömma "surrogat", eftersom alla tecken i denna kodning representeras av 4 byte. Det är uppenbart att vad gäller minnesanvändning är effektiviteten hos UTF-32 långt ifrån idealisk. Därför används denna kodning sällan för att överföra strängar över nätverket och spara dem i filer. Som regel används UTF-32 som ett internt format för att representera data i ett program.

UTF-8

I en snar framtid kallas ett speciellt Unicode-format (och ISO 10646) UTF-8. Denna "derivat" -kodning används för att skriva tecken efter kedjor av byte i olika längder (från en till sex), som omvandlas till Unicode-koder med en enkel algoritm, med kortare kedjor som motsvarar mer vanliga tecken. Den största fördelen med detta format är kompatibilitet med ASCII, inte bara när det gäller koder, utan också i antalet bitar per tecken, eftersom en byte är tillräcklig för att koda något av de första 128 tecknen i UTF-8 (även om det till exempel behövs två bokstäver för kyrilliska byte).

UTF-8-formatet uppfanns den 2 september 1992 av Ken Thompson och Rob Pike och implementerades i plan 9. Nu är UTF-8-standarden officiellt förankrad i RFC 3629 och ISO / IEC 10646 bilaga D.

För webbdesignern är denna kodning särskilt viktig eftersom det är den som har förklarats som "standarddokumentkodning" i HTML sedan version 4.

Text som endast består av tecken med ett nummer mindre än 128 konverteras till vanlig ASCII-text när den skrivs till UTF-8. Omvänt, i UTF-8-text representerar varje byte med ett värde mindre än 128 ett ASCII-tecken med samma kod. Resten av Unicode-tecken representeras av sekvenser med 2 till 6 byte i längd (endast 4 byte är faktiskt möjligt, eftersom användningen av koder större än 221 inte är planerad), där den första byten alltid har formen 11xxxxxx, och resten 10xxxxxx.

Enkelt uttryckt, i UTF-8-format, skrivs latinska tecken, skiljetecken och ASCII-kontrolltecken i US-ASCII-koder, och alla andra tecken kodas med hjälp av flera oktetter med den viktigaste biten 1. Detta har två effekter.

Även om programmet inte känner igen Unicode, kommer latinska bokstäver, arabiska siffror och skiljetecken att visas korrekt.

Om de latinska bokstäverna och de enklaste skiljetecknen (inklusive ett mellanrum) upptar en betydande mängd text ger UTF-8 en volymförstärkning jämfört med UTF-16.

Vid första anblicken kan det tyckas att UTF-16 är mer bekvämt eftersom de flesta tecken i den är kodade med exakt två byte. Detta negeras emellertid av behovet av att stödja surrogatpar, som ofta glömts när man använder UTF-16, genom att bara använda stöd för UCS-2-tecken.

Unicode är en mycket stor och komplex värld, eftersom standarden låter dig representera och arbeta på en dator med alla grundläggande skrivsystem i världen. Vissa skrivsystem har funnits i mer än tusen år, och många av dem har utvecklats nästan oberoende av varandra i olika delar av världen. Människor har kommit med så många saker och det är ofta så till skillnad från varandra att det var en extremt svår och ambitiös uppgift att kombinera allt detta till en enda standard.

För att verkligen hantera Unicode måste du åtminstone ha en ytlig förståelse för funktionerna i alla skrivsystem som standarden tillåter dig att arbeta med. Men är det vad varje utvecklare behöver? Vi kommer att säga nej. För att använda Unicode i de flesta vardagliga uppgifter räcker det att ha ett rimligt minimum av information och sedan gå djupare in i standarden efter behov.

I den här artikeln kommer vi att prata om de grundläggande principerna för Unicode och lyfta fram de viktiga praktiska frågor som utvecklarna säkert kommer att stöta på i sitt dagliga arbete.

Varför behövde du Unicode?

  Innan Unicode användes enkebytkodningar nästan universellt, där gränsen mellan karaktärerna själva, deras representation i datorns minne och skärmen på skärmen var ganska godtycklig. Om du arbetade med ett eller annat nationellt språk installerades de lämpliga kodningsteckensnitten på ditt system, vilket gjorde det möjligt att dra byte från disken på skärmen på ett sådant sätt att de var vettiga för användaren.

Om du skrev ut en textfil på en skrivare och såg en uppsättning med oklara skurkar på en papperssida, innebar detta att motsvarande teckensnitt inte laddades i utskriftsenheten och det tolkade byte annorlunda än hur du vill ha det.

Detta tillvägagångssätt som en helhet och en-byte-kodning hade i synnerhet ett antal betydande nackdelar:

1. Det var möjligt att arbeta med endast 256 tecken åt gången, de första 128 var reserverade för latinska och kontrolltecken, och under andra hälften, utöver det nationella alfabetet, var det nödvändigt att hitta en plats för pseudo-grafiska tecken (╔ ╗).
2. Teckensnitt var bundna till en specifik kodning.
3. Varje kodning representerade sin egen teckenuppsättning och konvertering från en till en annan var endast möjlig med partiella förluster när saknade tecken ersattes med grafiskt liknande.
4. Att överföra filer mellan enheter som kör olika operativsystem var svårt. Det var nödvändigt antingen att ha ett konverteringsprogram eller att ha ytterligare typsnitt tillsammans med filen. Existensen av Internet som vi känner till var omöjligt.
5. Icke-alfabetiska skrivningssystem (hieroglyfiska skrifter) finns i världen, som i princip inte kan representeras vid kodning av enbyte.

Unicode Fundamentals

  Vi förstår alla perfekt att datorn inte känner till några ideala enheter utan fungerar med bitar och byte. Men datorsystem skapas fortfarande av människor, inte maskiner, och det är ibland bekvämare för dig och mig att arbeta med spekulativa begrepp och sedan gå vidare från abstrakt till konkret.

Viktigt!  En av de centrala principerna i Unicode-filosofin är en tydlig åtskillnad mellan symboler, deras representation på en dator och deras display på en utgångsenhet.

Begreppet en abstrakt Unicode-symbol introduceras, som exklusivt finns i form av ett spekulativt begrepp och ett avtal mellan människor, fastställt av standarden. Varje Unicode-karaktär är associerat med ett icke-negativt heltal som kallas kodpunkten.

Så till exempel är Unicode-karaktären U + 041F det huvudsakliga kyrilliska bokstaven P. Det finns flera sätt att representera detta tecken i datorns minne, precis som flera tusen sätt att visa det på skärmen. Men samtidigt kommer P att vara P eller U + 041F också i Afrika.

Detta är en välkänd inkapsling eller separering av gränssnittet från implementeringen - ett koncept som har bevisat sig i programmering.

Det visar sig att, med hjälp av standarden, kan valfri text kodas som en sekvens av Unicode-tecken

Hej U + 041F U + 0440 U + 0438 U + 0432 U + 0435 U + 0442
  skriva på ett papper, packa det i ett kuvert och skicka det till valfri ände på jorden. Om de vet om existensen av Unicode, kommer texten att accepteras av dem på exakt samma sätt som du och jag. De kommer inte att ha det minsta tvivel om att den näst sista karaktären är exakt den kyrilliska gemener e  (U + 0435) snarare än att säga latin liten e  (U + 0065). Observera att vi inte sa ett ord om bytepresentationen.

Även om Unicode-tecken kallas tecken, motsvarar de inte alltid en karaktär i traditionellt naiv mening, till exempel bokstäver, siffror, skiljetecken eller hieroglyft. (Se spoilern för mer information.)

Exempel på olika Unicode-tecken

Det finns rent tekniska Unicode-tecken, till exempel:

• U + 0000: nolltecken;
• U + D800 - U + DFFF: surrogat för juniorer och seniorer för teknisk representation av kodpositioner i området från 10 000 till 10FFFF (läs: utanför BMNP / BMP) i UTF-16-kodningsfamiljen;
• etc.

Det finns skiljetecken, till exempel U + 200F: en markör för att ändra skrivriktningen från höger till vänster.

Det finns en hel grupp utrymmen med olika bredder och syften (se den utmärkta Habra-artikeln :):

• U + 0020 (utrymme);
• U + 00A0 (icke-brytande utrymme, i HTML);
• U + 2002 (halvcirkelformat spatia eller En Space);
• U + 2003 (rund spionage eller Em Space);
• etc.

  Det finns kombinerbara diakritiska märken - alla slags slag, prickar, lutor etc. som ändrar / klargör innebörden av det föregående tecknet och dess märke. Till exempel:

• U + 0300 och U + 0301: tecken på primära (akuta) och sekundära (svaga) spänningar;
• U + 0306: kort (superskriptbåge), som i th;
• U + 0303: superscript tilde;
• etc.

  Det finns till och med en sådan exotisk sak som språketaggar (U + E0001, U + E0020 - U + E007E och U + E007F), som nu är i limbo. De var tänkta som en möjlighet att markera vissa avsnitt av texten som relaterade till ett visst språkalternativ (t.ex. amerikansk och brittisk engelska), vilket kan påverka detaljerna i textdisplayen.

Vad är en symbol, vad är skillnaden mellan ett grafeme-kluster (läs: uppfattas som en enda helbild av en symbol) från en Unicode-symbol och från en kodkvantum, kommer vi att berätta för dig nästa gång.

Unicode-kodutrymme

  Unicode-kodutrymmet består av 1 114,112 kodpositioner i intervallet 0 till 10FFFF. Av dessa tilldelas endast 128 237 värden till den nionde versionen av standarden. En del av utrymmet är reserverat för privat bruk och Unicode-konsortiet lovar att aldrig tilldela värden till positioner från dessa specialområden.

För enkelhets skull är hela utrymmet indelat i 17 plan (sex av dem är nu involverade). Fram till nyligen var det vanligt att säga att du troligtvis bara kommer att behöva ta itu med det grundläggande flerspråkiga planet (Basic Multilingual Plane, BMP), som inkluderar Unicode-tecken från U + 0000 till U + FFFF. (Ser lite framåt: tecken från BMP representeras i UTF-16 av två byte, inte fyra). 2016 är denna avhandling redan i tvivel. Till exempel kan populära Emoji-tecken mycket väl visas i ett användarmeddelande och du måste kunna hantera dem korrekt.

kodningar

  Om vi \u200b\u200bvill skicka text över Internet måste vi koda en sekvens med Unicode-tecken som en sekvens av byte.

Unicode-standarden innehåller en beskrivning av ett antal Unicode-kodningar, såsom UTF-8 och UTF-16BE / UTF-16LE, som låter dig koda hela utrymmet för kodpositioner. Konvertering mellan dessa kodningar kan fritt utföras utan förlust av information.

Dessutom avbröt ingen kodning av enbyte, men de låter dig koda din individuella och mycket smala bit av Unicode-spektrumet - 256 eller färre kodpositioner. För sådana kodningar finns tabeller och är tillgängliga för alla händelser, där varje värde för en enda byte är associerad med ett Unicode-tecken (se till exempel CP1251.TXT). Trots begränsningarna visar kodningar med en byte vara mycket praktiska när det gäller att arbeta med ett stort antal monolingual textinformation.

Av Unicode-kodningarna är den vanligaste på Internet UTF-8 (den vann handflatan 2008), främst på grund av dess kostnadseffektivitet och transparenta kompatibilitet med sju-bitars ASCII. Latin och servicetecken, grundläggande skiljetecken och siffror - dvs alla sju-bitars ASCII-tecken är kodade i UTF-8 med en byte, samma som i ASCII. Symboler för många grundläggande skript, förutom några mer sällsynta hieroglyfiska tecken, representeras i det av två eller tre byte. Den största av standardkodpositionerna - 10FFFF - är kodad i fyra byte.

Observera att UTF-8 är en variabel längdkodning. Varje Unicode-karaktär i den representeras av en sekvens av kodkvanta med en minsta längd på ett kvantum. Siffran 8 betyder kodenhetens bitlängd - 8 bitar. För UTF-16-kodningsfamiljen är kodkvantstorleken 16 bitar. För UTF-32, 32 bitar.

Om du skickar en HTML-sida med kyrillisk text över nätverket kan UTF-8 ge en mycket konkret förstärkning, eftersom all markering, såväl som JavaScript och CSS-block, kommer att kodas effektivt i en byte. Till exempel är startsidan för Habr i UTF-8 139Kb, och i UTF-16 är den redan 256Kb. Som jämförelse, om du använder win-1251 med förlust av förmågan att spara vissa tecken, kommer storleken, jämfört med UTF-8, att reduceras med endast 11 kb till 128 kb.

För att lagra stränginformation i applikationer används 16-bitars Unicode-kodningar ofta på grund av deras enkelhet, liksom det faktum att karaktärerna i huvudvärldsskrivsystemen är kodade med en sexton-bitars kvantitet. Så till exempel använder Java framgångsrikt UTF-16 för internrepresentation av strängar. Windows-operativsystemet i sig själv använder också UTF-16.

I vilket fall som helst, medan vi förblir i Unicode-utrymmet, är det inte så viktigt hur stränginformationen lagras i en separat applikation. Om det interna lagringsformatet tillåter dig att korrekt koda alla miljoner eller fler kodpositioner vid applikationsgränsen, till exempel när du läser från en fil eller kopierar till urklippet, finns det ingen förlust av information, då är allt bra.

För korrekt tolkning av text som läses från en disk eller från ett nätverkskontakt måste du först bestämma dess kodning. Detta görs antingen med hjälp av metainformation som tillhandahålls av användaren, inspelad i eller bredvid texten eller bestämd heuristiskt.

I den torra återstoden

  Det finns mycket information och det är vettigt att ge en kort pressning av allt som skrivits ovan:

• Unicode postulerar en tydlig åtskillnad mellan tecken, deras representation på datorn och deras skärm på utgångsenheten.
• Unicode-tecken motsvarar inte alltid ett tecken i traditionellt naiv mening, till exempel bokstäver, siffror, skiljetecken eller hieroglyft.
• Unicode-kodutrymmet består av 1 114,112 kodpositioner i intervallet 0 till 10FFFF.
• Det grundläggande flerspråkiga planet inkluderar Unicode-tecken från U + 0000 till U + FFFF, som kodas i UTF-16 av två byte.
• Varje Unicode-kodning låter dig koda hela utrymmet för Unicode-kodpositioner och konvertering mellan olika sådana kodningar utförs utan förlust av information.
• Enbyte-kodning låter dig koda bara en liten del av Unicode-spektrumet, men kan vara användbart när du arbetar med en stor mängd enspråkig information.
• UTF-8- och UTF-16-kodningarna har en variabel kodlängd. I UTF-8 kan varje Unicode-tecken kodas i en, två, tre eller fyra byte. I UTF-16, två eller fyra byte.
• Det interna formatet för att lagra textinformation i en separat applikation kan vara godtyckligt under förutsättning att det fungerar korrekt med hela utrymmet för Unicode-kodpositioner och det går inte att förlora under gränsöverskridande dataöverföring.

En kort anteckning om kodning

  Det kan vara viss förvirring med termen kodning. Inom Unicode sker kodningen två gånger. Första gången en Unicode-teckenuppsättning kodas, i den meningen att varje Unicode-tecken tilldelas en kodposition. Som en del av denna process omvandlas Unicode-teckenuppsättningen till en kodad teckenuppsättning. Andra gången konverteras en sekvens med Unicode-tecken till en byte-sträng och denna process kallas också kodning.

I engelska terminologin finns det två olika verb, att koda och att koda, men även modersmål är ofta förvirrade. Dessutom används termen teckenuppsättning eller charset som en synonym för termen kodad teckenuppsättning.

Allt detta säger vi att det är vettigt att uppmärksamma kontexten och skilja mellan situationer när det gäller kodpositionen för en abstrakt Unicode-symbol och när det gäller dess bytepresentation.

Avslutningsvis

  Det finns så många olika aspekter på Unicode att det är omöjligt att täcka allt i en artikel. Ja, och onödigt. Ovanstående information är tillräckligt för att inte bli förvirrad i de grundläggande principerna och arbeta med text i de flesta dagliga uppgifter (läs: utan att gå längre än BMP). I följande artiklar kommer vi att prata om normalisering, ge en mer fullständig historisk översikt över utvecklingen av kodningar, prata om problemen med ryskspråkiga Unicode-terminologier, och också göra material om de praktiska aspekterna av att använda UTF-8 och UTF-16.