Unicode

Unicode
New Unicode logo.svg
Alias Universell kodad teckenuppsättning (UCS, ISO/IEC 10646)
Språk) Internationell
Standard Unicode standard
Kodningsformat
Föregås av ISO/IEC 8859 , diverse andra

Unicode , formellt The Unicode Standard , är en informationsteknologistandard för konsekvent kodning , representation och hantering av text som uttrycks i de flesta av världens skrivsystem . Standarden, som underhålls av Unicode Consortium , definierar från och med den nuvarande versionen (15.0) 149 186 tecken som täcker 161 moderna och historiska skript samt symboler, 3664 emoji (inklusive i färger) och icke-visuella kontroll- och formateringskoder .

Unicodes framgång med att förena teckenuppsättningar har lett till dess utbredda och dominerande användning vid internationalisering och lokalisering av datorprogramvara . Standarden har implementerats i många nyare teknologier, inklusive moderna operativsystem , XML , JSON och de flesta moderna programmeringsspråk , ibland endast i UTF-8- form, som också stöds i Microsoft Windows .

Unicode-teckenrepertoaren är synkroniserad med ISO/IEC 10646, var och en är kod-för-kod identisk med den andra. Unicode-standarden innehåller dock mer än bara baskoden . Vid sidan av teckenkodningarna innehåller konsortiets officiella publikation en mängd olika detaljer om skripten och hur man visar dem: normaliseringsregler , nedbrytning, sammanställning , rendering och dubbelriktad textvisningsordning för flerspråkiga texter, och så vidare. Standarden _ innehåller även referensdatafiler och visuella diagram för att hjälpa utvecklare och designers att implementera repertoaren korrekt.

Unicode kan lagras med flera olika kodningar , som översätter teckenkoderna till sekvenser av byte. Unicode-standarden definierar tre och flera andra kodningar finns, alla i praktiken kodningar med variabel längd . De vanligaste kodningarna är den ASCII -kompatibla UTF-8 , den ASCII-inkompatibla UTF-16 (kompatibel med den föråldrade UCS-2 ), och den kinesiska Unicode-kodningsstandarden GB18030 som inte är en officiell Unicode-standard men som används i Kina och implementerar Unicode fullt ut.

Ursprung och utveckling

Unicode har det uttryckliga syftet att överskrida begränsningarna för traditionella teckenkodningar, såsom de som definieras av ISO/IEC 8859- standarden, som har stor användning i olika länder i världen men förblir i stort sett inkompatibla med varandra. Många traditionella teckenkodningar delar ett gemensamt problem genom att de tillåter tvåspråkig datorbehandling (vanligtvis med latinska tecken och det lokala skriptet), men inte flerspråkig datorbehandling (datorbehandling av godtyckliga skript blandade med varandra).

Unicode kodar i avsikt de underliggande tecknen - grafem och grafeliknande enheter - snarare än variantglyferna ( renderingar) för sådana tecken. I fallet med kinesiska tecken leder detta ibland till kontroverser över att skilja det underliggande teckenet från dess variantglyfer (se Han-föreningen) .

Vid textbearbetning tar Unicode rollen att tillhandahålla en unik kodpunkt — ett nummer , inte en glyf — för varje tecken. Med andra ord representerar Unicode ett tecken på ett abstrakt sätt och lämnar den visuella renderingen (storlek, form, teckensnitt eller stil) till annan programvara, till exempel en webbläsare eller ordbehandlare . Detta enkla mål blir dock komplicerat på grund av eftergifter som Unicodes designers gör i hopp om att uppmuntra ett snabbare antagande av Unicode.

De första 256 kodpunkterna gjordes identiska med innehållet i ISO/IEC 8859-1 för att göra det trivialt att konvertera befintlig västerländsk text. Många i huvudsak identiska tecken kodades flera gånger vid olika kodpunkter för att bevara distinktioner som används av äldre kodningar och därför tillåta konvertering från dessa kodningar till Unicode (och tillbaka) utan att förlora någon information. Till exempel omfattar avsnittet " fullwidth forms " i kodpunkter en fullständig kopia av det latinska alfabetet eftersom kinesiska, japanska och koreanska ( CJK )-teckensnitt innehåller två versioner av dessa bokstäver, "fullbredd" som matchar bredden på CJK-tecken och normal bredd. För andra exempel, se dubbletter av tecken i Unicode .

Mottagare av Unicode Bulldog Award inkluderar många namn som är inflytelserika i utvecklingen av Unicode och inkluderar Tatsuo Kobayashi , Thomas Milo, Roozbeh Pournader , Ken Lunde och Michael Everson .

Historia

Baserat på erfarenheter med Xerox Character Code Standard (XCCS) sedan 1980, kan Unicodes ursprung spåras tillbaka till 1987, när Joe Becker från Xerox med Lee Collins och Mark Davis från Apple började undersöka de praktiska funktionerna för att skapa en universell karaktärsuppsättning. Med ytterligare input från Peter Fenwick och Dave Opstad , publicerade Joe Becker ett utkast till förslag för ett "internationellt/flerspråkigt textteckenkodningssystem i augusti 1988, preliminärt kallat Unicode". Han förklarade att "namnet 'Unicode' är avsett att föreslå en unik, enhetlig, universell kodning".

I detta dokument, med titeln Unicode 88 , skisserade Becker en 16-bitars teckenmodell:

Unicode är avsett att möta behovet av en fungerande, pålitlig världstextkodning. Unicode kan grovt beskrivas som "wide-body ASCII " som har sträckts ut till 16 bitar för att omfatta tecknen i alla världens levande språk. I en korrekt konstruerad design är 16 bitar per tecken mer än tillräckligt för detta ändamål.

Hans ursprungliga 16-bitars design baserades på antagandet att endast de skript och tecken i modern användning skulle behöva kodas:

Unicode ger högre prioritet åt att säkerställa nytta för framtiden än att bevara tidigare fornminnen. Unicode siktar i första hand på de tecken som publicerats i modern text (t.ex. i sammanslutningen av alla tidningar och tidskrifter som trycktes i världen 1988), vars antal utan tvekan är långt under 2 14 = 16 384 . Utöver dessa moderna karaktärer kan alla andra definieras som föråldrade eller sällsynta; dessa är bättre kandidater för privat användning än för att överbelasta den offentliga listan över allmänt användbara Unicodes.

I början av 1989 utökades Unicode-arbetsgruppen till att omfatta Ken Whistler och Mike Kernaghan från Metaphor, Karen Smith-Yoshimura och Joan Aliprand från RLG och Glenn Wright från Sun Microsystems , och 1990 Michel Suignard och Asmus Freytag från Microsoft och Rick McGowan of NeXT gick med i gruppen. I slutet av 1990 hade det mesta av arbetet med att kartlägga befintliga teckenkodningsstandarder slutförts, och ett sista granskningsutkast av Unicode var klart.

Unicode -konsortiet bildades i Kalifornien den 3 januari 1991 och i oktober 1991 publicerades den första volymen av Unicode-standarden. Den andra volymen, som täcker Han-ideografer, publicerades i juni 1992.

1996 implementerades en surrogatteckenmekanism i Unicode 2.0, så att Unicode inte längre var begränsad till 16 bitar. Detta ökade Unicode-kodutrymmet till över en miljon kodpunkter, vilket möjliggjorde kodning av många historiska skript (t.ex. egyptiska hieroglyfer ) och tusentals sällan använda eller föråldrade tecken som inte hade förväntats behöva kodas. Bland de tecken som ursprungligen inte var avsedda för Unicode används sällan Kanji- eller kinesiska tecken, av vilka många är en del av person- och ortnamn, vilket gör dem mycket mer väsentliga än vad man tänkt sig i Unicodes ursprungliga arkitektur.

Microsoft TrueType-specifikationen version 1.0 från 1992 använde namnet "Apple Unicode" istället för "Unicode" för plattforms-ID i namntabellen.

Unicode-konsortiet

Unicode Consortium är en ideell organisation som koordinerar Unicodes utveckling. Fullständiga medlemmar inkluderar de flesta av de största datorprogram- och hårdvaruföretagen med något intresse av textbearbetningsstandarder, inklusive Adobe , Apple , Facebook , Google , IBM , Microsoft , Netflix och SAP SE .

Under åren har flera länder eller statliga myndigheter varit medlemmar i Unicode-konsortiet. För närvarande är endast ministeriet för donationer och religiösa frågor (Oman) fullvärdig medlem med rösträtt.

Konsortiet har det ambitiösa målet att så småningom ersätta befintliga teckenkodningsscheman med Unicode och dess standardsystem för Unicode Transformation Format (UTF), eftersom många av de befintliga systemen är begränsade i storlek och omfattning och är oförenliga med flerspråkiga miljöer .

Manus täckta

Många moderna applikationer kan återge en betydande delmängd av de många skripten i Unicode , vilket visas av den här skärmdumpen från OpenOffice.org -applikationen.

Unicode täcker för närvarande de flesta större skrivsystem som används idag. [ bättre källa behövs ]

ingår totalt 161 skript i den senaste versionen av Unicode (som täcker alfabet , abugidas och syllabaries ), även om det fortfarande finns skript som ännu inte är kodade, särskilt de som huvudsakligen används i historiska, liturgiska och akademiska sammanhang. Ytterligare tillägg av tecken till de redan kodade skripten, liksom symboler, särskilt för matematik och musik (i form av noter och rytmiska symboler), förekommer också.

Unicode Roadmap Committee ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) upprätthåller listan över skript som är kandidater eller potentiella kandidater för kodning och deras preliminära kodblockstilldelningar på Unicode Roadmap-sidan på Unicode Consortiums webbplats . För vissa manus på färdplanen, som Jurchen och Khitan små manus , har kodningsförslag gjorts och de arbetar sig igenom godkännandeprocessen. För andra manus, som Mayan (förutom siffror) och Rongorongo , inget förslag har ännu lagts fram, och de väntar på överenskommelse om karaktärsrepertoar och andra detaljer från de inblandade användargrupperna.

Vissa moderna uppfunna skript som ännu inte har inkluderats i Unicode (t.ex. Tengwar ) eller som inte kvalificerar sig för inkludering i Unicode på grund av bristande användning i verkligheten (t.ex. Klingon ) är listade i ConScript Unicode Registry , tillsammans med inofficiella men ofta använda tilldelningar för privata användningsområden .

Det finns också ett medeltida Unicode Font Initiative fokuserat på speciella latinska medeltida tecken. En del av dessa förslag har redan inkluderats i Unicode.

Script Encoding Initiative

Script Encoding Initiative, ett projekt som drivs av Deborah Anderson vid University of California, Berkeley grundades 2002 med målet att finansiera förslag till skript som ännu inte kodats i standarden. Projektet har blivit en viktig källa till föreslagna tillägg till standarden de senaste åren.

Versioner

Unicode-konsortiet och International Organization for Standardization (ISO) har tillsammans utvecklat en delad repertoar efter den första publiceringen av The Unicode Standard 1991; Unicode och ISO:s Universal Coded Character Set (UCS) använder identiska teckennamn och kodpunkter. Unicode-versionerna skiljer sig dock från sina ISO-motsvarigheter på två betydande sätt.

Medan UCS är en enkel teckenkarta, specificerar Unicode de regler, algoritmer och egenskaper som krävs för att uppnå interoperabilitet mellan olika plattformar och språk. Således Unicode-standarden mer information och täcker – på djupet – ämnen som bitvis kodning, sortering och rendering. Den tillhandahåller också en omfattande katalog över teckenegenskaper, inklusive de som behövs för att stödja dubbelriktad text , samt visuella diagram och referensdatauppsättningar för att hjälpa implementerare. Tidigare Unicode Standard såldes som en utskriftsvolym innehållande den fullständiga kärnspecifikationen, standardbilagor och koddiagram. Unicode 5.0, publicerad 2006, var dock den sista versionen som trycktes på detta sätt. Från och med version 5.2 kan endast kärnspecifikationen, publicerad som print-on-demand pocketbok, köpas. Hela texten, å andra sidan, publiceras som en gratis PDF på Unicodes webbplats.

Ett praktiskt skäl till denna publiceringsmetod framhäver den andra betydande skillnaden mellan UCS och Unicode – frekvensen med vilken uppdaterade versioner släpps och nya tecken läggs till. Unicode-standarden har regelbundet släppt årliga utökade versioner, ibland med mer än en version som släppts under ett kalenderår och i sällsynta fall där den planerade releasen måste skjutas upp. Till exempel, i april 2020, bara en månad efter att version 13.0 publicerades, meddelade Unicode Consortium att de hade ändrat det avsedda releasedatumet för version 14.0, och förskjutit det sex månader från mars 2021 till september 2021 på grund av COVID-19-pandemin .

Den senaste versionen av Unicode, 15.0.0, släpptes den 13 september 2022. Flera bilagor uppdaterades inklusive Unicode Security Mechanisms (UTS #39), och totalt 4489 nya tecken kodades, inklusive 20 nya emoji-tecken, som " trådlös " (nätverks)-symbol och hjärtan i olika färger såsom rosa, två nya skript, CJK Unified Ideographs -tillägg och flera tillägg till befintliga block.

Hittills har följande större och mindre versioner av Unicode-standarden publicerats. Uppdateringsversioner, som inte inkluderar några ändringar av teckenrepertoaren, betecknas med det tredje numret (t.ex. "version 4.0.1") och utelämnas i tabellen nedan.

Version Datum bok Motsvarande ISO/IEC 10646 -utgåva Manus Tecken
Total Anmärkningsvärda tillägg
1.0.0 oktober 1991   ISBN 0-201-56788-1 (Vol. 1) 24 7 129 Den ursprungliga repertoaren täcker dessa manus: arabiska , armeniska , bengaliska , bopomofo , kyrilliska , devanagari , georgiska , grekiska och koptiska , gujarati , gurmukhi , hangul , hebreiska , hiragana , kannada , katakana , lao , latin , latin , o . Tamil , Telugu , Thai och Tibetan .
1.0.1 juni 1992 ISBN 0-201-60845-6 (Vol. 2) 25

28 327 (21 204 tillagda; 6 borttagna)
Den initiala uppsättningen av 20 902 CJK Unified Ideographs är definierad.
1.1 juni 1993 ISO/IEC 10646 -1:1993 24




34 168 (5 963 tillagda; 89 borttagna; 33 omklassificerade som kontrolltecken )
4 306 fler Hangul- stavelser läggs till i originaluppsättningen med 2 350 tecken. Tibetanska borttagen.
2.0 juli 1996 ISBN 0-201-48345-9 ISO/IEC 10646-1:1993 plus tillägg 5, 6 och 7 25

38 885 (11 373 tillagda; 6 656 borttagna)
Den ursprungliga uppsättningen Hangul- stavelser togs bort och en ny uppsättning med 11 172 Hangul-stavelser lades till på en ny plats. Tibetan lades till på en ny plats och med en annan karaktärsrepertoar. Surrogatteckenmekanism definierad, och plan 15 och plan 16 privata användningsområden tilldelade.
2.1 maj 1998 ISO/IEC 10646-1:1993 plus tillägg 5, 6 och 7, samt två tecken från tillägg 18 25
38 887 (2 tillagda)
Eurotecken och objektersättningstecken har lagts till.
3.0 september 1999 ISBN 0-201-61633-5 ISO/IEC 10646-1:2000 38
49 194 (10 307 tillagda)
Cherokee , Etiopiska , Khmer , Mongoliska , Burmesiska , Ogham , Runiska , Sinhala , Syriac , Thaana , Unified Canadian Aboriginal Syllabics och Yi Syllables har lagts till, samt en uppsättning punktskriftsmönster .
3.1 mars 2001 ISO/IEC 10646-1:2000

ISO/IEC 10646-2:2001

41
94 140 (44 946 tillagda)
Deseret , Gothic och Old Italic lades till, liksom uppsättningar av symboler för västerländsk musik och bysantinsk musik , och 42 711 ytterligare CJK Unified Ideographs .
3.2 mars 2002 ISO/IEC 10646-1:2000 plus tillägg 1

ISO/IEC 10646-2:2001

45
95 156 (1 016 tillagda)
Filippinska manus Buhid , Hanunoo , Tagalog och Tagbanwa har lagts till.
4.0 april 2003 ISBN 0-321-18578-1 ISO/IEC 10646:2003 52
96 382 (1 226 tillagda)
Cypriotiska syllabary , Limbu , Linear B , Osmanya , Shavian , Tai Le , och Ugaritic har lagts till, liksom hexagramsymboler .
4.1 mars 2005 ISO/IEC 10646:2003 plus tillägg 1 59
97 655 (1 273 tillagda)
Buginesiska , Glagolitiska , Kharosthi , New Tai Lue , Old Persian , Sylheti Nagri och Tifinagh lade till, och koptiska var disunified från grekiska . Forntida grekiska siffror och musikaliska symboler tillkom också.
5.0 juli 2006 ISBN 0-321-48091-0 ISO/IEC 10646:2003 plus tillägg 1 och 2, samt fyra tecken från tillägg 3 64
99 024 (1 369 tillagda)
Balinesiska , Cuneiform , N'Ko , 'Phags-pa , och Fenician tillade.
5.1 april 2008 ISO/IEC 10646:2003 plus tillägg 1, 2, 3 och 4 75
100 648 (1 624 tillagda)
Carian , Cham , Kayah Li , Lepcha , Lycian , Lydian , Ol Chiki , Rejang , Saurashtra , Sundanese och Vai lades till, liksom uppsättningar av symboler för Phaistos-skivan , Mahjong-brickorna och Domino-brickorna . Det fanns också viktiga tillägg för burmesiska , tillägg av bokstäver och skriftlärda förkortningar som användes på medeltida manuskript och tillägg av Kapital ẞ .
5.2 oktober 2009 ISBN 978-1-936213-00-9 ISO/IEC 10646:2003 plus tillägg 1, 2, 3, 4, 5 och 6 90
107 296 (6 648 tillagda)
Avestan , Bamum , egyptiska hieroglyfer ( Gardiner-uppsättningen , bestående av 1 071 tecken), kejserliga arameiska , inskriptionspahlavi , inskriptionsparthiska , javanesiska , kaithi , Lisu , Meetei Mayek , gammal sydarabiska , gammalturkiska , tai-samaritanska och tai -samaritanska . 4 149 ytterligare CJK Unified Ideographs (CJK-C), såväl som utökad Jamo för Old Hangul och karaktärer för vedisk sanskrit .
6,0 oktober 2010 ISBN 978-1-936213-01-6 ISO/IEC 10646:2010 plus tecknet för indiska rupier 93
109 384 (2 088 tillagda)
Batak , Brahmi , Mandaic , spelkortssymboler , transport- och kartsymboler , alkemiska symboler , uttryckssymboler och emojis . 222 ytterligare CJK Unified Ideographs (CJK-D) har lagts till.
6.1 januari 2012 ISBN 978-1-936213-02-3 ISO/IEC 10646:2012 100
110 116 (732 tillagda)
Chakma , meroitiska kursiv , meroitiska hieroglyfer , Miao , Sharada , Sora Sompeng och Takri .
6.2 september 2012 ISBN 978-1-936213-07-8 ISO/IEC 10646:2012 plus tecknet turkisk lira 100
110 117 (1 tillagd)
Turkisk lira tecken .
6.3 september 2013 ISBN 978-1-936213-08-5 ISO/IEC 10646:2012 plus sex tecken 100
110 122 (5 tillagda)
5 dubbelriktade formateringstecken.
7,0 juni 2014 ISBN 978-1-936213-09-2 ISO/IEC 10646:2012 plus tillägg 1 och 2, samt rubeltecknet 123
112 956 (2 834 tillagda)
Bassa Vah , kaukasisk albansk , Duployan , Elbasan , Grantha , Khojki , Khudawadi , Linear A , Mahajani , Manichaean , Mende Kikakui , Modi , Mro , Nabataean , Old North Arabian , Old Permic , Pahawhm Håvi , Palmalin Håvi , Pahawhm Håvi , Siddham , Tirhuta , Warang Citi och Dingbats .
8,0 juni 2015 ISBN 978-1-936213-10-8 ISO/IEC 10646:2014 plus tillägg 1, såväl som Lari-tecknet , nio CJK förenade ideografer och 41 emoji-tecken 129
120 672 (7 716 tillagda)
Ahom , anatoliska hieroglyfer , Hatran , Multani , Old Hungarian , SignWriting , 5 771 CJK Unified Ideographs , en uppsättning små bokstäver för Cherokee och fem emoji- hudtonsmodifierare .
9,0 juni 2016 ISBN 978-1-936213-13-9 ISO/IEC 10646:2014 plus tillägg 1 och 2, samt Adlam, Newa, japanska TV-symboler och 74 emoji och symboler 135
128 172 (7 500 tillagda)
Adlam , Bhaiksuki , Marchen , Newa , Osage , Tangut och 72 emoji .
10,0 juni 2017 ISBN 978-1-936213-16-0 ISO/IEC 10646:2017 plus 56 emoji- tecken, 285 hentaigana -tecken och 3 Zanabazar Square-tecken 139
136 690 (8 518 tillagda)
Zanabazar Square , Soyombo , Masaram Gondi , Nüshu , hentaigana (icke-standard hiragana ), 7 494 CJK Unified Ideographs , 56 emoji och bitcoin- symbol.
11.0 juni 2018 ISBN 978-1-936213-19-1 ISO/IEC 10646:2017 plus tillägg 1, samt 46 Mtavruli georgiska versaler, 5 CJK enhetliga ideografer och 66 emoji-tecken. 146
137 374 (684 tillagda)
Dogra , georgiska Mtavruli versaler , Gunjala Gondi , Hanifi Rohingya , Indic Siyaq Numbers , Makasar , Medefaidrin , Old Sogdian och Sogdian , Maya siffror , 5 brådskande CJK Unified Ideographs , symboler för xiangqi s och 1 xiangqi (Chinese xiangqi ) .
12,0 mars 2019 ISBN 978-1-936213-22-1 ISO/IEC 10646:2017 plus tillägg 1 och 2, samt 62 ytterligare tecken. 150
137 928 (554 tillagda)
Elymaic , Nandinagari , Nyiakeng Puachue Hmong , Wancho , Miao scripttillägg för flera Miao- och Yi-språk i Kina, hiragana och katakana små bokstäver för att skriva arkaiska japanska, tamilska historiska bråk och symboler, laotiska bokstäver för pali , latinska bokstäver för egyptologiska och ugariska bokstäver , hieroglyfformatkontroller och 61 emoji .
12.1 maj 2019 ISBN 978-1-936213-25-2 150
137 929 (1 tillagd)
Lägger till ett enda tecken vid U+32FF för den kvadratiska ligaturformen av namnet på Reiwa-eran .
13,0 mars 2020 ISBN 978-1-936213-26-9 ISO/IEC 10646:2020 154
143 859 (5 930 tillagda)
Chorasmian , Dhives Akuru , Khitan small script , Yezidi , 4 969 CJK förenade ideografer har lagts till (inklusive 4 939 i Ext. G ) , arabiska manustillägg som används för att skriva Hausa , Wolof och andra språk i Afrika och andra tillägg som används för att skriva in Hindko och Punjabi Pakistan, Bopomofo-tillägg som används för kantonesiska, Creative Commons-licenssymboler, grafiska tecken för kompatibilitet med text-TV och hemdatorsystem från 1970- och 1980-talen, och 55 emoji.
14,0 september 2021 ISBN 978-1-936213-29-0 159
144 697 (838 tillagda)
Toto , Cypro-Minoan , Vithkuqi , Old Uyghur , Tangsa , latinska skriftstillägg vid SMP-block ( Ext-F , Ext-G ) för användning i utökad IPA , arabiska skriftstillägg för användning på språk över hela Afrika och i Iran, Pakistan, Malaysia , Indonesien, Java och Bosnien, och att skriva hedersbetygelser, tillägg för användning i Koranen, andra tillägg för att stödja språk i Nordamerika, Filippinerna, Indien och Mongoliet, tillägg av valutasymbolen Kyrgyzstani som, stöd för Znamenny musikalisk notation och 37 emoji.
15,0 september 2022 ISBN 978-1-936213-32-0 161
149 186 (4 489 tillagda)
Kawi och Mundari , flera nya karaktärer, inklusive 20 emoji, 4 192 CJK-ideografer och kontrolltecken för egyptiska hieroglyfer .

Projicerade versioner

Version 15.1, planerad att publiceras i september 2023, är en nedskärning för att konsolidera stöd och karaktärsbeteende. Den lägger till endast 5 tecken, nämligen CJK-beskrivnings-/formateringstecken vid punkterna U+2FFC–2FFF och 31EF. Betydande tillägg av tecken kommer inte att ske förrän version 16, i pipeline för 2024.

Arkitektur och terminologi

Kodutrymme och kodpunkter

Unicode-standarden definierar ett kodutrymme : en uppsättning heltal som kallas kodpunkter och betecknas som U+0000 till U+10FFFF .

De två första tecknen är alltid "U+" för att indikera början av en kodpunkt. De följs av kodpunktsvärdet i hexadecimal . Minst 4 hexadecimala siffror visas med inledande nollor efter behov.

Hiero O4.png Till exempel är U+00F7 för divisionstecknet ÷ vadderat med två inledande nollor, men U+13254 för den egyptiska hieroglyfen är inte vadderat.

Av dessa 2 16 + 2 20 definierade kodpunkter är kodpunkterna från U+D800 till U+DFFF , som används för att koda surrogatpar i UTF-16 , reserverade av Unicode-standarden och får inte användas för att koda giltiga tecken , vilket resulterar i en nettosumma på 2 16 + 2 20 − 2 11 = 1 112 064 tilldelbara kodpunkter.

Koda plan och block

Unicode-kodutrymmet är uppdelat i sjutton plan , numrerade 0 till 16. Plan 0 är Basic Multilingual Plane (BMP), som innehåller de vanligaste tecknen. Alla kodpunkter i BMP nås som en enda kodenhet i UTF-16- kodning och kan kodas i en, två eller tre byte i UTF-8 . Kodpunkter i plan 1 till 16 ( tilläggsplan ) nås som surrogatpar i UTF-16 och kodas i fyra byte i UTF-8.

Inom varje plan tilldelas tecken inom namngivna block med relaterade tecken. Även om block har en godtycklig storlek, är de alltid en multipel av 16 kodpunkter och ofta en multipel av 128 kodpunkter. Tecken som krävs för ett givet skript kan vara utspridda över flera olika block.

Allmän kategori fastighet

Varje kodpunkt har en enda egenskap för allmän kategori . De viktigaste kategorierna betecknas: Bokstav, Mark, Siffra, Skiljetecken, Symbol, Separator och Övrigt. Inom dessa kategorier finns underkategorier. I de flesta fall måste andra egenskaper användas för att tillräckligt specificera egenskaperna hos en kodpunkt. De möjliga allmänna kategorierna är:

Allmän kategori (Unicode Character Property )
Värde Kategori major, moll Grundläggande typ Karaktär tilldelad
Antal (från och med 15.0)
Anmärkningar
 
L , Bokstav; LC , versaler (endast Lu, Ll och Lt)
Lu Bokstav, versaler Grafisk Karaktär 1,831
Ll Bokstav, gemener Grafisk Karaktär 2,233
Lt Brev, titelfall Grafisk Karaktär 31 Ligaturer som innehåller versaler följt av små bokstäver (t.ex. Dž , Lj , Nj och Dz )
Lm Bokstav, modifierare Grafisk Karaktär 397 En modifieringsbokstav
Lo Brev, annat Grafisk Karaktär 131,612 En ideograf eller en bokstav i ett unicase-alfabet
M , Mark
Mn Mark, utan mellanslag Grafisk Karaktär 1 985
Mc Markera, mellanrumskombination Grafisk Karaktär 452
Mig Mark, omslutande Grafisk Karaktär 13
N , nummer
Nd Tal, decimalsiffra Grafisk Karaktär 680 Alla dessa, och endast dessa, har numerisk typ = De
Nl Siffra, bokstav Grafisk Karaktär 236 Siffror som består av bokstäver eller bokstavsliknande symboler (t.ex. romerska siffror )
Nej Nummer, annat Grafisk Karaktär 915 Till exempel vulgära bråk , upphöjda och nedsänkta siffror
P , Interpunktion
Pc Skiljetecken, kontakt Grafisk Karaktär 10 Inkluderar mellanrumstecken som "_" och andra mellanrumstecken . Till skillnad från andra skiljetecken kan dessa klassificeras som "ord"-tecken av reguljära uttrycksbibliotek.
Pd Skiljetecken, streck Grafisk Karaktär 26 Innehåller flera bindestreck
Ps Skiljetecken, öppen Grafisk Karaktär 79 Tecken för öppningsparentes
Pe Skiljetecken, nära Grafisk Karaktär 77 Tecknen för avslutande parentes
Pi Skiljetecken, första citat Grafisk Karaktär 12 Inledande citattecken . Inkluderar inte ASCII "neutrala" citattecken. Kan bete sig som Ps eller Pe beroende på användning
Pf Skiljetecken, sista citat Grafisk Karaktär 10 Avslutande citattecken. Kan bete sig som Ps eller Pe beroende på användning
Po Skiljetecken, andra Grafisk Karaktär 628
S , Symbol
Sm Symbol, matematik Grafisk Karaktär 948 Matematiska symboler (t.ex. + , , = , × , ÷ , , , ). Inkluderar inte parenteser och parenteser, som finns i kategorierna Ps och Pe. Inkluderar inte heller ! , * , - , eller / , som trots frekvent användning som matematiska operatorer, i första hand anses vara "interpunktion".
Sc Symbol, valuta Grafisk Karaktär 63 Valutasymboler
Sk Symbol, modifierare Grafisk Karaktär 125
Symbol, annat Grafisk Karaktär 6,634
Z , separator
Zs Separator, utrymme Grafisk Karaktär 17 Inkluderar blanksteg, men inte TAB , CR eller LF , som är Cc
Zl Separator, linje Formatera Karaktär 1 Endast U+2028 LINE SEPARATOR (LSEP)
Z P Avskiljare, paragraf Formatera Karaktär 1 Endast U+2029 PUNKTSEPARATOR (PSEP)
C , Annat
Cc Annat, kontroll Kontrollera Karaktär 65 (kommer aldrig att förändras) Inget namn,<control>
Jfr Annat, format Formatera Karaktär 170 Innehåller det mjuka bindestrecket , sammanfogande kontrolltecken ( ZWNJ och ZWJ ), kontrolltecken för att stödja dubbelriktad text och språktagg -tecken
Cs Annat, surrogat Surrogat Inte (används endast i UTF-16 ) 2 048 (kommer aldrig att förändras) Inget namn,<surrogate>
Co Annat, privat bruk Privat användning Karaktär (men ingen tolkning specificerad) 137 468 totalt (kommer aldrig att förändras) ( 6 400 i BMP , 131 068 i Plan 15–16 ) Inget namn,<private-use>
Cn Annat, ej tilldelat Icke karaktär Inte 66 (kommer aldrig att förändras) Inget namn,<noncharacter>
Reserverad Inte 825,279 Inget namn,<reserved>

Kodpunkter i intervallet U+D800–U+DBFF (1 024 kodpunkter) är kända som högsurrogatkodpunkter, och kodpunkter i intervallet U+DC00–U+DFFF (1 024 kodpunkter) kallas lågsurrogatkoder kodpunkter. En hög surrogatkodpunkt följt av en låg surrogatkodpunkt bildar ett surrogatpar i UTF-16 för att representera kodpunkter större än U+FFFF. Dessa kodpunkter kan annars inte användas (denna regel ignoreras ofta i praktiken, särskilt när man inte använder UTF-16).

En liten uppsättning kodpunkter kommer garanterat aldrig att användas för att koda tecken, även om applikationer kan använda dessa kodpunkter internt om de så önskar. Det finns sextiosex av dessa icke-tecken : U+FDD0–U+FDEF och valfri kodpunkt som slutar på värdet FFFE eller FFFF (dvs. U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, ... U +10FFFE, U+10FFFF). Uppsättningen av icke-tecken är stabil och inga nya icke-tecken kommer någonsin att definieras. Liksom surrogat ignoreras ofta regeln att dessa inte kan användas, även om operationen av byte ordermark (BOM) förutsätter att U+FFFE aldrig kommer att vara den första kodpunkten i en text.

Exklusive surrogat och icke-tecken lämnar 1 111 998 kodpunkter tillgängliga för användning.

för privat användning anses vara tilldelade tecken, men de har ingen tolkning specificerad av Unicode-standarden, så varje utbyte av sådana tecken kräver en överenskommelse mellan avsändare och mottagare om deras tolkning. Det finns tre områden för privat användning i Unicode-kodutrymmet:

  • Privat användningsområde: U+E000–U+F8FF (6 400 tecken),
  • Kompletterande privat användningsområde-A: U+F0000–U+FFFFD (65 534 tecken),
  • Kompletterande privat användningsområde-B: U+100000–U+10FFFD (65 534 tecken).

Grafiska tecken är tecken som definieras av Unicode för att ha speciell semantik och antingen har en synlig glyfform eller representerar ett synligt mellanslag. Från och med Unicode 15.0 finns det 149 014 grafiska tecken.

Formattecken är tecken som inte har ett synligt utseende, men som kan ha en effekt på utseendet eller beteendet hos intilliggande tecken. Till exempel U+200C ZERO WIDTH NON-JOINER och U+200D ZERO WIDTH JOINER användas för att ändra standardformningsbeteendet för intilliggande tecken (t.ex. för att förhindra ligaturer eller begära ligaturbildning). Det finns 172 formattecken i Unicode 15.0.

Sextiofem kodpunkter (U+0000–U+001F och U+007F–U+009F) är reserverade som kontrollkoder och motsvarar kontrollkoderna C0 och C1 som definieras i ISO/IEC 6429 . U+0009 (Tab), U+000A (Line Feed) och U+000D (Carriage Return) används ofta i Unicode-kodade texter. I praktiken är C1-kodpunkterna ofta felaktigt översatta ( mojibake ) som de äldre Windows-1252 -tecken som används av vissa engelska och västeuropeiska texter.

Grafiska tecken, formattecken, kontrollkodtecken och tecken för privat användning kallas gemensamt för tilldelade tecken . Reserverade kodpunkter är de kodpunkter som är tillgängliga för användning, men som ännu inte är tilldelade. Från och med Unicode 15.0 finns det 825 279 reserverade kodpunkter.

Abstrakta karaktärer

Uppsättningen av grafiska tecken och formattecken som definieras av Unicode motsvarar inte direkt repertoaren av abstrakta tecken som kan representeras under Unicode. Unicode kodar tecken genom att associera ett abstrakt tecken med en viss kodpunkt. Alla abstrakta tecken är dock inte kodade som ett enda Unicode-tecken, och vissa abstrakta tecken kan representeras i Unicode av en sekvens av två eller flera tecken. Till exempel en latinsk liten bokstav "i" med en ogonek , en punkt ovanför och en akut accent , som krävs på litauiska , representeras av teckensekvensen U+012F, U+0307, ​​U+0301. Unicode upprätthåller en lista med unikt namngivna teckensekvenser för abstrakta tecken som inte är direkt kodade i Unicode.

Alla tecken för grafik, format och privat användning har ett unikt och oföränderligt namn med vilket de kan identifieras. Denna oföränderlighet har garanterats sedan Unicode version 2.0 av namnstabilitetspolicyn. I de fall namnet är allvarligt defekt och missvisande, eller har ett allvarligt typografiskt fel, kan ett formellt alias definieras, och ansökningar uppmuntras att använda det formella aliaset i stället för det officiella teckennamnet. Till exempel, U+A015 YI STAVELSE WU har det formella aliaset YI STAVELSE ITERATIONSMARK och U+FE18 PRESENTATIONSFORMULÄR FÖR VERTIKAL HÖGER VIT LENTICULAR BRA KC ET ( sic ) har det formella aliaset PRESENTATIONSFORM FÖR VERTICAL RIGHT WHITE LENTICULAR BRA CK ET .

Färdiggjorda kontra sammansatta karaktärer

Unicode innehåller en mekanism för att modifiera tecken som avsevärt utökar den stödda glyph-repertoaren. Detta täcker användningen av att kombinera diakritiska tecken som kan läggas till efter bastecknet av användaren. Flera kombinerande diakritiska tecken kan appliceras samtidigt på samma tecken. Unicode innehåller också förkomponerade versioner av de flesta bokstavs-/diakritiska kombinationer vid normal användning. Dessa gör konverteringen till och från äldre kodningar enklare och tillåter applikationer att använda Unicode som ett internt textformat utan att behöva implementera att kombinera tecken. Till exempel é representeras i Unicode som U+ 0065 ( LATINSK LITEN BOKSTAV E ) följt av U+0301 ( KOMBINERAR AKUT ACCENT ), men det kan också representeras som det förkomponerade tecknet U+00E9 ( LATINSK LITEN BOKSTAV E MED AKUT ) . Således har användare i många fall flera sätt att koda samma tecken. För att hantera detta tillhandahåller Unicode mekanismen för kanonisk ekvivalens .

Ett exempel på detta uppstår med Hangul , det koreanska alfabetet. Unicode tillhandahåller en mekanism för att komponera Hangul-stavelser med sina individuella underkomponenter, känd som Hangul Jamo . Men det ger också 11 172 kombinationer av förkomponerade stavelser gjorda av den vanligaste jamoen.

CJK -tecken har för närvarande endast koder för sin förkomponerade form. Ändå består de flesta av dessa karaktärer av enklare element (kallade radikaler ), så i princip kunde Unicode ha dekomponerat dem som det gjorde med Hangul. Detta skulle avsevärt ha minskat antalet erforderliga kodpunkter, samtidigt som det tillåts visning av praktiskt taget alla tänkbara tecken (vilket skulle kunna undanröja några av problemen som orsakas av Han-föreningen ). En liknande idé används av vissa inmatningsmetoder , som Cangjie och Wubi . Men försök att göra detta för teckenkodning har snubblat över det faktum att kinesiska tecken inte sönderfaller så enkelt eller så regelbundet som Hangul gör.

En uppsättning radikaler tillhandahölls i Unicode 3.0 (CJK-radikaler mellan U+2E80 och U+2EFF, KangXi-radikaler i U+2F00 till U+2FDF och ideografiska beskrivningstecken från U+2FF0 till U+2FFB), men Unicode-standarden (kap. 12.2 i Unicode 5.2) varnar för att använda ideografiska beskrivningssekvenser som en alternativ representation för tidigare kodade tecken:

Denna process skiljer sig från en formell kodning av en ideograf. Det finns ingen kanonisk beskrivning av okodade ideografer; det finns ingen semantik tilldelad beskrivna ideografer; det finns ingen likvärdighet definierad för beskrivna ideografer. Begreppsmässigt är ideografiska beskrivningar mer besläktade med den engelska frasen "an 'e' with a acute accent on it" än med teckensekvensen <U+0065, U+0301>.

Ligaturer

Devanāgarī ddhrya -ligaturen (द् + ध् + र् + य = द्ध्र्य ) av JanaSanskritSans
الا Den arabiska lām - alif ligaturen ( ل ‎+ <a i=8>‎ ا ‎= <a i=10>‎ لا )

Många skript, inklusive arabiska och Devanāgarī , har speciella ortografiska regler som kräver att vissa kombinationer av bokstavsformer kombineras till speciella ligaturformer . Reglerna för ligaturbildning kan vara ganska komplexa och kräver speciella skriptformande teknologier som ACE (Arabic Calligraphic Engine av DecoType på 1980-talet och som användes för att generera alla arabiska exempel i de tryckta utgåvorna av Unicode Standard), som blev beviset koncept för OpenType (av Adobe och Microsoft), Graphite (av SIL International ), eller AAT (av Apple).

Instruktioner är också inbäddade i teckensnitt för att berätta för operativsystemet hur man korrekt matar ut olika teckensekvenser. En enkel lösning på placeringen av kombinationsmärken eller diakritiska tecken är att tilldela märkena en bredd på noll och placera själva glyfen till vänster eller höger om vänster sidolager (beroende på riktningen för skriptet de är avsedda att användas med). Ett märke som hanteras på detta sätt kommer att visas över vilket tecken som helst som föregår det, men kommer inte att justera sin position i förhållande till bredden eller höjden på basglyfen; det kan vara visuellt besvärligt och det kan överlappa vissa glyfer. Verklig stapling är omöjlig, men kan approximeras i begränsade fall (t.ex. thailändska toppkombinerande vokaler och tonmärken kan bara vara på olika höjder till att börja med). I allmänhet är detta tillvägagångssätt endast effektivt i teckensnitt med ett avstånd, men kan användas som en reservåtergivningsmetod när mer komplexa metoder misslyckas.

Standardiserade delmängder

Flera delmängder av Unicode är standardiserade: Microsoft Windows sedan Windows NT 4.0 stöder WGL-4 med 657 tecken, vilket anses stödja alla samtida europeiska språk med latinska, grekiska eller kyrilliska skrift. Andra standardiserade delmängder av Unicode inkluderar de flerspråkiga europeiska delmängderna: MES-1 (endast latinska skript, 335 tecken), MES-2 (latinska, grekiska och kyrilliska 1062 tecken) och MES-3A & MES-3B (två större delmängder, visas inte här). Observera att MES-2 inkluderar alla tecken i MES-1 och WGL-4.

Standarden DIN 91379 specificerar en undergrupp av Unicode-bokstäver, specialtecken och sekvenser av bokstäver och diakritiska tecken för att tillåta korrekt representation av namn och för att förenkla datautbytet i Europa. Denna specifikation stöder alla officiella språk i EU- länder samt de officiella språken i Island, Liechtenstein, Norge och Schweiz, och även de tyska minoritetsspråken. För att tillåta translitterering av namn i andra skriftsystem till latinsk skrift enligt relevanta ISO-standarder tillhandahålls alla nödvändiga kombinationer av basbokstäver och diakritiska tecken.

WGL-4 , MES-1 och MES-2
Rad Celler Område(n)
00 20–7E Grundläggande latin (00–7F)
A0–FF Latin-1-tillägg (80–FF)
01 00–13, 14–15, 16–2B, 2C–2D, 2E–4D, 4E–4F, 50–7E, 7F Latin Extended-A (00–7F)
8F, 92, B7, DE-EF, FA–FF Latin Extended-B (80–FF ... )
02 18–1B, 1E–1F Latin Extended-B ( ... 00–4F)
59, 7C, 92 IPA-tillägg (50–AF)
BB–BD, C6, C7, C9, D6, D8–DB, DC, DD, DF, EE Avståndsmodifierande bokstäver (B0–FF)
03 74–75, 7A, 7E, 84–8A, 8C, 8E–A1, A3–CE, D7, DA–E1 Grekiska (70–FF)
04 00–5F, 90–91, 92–C4, C7–C8, CB–CC, D0–EB, EE–F5, F8–F9 Kyrillisk (00–FF)
1E 02–03, 0A–0B, 1E–1F, 40–41, 56–57, 60–61, 6A–6B, 80–85, 9B, F2–F3 Latin Extended Extra (00–FF)
1F 00–15, 18–1D, 20–45, 48–4D, 50–57, 59, 5B, 5D, 5F–7D, 80–B4, B6–C4, C6–D3, D6–DB, DD–EF, F2–F4, F6–FE Greek Extended (00–FF)
20 13–14, 15, 17, 18–19, 1A–1B, 1C–1D, 1E, 20–22, 26, 30, 32–33, 39–3A, 3C, 3E, 44, 4A Allmän interpunktion (00–6F)
7F , 82 Upphöjda och nedsänkta (70–9F)
A3–A4, A7, AC, AF Valutasymboler (A0–CF)
21 05, 13, 16, 22, 26, 2E Bokstavsliknande symboler (00–4F)
5B–5E Nummerformulär (50–8F)
90–93, 94–95, A8 Pilar (90–FF)
22 00, 02, 03, 06, 08–09, 0F, 11–12, 15, 19–1A, 1E–1F, 27–28, 29, 2A, 2B, 48, 59, 60–61, 64–65, 82–83, 95, 97 Matematiska operatorer (00–FF)
23 02, 0A, 20–21, 29–2A Diverse tekniska (00–FF)
25 00, 02, 0C, 10, 14, 18, 1C, 24, 2C, 34, 3C, 50–6C Lådteckning (00–7F)
80, 84, 88, 8C, 90–93 Blockelement (80–9F)
A0–A1, AA–AC, B2, BA, BC, C4, CA–CB, CF, D8–D9, E6 Geometriska former (A0–FF)
26 3A–3C, 40, 42, 60, 63, 65–66, 6A, 6B Diverse symboler (00–FF)
F0 (01–02) Privat användningsområde (00–FF ...)
FB 01–02 Alfabetiska presentationsformulär (00–4F)
FF FD Specialerbjudanden

Återgivning av programvara som inte kan bearbeta ett Unicode-tecken på lämpligt sätt visar det ofta som en öppen rektangel, eller Unicode " ersättningstecken " (U+FFFD, �), för att indikera positionen för det okända tecknet. Vissa system har gjort försök att ge mer information om sådana karaktärer. Apples Last Resort-teckensnitt kommer att visa en ersättningsglyph som indikerar Unicode-intervallet för tecknet, och SIL Internationals Unicode Fallback-teckensnitt kommer att visa en ruta som visar tecknets hexadecimala skalära värde.

Kartläggning och kodningar

Flera mekanismer har specificerats för att lagra en serie kodpunkter som en serie byte.

Unicode definierar två mappningsmetoder: Unicode Transformation Format (UTF)-kodningar och Universal Coded Character Set (UCS)-kodningar. En kodning mappar (möjligen en delmängd av) intervallet av Unicode- kodpunkter till sekvenser av värden i ett intervall med fast storlek, så kallade kodenheter . Alla UTF-kodningar avbildar kod pekar på en unik sekvens av byte. Siffrorna i kodningarnas namn anger antalet bitar per kodenhet (för UTF-kodningar) eller antalet byte per kodenhet (för UCS-kodningar och UTF-1 ). UTF-8 och UTF-16 är de vanligaste kodningarna. UCS-2 är en föråldrad delmängd av UTF-16; UCS-4 och UTF-32 är funktionellt likvärdiga.

UTF-kodningar inkluderar:

  • UTF-8 , använder en till fyra byte för varje kodpunkt, maximerar kompatibiliteten med ASCII
  • UTF-EBCDIC , liknande UTF-8 men designad för kompatibilitet med EBCDIC (inte en del av Unicode Standard )
  • UTF-16 , använder en eller två 16-bitars kodenheter per kodpunkt, kan inte koda surrogat
  • UTF-32 , använder en 32-bitars kodenhet per kodpunkt

UTF-8 använder en till fyra byte per kodpunkt och, eftersom den är kompakt för latinska skript och ASCII-kompatibel, tillhandahåller den de facto standardkodningen för utbyte av Unicode-text. Den används av FreeBSD och de senaste Linux-distributionerna som en direkt ersättning för äldre kodningar i allmän texthantering.

UCS-2- och UTF-16-kodningarna anger Unicode- byteordermärket (BOM) för användning i början av textfiler, som kan användas för byteordningsdetektering (eller byteendiannessdetektering ). BOM, kodpunkt U+FEFF, har den viktiga egenskapen att det är entydigt vid byteomordning, oavsett vilken Unicode-kodning som används; U+FFFE (resultatet av byte-byte U+FEFF) är inte lika med ett lagligt tecken, och U+FEFF på andra ställen än i början av texten förmedlar det noll-bredda non-break-utrymmet (ett tecken utan utseende och ingen annan effekt än att förhindra bildandet av ligaturer ).

  Samma tecken omvandlat till UTF-8 blir bytesekvensen EF BB BF . Unicode-standarden tillåter att BOM "kan fungera som signatur för UTF-8-kodad text där teckenuppsättningen är omarkerad". Vissa mjukvaruutvecklare har använt det för andra kodningar, inklusive UTF-8, i ett försök att skilja UTF-8 från lokala 8-bitars teckentabeller . Men RFC 3629 , UTF-8-standarden, rekommenderar att byteordningsmärken förbjuds i protokoll som använder UTF-8, men diskuterar de fall där detta kanske inte är möjligt. Dessutom innebär den stora begränsningen av möjliga mönster i UTF-8 (det kan till exempel inte finnas några ensamma byte med den höga bituppsättningen) att det bör vara möjligt att skilja UTF-8 från andra teckenkodningar utan att förlita sig på BOM.

I UTF-32 och UCS-4 fungerar en 32-bitars kodenhet som en ganska direkt representation av varje teckens kodpunkt (även om endianiteten, som varierar mellan olika plattformar, påverkar hur kodenheten manifesterar sig som en bytesekvens). I de andra kodningarna kan varje kodpunkt representeras av ett variabelt antal kodenheter. UTF-32 används ofta som en intern representation av text i program (i motsats till lagrad eller överförd text), eftersom varje Unix-operativsystem som använder gcc- kompilatorerna för att generera programvara använder det som standard " wide character " " kodning. Vissa programmeringsspråk, som Seed7 , använder UTF-32 som intern representation för strängar och tecken. Senaste versioner av programmeringsspråket Python (som börjar med 2.2) kan också konfigureras för att använda UTF-32 som representation för Unicode-strängar , effektivt sprider sådan kodning i högnivåkodad programvara.

Punycode , en annan kodningsform, möjliggör kodning av Unicode-strängar till den begränsade teckenuppsättningen som stöds av det ASCII -baserade Domain Name System (DNS). Kodningen används som en del av IDNA , som är ett system som möjliggör användning av internationella domännamn i alla skript som stöds av Unicode. Tidigare och nu historiska förslag inkluderar UTF-5 och UTF-6 .

GB18030 är en annan kodningsform för Unicode, från Standardization Administration of China . Det är den officiella karaktärsuppsättningen för Folkrepubliken Kina ( PRC). BOCU-1 och SCSU är Unicode-komprimeringsscheman. April Fools' Day RFC 2005 specificerade två parodi UTF-kodningar, UTF-9 och UTF-18 .

Adoption

Unicode, i form av UTF-8 , har varit den vanligaste kodningen för World Wide Web sedan 2008. Den har nästan universell användning, och mycket av innehållet som inte är UTF-8 finns i andra Unicode-kodningar, t.ex. UTF -16 . Från och med 2023 står UTF-8 för i genomsnitt 97,8 % av alla webbsidor (och 987 av de 1 000 högst rankade webbsidorna). Även om många sidor bara använder ASCII- tecken för att visa innehåll, designades UTF-8 med 8-bitars ASCII som en delmängd och nästan inga webbplatser deklarerar nu att deras kodning endast är ASCII istället för UTF-8. Över en tredjedel av de spårade språken har 100 % UTF-8-användning.

  Alla internetprotokoll som underhålls av Internet Engineering Task Force , t.ex. FTP , har krävt stöd för UTF-8 sedan publiceringen av RFC 2277 1998, som specificerade att alla IETF-protokoll "MÅSTE kunna använda teckenuppsättningen UTF-8".

Operativsystem

Unicode har blivit det dominerande systemet för intern bearbetning och lagring av text. Även om en hel del text fortfarande lagras i äldre kodningar, används Unicode nästan uteslutande för att bygga nya informationsbehandlingssystem. Tidiga användare tenderade att använda UCS-2 (den fasta tvåbyte föråldrade föregångaren till UTF-16) och flyttade senare till UTF-16 (den nuvarande standarden med variabel längd), eftersom detta var det minst störande sättet att lägga till stöd för icke-BMP-tecken. Det mest kända sådana systemet är Windows NT (och dess ättlingar, 2000 , XP , Vista , 7 , 8 , 10 och 11 ), som använder UTF-16 som enda interna teckenkodning. Java- och .NET- bytecode-miljöerna, macOS och KDE använder det också för intern representation. Partiellt stöd för Unicode kan installeras på Windows 9x genom Microsoft Layer for Unicode .

UTF-8 (ursprungligen utvecklad för Plan 9 ) har blivit huvudlagringskodningen på de flesta Unix-liknande operativsystem (även om andra också används av vissa bibliotek) eftersom det är en relativt enkel ersättning för traditionella utökade ASCII- teckenuppsättningar. UTF-8 är också den vanligaste Unicode-kodningen som används i HTML- dokument på World Wide Web .

Flerspråkiga textrenderingsmotorer som använder Unicode inkluderar Uniscribe och DirectWrite för Microsoft Windows, ATSUI och Core Text för macOS och Pango för GTK+ och GNOME -skrivbordet.

Inmatningsmetoder

Eftersom tangentbordslayouter inte kan ha enkla tangentkombinationer för alla tecken, tillhandahåller flera operativsystem alternativa inmatningsmetoder som ger tillgång till hela repertoaren.

ISO/IEC 14755 , som standardiserar metoder för att mata in Unicode-tecken från deras kodpunkter, specificerar flera metoder. Det finns Basic-metoden , där en startsekvens följs av den hexadecimala representationen av kodpunkten och slutsekvensen . Det finns också en skärmvalsinmatningsmetod specificerad, där tecknen listas i en tabell på en skärm, till exempel med ett teckenkartaprogram.

Onlineverktyg för att hitta kodpunkten för en känd karaktär inkluderar Unicode Lookup av Jonathan Hedley och Shapecatcher av Benjamin Milde. I Unicode Lookup anger man en söknyckel (t.ex. "bråk"), och en lista med motsvarande tecken med deras kodpunkter returneras. I Shapecatcher, baserat på Shape-kontext , ritar man tecknet i en ruta och en lista med tecken som approximerar ritningen, med deras kodpunkter, returneras.

E-post

MIME definierar två olika mekanismer för att koda icke-ASCII-tecken i e-post , beroende på om tecknen finns i e-posthuvuden (som "Ämne:") eller i meddelandets text; i båda fallen identifieras den ursprungliga teckenuppsättningen samt en överföringskodning. För e-postöverföring av Unicode rekommenderas UTF-8- teckenuppsättningen och Base64 eller överföringskodningen Quoted-printable , beroende på om mycket av meddelandet består av ASCII tecken. Detaljerna för de två olika mekanismerna specificeras i MIME-standarderna och är i allmänhet dolda för användare av e-postprogramvara.

IETF har definierat ett ramverk för internationaliserad e-post med UTF-8, och har uppdaterat flera protokoll i enlighet med det ramverket.

Antagandet av Unicode i e-post har gått mycket långsamt. [ citat behövs ] Viss östasiatisk text är fortfarande kodad i kodningar som ISO-2022 , och vissa enheter, såsom mobiltelefoner [ citat behövs ] , kan fortfarande inte hantera Unicode-data korrekt. Supporten har dock blivit bättre. Många stora gratis e-postleverantörer som Yahoo! Mail , Gmail och Outlook.com stöder det.

webb

Alla W3C- rekommendationer har använt Unicode som sin dokumentteckenuppsättning sedan HTML 4.0. Webbläsare har stödt Unicode, särskilt UTF-8, i många år. Det brukade vara visningsproblem som främst berodde på teckensnittsrelaterade problem; t.ex. v6 och äldre av Microsoft Internet Explorer återgav inte många kodpunkter om de inte uttryckligen uppmanades att använda ett teckensnitt som innehåller dem.

Även om syntaxregler kan påverka ordningen i vilken tecken tillåts visas, innehåller XML- dokument (inklusive XHTML ) per definition tecken från de flesta Unicode-kodpunkterna, med undantag av:

  • de flesta av C0-kontrollkoderna ,
  • de permanent otilldelade kodpunkterna D800–DFFF,
  • FFFE eller FFFF.

HTML-tecken manifesteras antingen direkt som byte enligt dokumentets kodning, om kodningen stöder dem, eller så kan användare skriva dem som numeriska teckenreferenser baserat på tecknets Unicode-kodpunkt. Till exempel referenserna &#916; , &#1049; , &#1511; , &#1605; , &#3671; , &#12354; , &#21494; , &#33865; , och &#47568; (eller samma numeriska värden uttryckta i hexadecimal, med &#x som prefix) ska visas i alla webbläsare som Δ, Й, K ,م, ๗, あ, 叶, 葉 och 말.

När du anger URI:er , till exempel som URL:er i HTTP- förfrågningar, måste icke-ASCII-tecken vara procentkodade .

Teckensnitt

Unicode handlar i princip inte om typsnitt i sig , eftersom de ser dem som implementeringsval. Varje given karaktär kan ha många allografer , från vanligare fetstil, kursiv och basbokstav till komplexa dekorativa stilar. Ett teckensnitt är "Unicode-kompatibelt" om glyferna i teckensnittet kan nås med hjälp av kodpunkter definierade i Unicode-standarden. Standarden anger inte ett minsta antal tecken som måste inkluderas i teckensnittet; vissa typsnitt har en ganska liten repertoar.

Gratis- och butiksteckensnitt baserade på Unicode är allmänt tillgängliga, eftersom TrueType och OpenType stöder Unicode (och Web Open Font Format (WOFF och WOFF2 ) är baserad på dessa). Dessa teckensnittsformat mappar Unicode-kodpunkter till glyfer, men OpenType- och TrueType-teckensnittsfiler är begränsade till 65 535 glyfer. Samlingsfiler tillhandahåller en "gap mode"-mekanism för att övervinna denna gräns i en enda teckensnittsfil. (Varje typsnitt i samlingen har dock fortfarande gränsen på 65 535.) En TrueType Collection-fil skulle vanligtvis ha filtillägget ".ttc".

tusentals typsnitt på marknaden, men färre än ett dussin typsnitt – ibland beskrivna som "pan-Unicode"-teckensnitt – försöker stödja majoriteten av Unicodes teckenrepertoar. Istället Unicode-baserade typsnitt fokuserar vanligtvis på att endast stödja grundläggande ASCII och särskilda skript eller uppsättningar av tecken eller symboler. Flera skäl motiverar detta tillvägagångssätt: applikationer och dokument behöver sällan återge tecken från mer än ett eller två skrivsystem; typsnitt tenderar att kräva resurser i datormiljöer; och operativsystem och applikationer visar ökande intelligens när det gäller att hämta glyfinformation från separata teckensnittsfiler efter behov, dvs. teckensnittsersättning . Dessutom är det en monumental uppgift att utforma en konsekvent uppsättning renderingsinstruktioner för tiotusentals glyfer; en sådan satsning passerar poängen med minskande avkastning för de flesta typsnitt.

Nya rader

Unicode åtgärdar delvis newline -problemet som uppstår när man försöker läsa en textfil på olika plattformar. Unicode definierar ett stort antal tecken som överensstämmande applikationer ska känna igen som radavslutare.

När det gäller den nya linjen introducerade Unicode U+2028 LINE SEPARATÖR och U+2029 PARAGRAPH SEPARATOR . Detta var ett försök att tillhandahålla en Unicode-lösning för att koda stycken och rader semantiskt, vilket potentiellt skulle ersätta alla olika plattformslösningar. Genom att göra det ger Unicode en väg runt de historiska plattformsberoende lösningarna. Ändå är det få om några Unicode-lösningar som har antagit dessa Unicode-rad- och styckeseparatorer som de enda kanoniska radsluttecken. Ett vanligt tillvägagångssätt för att lösa detta problem är dock genom nylinjenormalisering. Detta uppnås med Kakaotextsystem i Mac OS X och även med W3C XML- och HTML-rekommendationer. I detta tillvägagångssätt omvandlas varje möjlig nyradstecken internt till en gemensam nyradslinje (vilket man egentligen inte spelar någon roll eftersom det är en intern operation bara för rendering). Med andra ord kan textsystemet korrekt behandla tecknet som en nyrad, oavsett ingångens faktiska kodning.

frågor

Karaktärsförening

Han enande

Han-enandet (identifieringen av former i de östasiatiska språken som man kan behandla som stilistiska varianter av samma historiska karaktär) har blivit en av de mest kontroversiella aspekterna av Unicode, trots närvaron av en majoritet av experter från alla tre regionerna i Ideographic Research Group (IRG), som ger råd till konsortiet och ISO om tillägg till repertoaren och om enande av Han.

Unicode har kritiserats för att ha misslyckats med att separat koda äldre och alternativa former av kanji , vilket, hävdar kritiker, komplicerar bearbetningen av gamla japanska och ovanliga japanska namn. Detta beror ofta på att Unicode kodar tecken snarare än glyfer (de visuella representationerna av grundtecknet som ofta varierar från ett språk till ett annat). Enhet av glyfer leder till uppfattningen att språken själva, inte bara den grundläggande karaktärsrepresentationen, håller på att slås samman. [ förtydligande behövs ] Det har gjorts flera försök att skapa alternativa kodningar som bevarar de stilistiska skillnaderna mellan kinesiska, japanska och koreanska tecken i motsats till Unicodes policy för enande av Han. Ett exempel på en är TRON (även om den inte är allmänt antagen i Japan, det finns vissa användare som behöver hantera historisk japansk text och föredrar den).

Även om repertoaren på färre än 21 000 Han-tecken i den tidigaste versionen av Unicode till stor del var begränsad till tecken i vanlig modern användning, inkluderar Unicode nu mer än 97 000 Han-tecken, och arbetet fortsätter med att lägga till tusentals fler historiska och dialektala tecken som används i Kina, Japan, Korea, Taiwan och Vietnam.

Modern teckensnittsteknik ger ett sätt att ta itu med den praktiska frågan om att behöva skildra en enhetlig Han-karaktär i form av en samling alternativa glyferepresentationer. OpenType -tabellen 'locl' låter en renderare välja en annan glyf för ett tecken baserat på textens lokalitet. Unicode -variationssekvenserna kan också tillhandahålla annotering i text av önskat glyph-val, men inga sådana sekvenser för Han-tecken har standardiserats.

Kursiva eller kursiva tecken på kyrilliska

Olika kyrilliska tecken visas med upprättstående, snett och kursiv omväxlande former

Om de lämpliga glyferna för tecken i samma skript skiljer sig endast i kursiv stil, har Unicode generellt förenat dem, vilket kan ses i jämförelsen mellan en uppsättning av sju teckens kursiv glyfer som vanligtvis förekommer på ryska, traditionella bulgariska, makedonska och serbiska texter till höger, vilket betyder att skillnaderna visas genom smart typsnittsteknik eller manuellt byte av typsnitt. Samma OpenType 'locl'-teknik används.

Mappning till äldre teckenuppsättningar

Unicode designades för att tillhandahålla kod-punkt-för-kod-punkt -formatkonvertering till och från alla befintliga teckenkodningar, så att textfiler i äldre teckenuppsättningar kan konverteras till Unicode och sedan tillbaka och få tillbaka samma fil, utan att använda kontextberoende tolkning. Det har inneburit att inkonsekventa äldre arkitekturer, som att kombinera diakritiska tecken och förkomponerade tecken , båda finns i Unicode, vilket ger mer än en metod för att representera viss text. Detta är mest uttalat i de tre olika kodningsformerna för koreanska Hangul . Sedan version 3.0 kan alla förkomponerade tecken som kan representeras av en kombinerande sekvens av redan befintliga tecken inte längre läggas till standarden för att bevara interoperabilitet mellan programvara som använder olika versioner av Unicode.

Injektiv mappningar måste tillhandahållas mellan tecken i befintliga äldre teckenuppsättningar och tecken i Unicode för att underlätta konvertering till Unicode och möjliggöra interoperabilitet med äldre programvara. Brist på konsistens i olika mappningar mellan tidigare japanska kodningar som Shift-JIS eller EUC-JP och Unicode ledde till oöverensstämmelse med formatomvandlingsfel , särskilt mappningen av tecknet JIS X 0208 '~' (1-33, WAVE DASH) , mycket använd i äldre databasdata, till antingen U+FF5E FULLWIDTH TILDE ( i Microsoft Windows ) eller U+301C WAVE DASH (andra leverantörer).

Vissa japanska datorprogrammerare protesterade mot Unicode eftersom det kräver att de separerar användningen av U+005C \ REVERSE SOLIDUS (omvänt snedstreck) och U+00A5 ¥ YEN SIGN , som mappades till 0x5C i JIS X 0201, och det finns en hel del äldre kod. med denna användning. (Denna kodning ersätter också tilde '~' 0x7E med makron '¯', nu 0xAF.) Separationen av dessa tecken finns i ISO 8859-1 , från långt före Unicode.

Indiska skript

Indiska skript som Tamil och Devanagari tilldelas var och en endast 128 kodpunkter, som matchar ISCII standard. Den korrekta återgivningen av Unicode Indic-text kräver omvandling av de lagrade logiska ordningstecken till visuell ordning och bildande av ligaturer (aka konjunkter) av komponenter. Vissa lokala forskare argumenterade för tilldelning av Unicode-kodpunkter till dessa ligaturer, vilket gick emot praxis för andra skrivsystem, även om Unicode innehåller vissa arabiska och andra ligaturer endast för bakåtkompatibilitetsändamål. Kodning av några nya ligaturer i Unicode kommer inte att ske, delvis på grund av att uppsättningen ligaturer är teckensnittsberoende och Unicode är en kodning oberoende av teckensnittsvariationer. Samma typ av problem uppstod för den tibetanska skriften 2003 när Kinas standardiseringsadministration föreslog kodning av 956 förkomponerade tibetanska stavelser, men dessa avvisades för kodning av den relevanta ISO-kommittén ( ISO/IEC JTC 1/SC 2 ) .

thailändska alfabet har kritiserats för sin ordning av thailändska tecken. Vokalerna เ, แ, โ, ใ, ไ som skrivs till vänster om föregående konsonant är i visuell ordning istället för fonetisk ordning, till skillnad från Unicode-representationerna av andra indiska skript. Denna komplikation beror på att Unicode ärvde Thai Industrial Standard 620 , som fungerade på samma sätt, och var det sätt som Thai alltid hade skrivits på tangentbord. Detta ordningsproblem komplicerar Unicode-sorteringsprocessen något, vilket kräver tabelluppslagningar för att ordna om thailändska tecken för sortering. Även om Unicode hade antagit kodning enligt talad ordning, skulle det fortfarande vara problematiskt att sammanställa ord i ordboksordning. Till exempel ordet แสดง [sa dɛːŋ] "perform" börjar med ett konsonantkluster "สด" (med en inneboende vokal för konsonanten "ส"), vokalen แ-, i talad ordning skulle komma efter ด, men i en ordbok, ordet är sammanställt som det är skrivet, med vokalen efter ส.

Kombinera karaktärer

Tecken med diakritiska tecken kan i allmänhet representeras antingen som ett enstaka förkomponerat tecken eller som en dekomponerad sekvens av en basbokstav plus ett eller flera icke-mellanrumstecken. Till exempel bör ḗ (förkomponerad e med makron och akut ovan) och ḗ (e följt av den kombinerande makron ovan och kombinera akut ovan) återges identiskt, båda visas som ett e med en makron och akut accent , men i praktiken utseende kan variera beroende på vilken renderingsmotor och typsnitt som används för att visa tecknen. Likaså underpunkter , efter behov i romanisering av Indic , kommer ofta att placeras felaktigt. [ citat behövs ] . Unicode-tecken som mappas till förkomponerade glyfer kan användas i många fall och på så sätt undvika problemet, men där inget förkomponerat tecken har kodats kan problemet ofta lösas genom att använda ett specialiserat Unicode-teckensnitt som Charis SIL som använder Graphite , OpenType ( ' gsub'), eller AAT -tekniker för avancerade renderingsfunktioner.

Anomalier

Unicode-standarden har infört regler för att garantera stabilitet. Beroende på hur strikt en regel är kan en ändring förbjudas eller tillåtas. Till exempel kan ett "namn" som ges till en kodpunkt inte och kommer inte att ändras. Men en "script"-egenskap är mer flexibel, enligt Unicodes egna regler. I version 2.0 ändrade Unicode många kodpunkts "namn" från version 1. I samma ögonblick uppgav Unicode att från och med då skulle ett tilldelat namn till en kodpunkt aldrig längre ändras. Detta innebär att när misstag publiceras kan dessa misstag inte korrigeras, även om de är triviala (som hände i ett fall med stavningen BRAKCET för BACKET i ett teckennamn). 2006 publicerades först en lista över anomalier i karaktärsnamn, och i juni 2021 fanns det 104 tecken med identifierade problem, till exempel:

  • U+2118 SCRIPT STORA P : Detta är en liten bokstav. Huvudstaden är U+1D4AB 𝒫 MATEMATISK SCRIPT HUVUDSTAD P .
  • U+034F ͏ KOMBINERING AV GRAPHEM JOINER : Sammanfogar inte grafem.
  • U+A015 YI STAVELSE WU : Detta är inte en Yi stavelse, utan ett Yi iterationstecken.
  • U+FE18 PRESENTATIONSFORMULÄR FÖR VERTIKAL HÖGER VIT LENTIKULAR KLASSE : parentes är felstavat. (Stavfel löses genom att använda Unicode-aliasnamn .)

Medan Unicode definierar skriptbeteckningen (namn) till " Phags Pa ", läggs ett bindestreck i det skriptets teckennamn: U+A840 PHAGS-PA BOKSTAV KA .

Säkerhetsproblem

Unicode har ett stort antal homoglyfer , av vilka många ser väldigt lika eller identiska med ASCII-bokstäver. Ersättning av dessa kan skapa en identifierare eller URL som ser korrekt ut, men som leder till en annan plats än förväntat, och kan också användas för att manipulera utdata från -system (natural language processing) . Begränsning kräver att dessa tecken inte tillåts, att de visas annorlunda eller att de löser sig till samma identifierare; allt detta är komplicerat på grund av den enorma och ständigt föränderliga uppsättningen av karaktärer.

En säkerhetsrådgivning släpptes 2021 från två forskare, en från University of Cambridge och den andra från samma och från University of Edinburgh , där de hävdar att BiDi-märkena kan användas för att få stora delar av koden att göra något annorlunda från vad de verkar göra. Problemet fick namnet " Trojan Source ". Som svar började kodredigerare markera märken för att indikera tvingade textriktningsändringar.

Se även

Anteckningar

Vidare läsning

externa länkar