Уникод
стандартни опции за интернет и управление From Wikipedia, the free encyclopedia
стандартни опции за интернет и управление From Wikipedia, the free encyclopedia
Уникод (на английски: Unicode) е стандарт в компютърната индустрия за кодиране, представяне и обработка на текст на повечето писмености в света. Той е разработен да реши проблемите, причинявани от едновременната употреба на голям брой несъвместими помежду си традиционни кодировки за различните езици. Стандартът се поддържа от Консорциума Уникод и през 2018 г. най-новата му версия 11.0 съдържа 137 439 знака и обхваща 146 писмености на съвременни и мъртви езици, както и много символи (например от математиката и инженерните дисциплини) и емоджита. Знаковият набор на Уникод е синхронизиран със стандарта ISO/IEC 10646 и кодовете в двата стандарта са еднакви.
За помощната страница вижте Уикипедия:Уникод. 
Стандартът Уникод се състои от комплект справочни таблици за кодовете, метод за кодиране и набор от стандартни знакови кодировки, комплект от еталонни файлове с данни, както и някои документи, свързани с изброените, например относно свойствата на знаците, правилата за нормализация, декомпозиция, визуализиране и ред на изписване на двупосочен текст (за правилно показване на текст със смесени посоки на изписване: от дясно наляво, като при арабски и иврит, и от ляво надясно).
Успехът на Уникод в обединяването на знаковите набори е довел до широкото му използване и доминиращо положение в интернационализацията и локализацията на компютърен софтуер. Стандартът се използва в множество съвременни технологии, включително съвременните операционни системи, XML, езици за програмиране и .NET Framework.
Уникод може да се прилага чрез различни кодировки. Стандартът дефинира UTF-8, UTF-16, UTF-32, а в употреба са и още няколко начина за кодиране. Най-често използваните кодировки са UTF-8, UTF-16 и UCS-2, предшественик на UTF-16.
При UTF-8, използвана в над 90% от уебсайтовете, за първите 128 кода се използва по един байт, а за останалите – до 4 байта.[1] Първите 128 кода от Уникод съвпадат с тези на ASCII, което означава, че всеки текст в ASCII е и в UTF-8.
При UCS-2 за всеки знак се използват два байта (16 бита), но така могат да се представят само първите 65 536 кода, които образуват групата Basic Multilingual Plane (BMP, Основна многоезична група). Тъй като са възможни общо 1 114 112 кода в 17 различни групи, а вече са дефинирани над 137 000 от тях, много от знаците в Уникод са извън обхвата на UCS-2. Затова тя се смята за остаряла, макар да е все още в широка употреба. UTF-16 разширява UCS-2, като използва същото 16-битово кодиране за BMP и 4-байтово – за останалите групи. Всеки текст в UCS-2, който не съдържа кодове в запазения диапазон U+D800–U+DFFF, представлява и валиден текст в UTF-16.
При UTF-32 (наричана още UCS-4) за всеки знак се използват 4 байта. Както и при UCS-2, броят байтове на знак е фиксиран, което улеснява индексирането им в паметта, но за разлика от UCS-2, с UTF-32 могат да се представят всички кодове в Уникод. Поради кодирането на всеки знак с четири байта обаче UTF-32 заема много повече памет от другите кодировки и не се използва широко.
Уникод е създаден с изричната цел да се превъзмогнат ограниченията на традиционните методи за кодиране на знаци, например дефинираните със стандарта ISO-8859, които се използват широко в различни страни на света, но до голяма степен остават несъвместими помежду си. Общ недостатък на много от традиционните знакови кодировки е, че позволяват двуезична компютърна обработка на текст (обикновено с латиница и местната писменост), но не и многоезична (компютърна обработка на произволни писмености, смесени една с друга).
Уникод, по замисъл, кодира същинските знаци – графеми и подобни на графема звена – а не техните вариантни глифове (графики). При китайските логограми това понякога води до противоречия при разграничаването на базовия знак от вариантните му глифове.
При обработка на текст ролята на Уникод е да предостави уникална кодова точка – число, а не глиф – за всеки знак. С други думи, Уникод представя знаците по абстрактен начин и оставя визуализацията им (размер, форма, шрифт или стил), на друг софтуер, например уеббраузър или текстообработваща програма. Тази проста задача обаче се усложнява заради компромиси, направени от проектантите на стандарта с надежда да насърчат по-бързото му разпространение.
Първите 256 кода са дефинирани идентично със съдържанието на ISO-8859-1, за да се улесни максимално конвертирането на съществуващ текст на латиница. Много по същество идентични знаци са кодирани няколко пъти с различни кодове, за да се запазят отличията, използвани от наследени кодировки, и така да се позволи преобразуване от тези кодировки към Уникод (и обратно) без загуба на информация. Например разделът с кодове за „форми с пълна ширина“ съдържа цяла латинска азбука, отделна от тази в главния раздел за латиница, защото в китайски, японски и корейски тези латински букви се изобразяват със същата ширина като логограмите, вместо с половин ширина.
Началото на Уникод е поставено през 1987 г., когато Джо Бекер от Ксерокс и Лий Колинс и Марк Дейвис от Епъл започват да проучват практическите аспекти на създаването на универсален знаков набор.[2] През август 1988 г. Джо Бекер публикува проект на предложение за „международна/многоезична система за кодиране на текстови знаци, временно наречена Уникод“. Той пояснява, че „името „Уникод“ е замислено да подсказва за уникална, единна, универсална (от англ. unique, unified, universal) система за кодиране“.[3]
В този документ, озаглавен „Уникод 88“, Бекер описва 16-битов модел на знаците:[3]
Уникод е предназначен да отговори на необходимостта от работещо, надеждно, многоезично кодиране на текст. Уникод може да бъде грубо описан като „широк ASCII“, разтеглен до 16 бита, за да обхване знаците на всички живи световни езици. При добре проектирана архитектура 16 бита за знак са повече от достатъчни за тази цел.
Неговата оригинална 16-битова архитектура се основава на предположението, че е необходимо кодиране само на писменостите и знаците в съвременна употреба:[3]
Уникод дава по-висок приоритет на осигуряването на полезност за в бъдеще, отколкото на опазването на отминали антики. Уникод е предназначен на първо място за знаците, публикувани в съвременен текст (например във всички вестници и списания, отпечатани в света през 1988 г.), чийто брой е несъмнено много под 214 = 16 384. Извън тези знаци в съвременна употреба, всички други могат да бъдат определени като морално остарели или рядко използвани; те са по-добри кандидати да бъдат регистрирани за лично ползване, отколкото да задръстват публичния списък на полезните Уникодове.
В началото на 1989 г. работната група, занимаваща се с Уникод, се разширява и вече включва и Кен Уистлър и Майк Кърнаган от Метафор, Карън Смит-Йошимура и Джоан Алипран от RLG, както и Глен Райт от Сън Майкросистъмс, а през 1990 г. към нея се присъединяват Мишел Зигнард и Асмус Фрайтаг от Майкрософт и Рик Макгоуън от NeXT. До края на 1990 г. по-голямата част от работата по определяне на съществуващи стандарти за кодиране на знаците е била завършена, и окончателният проект на Уникод е готов за представяне.
Консорциумът Уникод е учреден на 3 януари 1991 г. в Калифорния, а през октомври 1991 г. е публикуван първият том на стандарта Уникод. Вторият том, който обхваща и китайските логограми, е публикуван през юни 1992 г.
През 1996 г. с Уникод 2.0 е внедрен механизъм за сурогатни знаци, с който се премахва ограничението от 16 бита. Това увеличава капацитета на Уникод до над един милион кодови единици, позволявайки кодирането на много исторически писмености (например, египетски йероглифи) и хиляди рядко използвани или остарели знаци, чието кодиране се е смятало за ненужно. Сред знаците, първоначално непредвидени за включване в Уникод, са рядко използвани канджи или китайски логограми, много от които са част от имена на хора и места и въпреки рядката си употреба са много по-важни, отколкото се предвижда в оригиналната архитектура на Уникод.[4]
Уникод дефинира кодово пространство от 1 114 112 кодови точки (допустими числови стойности за представяне на знаци) в диапазона от 0hex до 10FFFFhex. Обикновено кодова точка на Уникод се посочва с изписване на „U+“, следвано от шестнадесетично число. За кодова точка в групата Basic Multilingual Plane (BMP) се използват четири цифри (например за латинската главна буква X използваме U+0058). За кодови точки извън BMP се използват пет или шест цифри.
Уникод се разделя на седемнадесет групи (на английски: planes), номерирани от 0 до 16:
Всяка кодова точка в BMP е достъпна като самостоятелна кодова единица в UTF-16 и може да се кодира с един, два или три байта в UTF-8. Кодовите точки в групите от 1 до 16 (Planes 1–16) са достъпни като сурогатни двойки в UTF-16 и се кодират с четири байта в UTF-8.
Във всяка група знаците са разпределени в блокове от логически свързани знаци. Въпреки че блоковете са с произволен размер, броят кодови точки в тях винаги е кратен на 16, а често и на 128. Знаците, необходими за дадена писменост, може да са пръснати в няколко различни блока.
Всяка кодова точка има свойство „Обща категория“ (на английски: General Category). Основните категории са: буква, комбиниращ или ограждащ знак, число, пунктуация, символ, разделител и друго. Всяка от тези категории има подразделения. В повечето случаи за точно задаване характеристиките на дадена кодова точка е необходимо да се използват и други свойства. Възможните общи категории са:
| Обща категория (свойство на знаците в Уникод) | |||||
|---|---|---|---|---|---|
| Стойност | Категория: главна, второстепенна | Основен тип | Присвоен знак | Брой (във версия 11.0) | Бележки |
| Буква (letter) | |||||
| Lu | Буква, горен регистър | Графичен | Знак | 1781 | |
| Ll | Буква, долен регистър | Графичен | Знак | 2145 | |
| Lt | Буква, заглавен регистър | Графичен | Знак | 31 | Лигатури, съдържащи главна буква, последвана от малка (напр. Dž, Lj, Nj и Dz) |
| Lm | Буква, модификатор | Графичен | Знак | 250 | |
| Lo | Буква, друга | Графичен | Знак | 121 212 | |
| Комбиниращ или ограждащ знак (mark) | |||||
| Mn | Знак, не интервал | Графичен | Знак | 1805 | |
| Mc | Знак, комбиниращ интервал | Графичен | Знак | 415 | |
| Me | Знак, ограждащ | Графичен | Знак | 13 | |
| Число (number) | |||||
| Nd | Число, десетична цифра | Графичен | Знак | 610 | Всички, и само те, имат свойство „Числов тип“ = De |
| Nl | Число, буква | Графичен | Знак | 236 | Числа, съставени от буквоподобни знаци (напр. римски цифри) |
| No | Число, друго | Графичен | Знак | 807 | Например обикновени дроби, цифри в горен индекс и долен индекс |
| Пунктуация (punctuation) | |||||
| Pc | Пунктуация, свързваща | Графичен | Знак | 10 | Включва "_" (долна черта) |
| Pd | Пунктуация, тире | Графичен | Знак | 24 | Включва няколко различни тирета |
| Ps | Пунктуация, отваряща | Графичен | Знак | 75 | Отварящи скоби |
| Pe | Пунктуация, затваряща | Графичен | Знак | 73 | Затварящи скоби |
| Pi | Пунктуация, начална кавичка | Графичен | Знак | 12 | Отваряща кавичка. Не включва „неутралните“ кавички от ASCII. Може да се държи като Ps или Pe в зависимост от употребата. |
| Pf | Пунктуация, завършваща кавичка | Графичен | Знак | 10 | Затваряща кавичка. Може да се държи като Ps или Pe в зависимост от употребата. |
| Po | Пунктуация, друга | Графичен | Знак | 584 | |
| Символ (symbol) | |||||
| Sm | Символ, математически | Графичен | Знак | 948 | Математически символи (напр. +, =, ×, ÷, √, ∊). Не включва скоби – те са в категориите Ps и Pe. Също не включва !, *, - и /, които въпреки честата си употреба в математиката се смятат основно за „пунктуация“. |
| Sc | Символ, валутен | Графичен | Знак | 57 | Валутни символи |
| Sk | Символ, модификатор | Графичен | Знак | 121 | |
| So | Символ, друг | Графичен | Знак | 5984 | |
| Разделител (separator) | |||||
| Zs | Разделител, интервал | Графичен | Знак | 17 | Включва интервал, но не и знак за табулация, връщане на каретката (CR) и нов ред (LF), които са Cc. |
| Zl | Разделител, ред | Форматиращ | Знак | 1 | Само U+2028, LINE SEPARATOR |
| Zp | Разделител, абзац | Форматиращ | Знак | 1 | Само U+2029, PARAGRAPH SEPARATOR |
| Други | |||||
| Cc | Друг, контролен | Контролен | Знак | 65 (никога няма да се промени) | Без име, <control> |
| Cf | Друг, форматиращ | Форматиращ | Знак | 152 | Включва меко тире, свързващи контролни знаци (zwnj и zwj), контролни знаци за двупосочен текст и знаци за отбелязване на език. |
| Cs | Друг, сурогатен | Сурогатен | Не (абстрактен) | 2048 (никога няма да се промени) | Без име, <surrogate> |
| Co | Друг, частно използване | Частно използване | Не (абстрактен) | Общо 137 468 (никога няма да се промени) (6400 в BMP, 131 068 в групи 15 – 16) | Без име, <private-use> |
| Cn | Друг, недефиниран | Не знак | Не | 66 (никога няма да се промени) | Без име, <noncharacter> |
| Запазен | Не | 837 091 | Без име, <reserved> | ||
Кодовите точки в диапазона между U+D800 и U+DBFF (общо 1024 на брой) се наричат старши сурогати (high-surogate code points], а тези между U+DC00 и U+DFFF (също 1024) – младши сурогати (low-surrogate code points). Старши сурогат и следващ го младши сурогат образуват сурогатна двойка, използвана в UTF-16 за представяне на кодовите точки над U+FFFF. Сурогатните кодови точки не могат да се използват по друг начин (това правило често се пренебрегва на практика, особено когато не се използва UTF-16).
За определен малък набор от кодови точки се гарантира, че никога няма да се използват за кодиране на знаци, макар че приложенията при желание могат да ги използват вътрешно. Тези не-знаци (noncharacters) са 66 на брой: U+FDD0–U+FDEF и всички кодови точки, завършващи на FFFE или FFFF (например U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, … U+10FFFE, U+10FFFF). Наборът от не-знаци е стабилен и никога няма да се разширява в бъдеще. Както и при сурогатите, правилото, че тези кодови точки не бива да се използват, често се игнорира, макар че за работата на маркера за ред на байтовете (BOM) се приема, че U+FFFE никога няма да бъде първа кодова точка в текст.
Като изключим сурогатите и не-знаците, остават 1 111 998 достъпни за употреба кодови точки.
За кодовите точки за частно използване се приема, че са им приписани знаци, но нямат зададена интерпретация в стандарта Уникод. Поради това обменът на подобни знаци изисква споразумение между подателя и получателя за интерпретацията им. В кодовото пространство на Уникод има три диапазона за частно използване:
Графичните знаци са такива, на които Уникод приписва определена семантика и или имат видима форма (глиф), или представляват видимо празно място. В Уникод 10.0 има 136 537 графични знака.
Форматиращите знаци са такива, които не се виждат сами по себе си, но може да влияят върху вида или поведението на съседните. Например U+200C (несъединител с нулева ширина, zwnj) и U+200D (съединител с нулева ширина, zwj) служат за променяне на подразбираната форма на съседни знаци (в частност потискане на лигатурите или налагане на лигатура). В Уникод 10.0 има 153 форматиращи знака.
Шейсет и пет кодови точки (U+0000–U+001F и U+007F–U+009F) са запазени като контролни кодове, отговарящи на дефинираните в ISO/IEC 6429 групи от контролни кодове C0 и C1. Кодовете U+0009 (знак за табулация, Tab), U+000A (нов ред, Line Feed) и U+000D (връщане на каретката, Carriage Return) се използват широко в текстове, кодирани с Уникод. На практика кодовите точки от групата C1 често представляват неправилно преобразувани знаци от остарялата кодировка CP-1252, използвана в някои текстове на английски и западноевропейски езици в Windows.
Графичните, форматиращите, контролните и частните знаци се наричат общо присвоени знаци (assigned characters). Запазени (reserved) са тези кодови точки, които са достъпни за използване, но още не са присвоени. В Уникод 11.0 има 837 091 запазени кодови точки.
Дефинираният от Уникод набор от графични и форматиращи знаци не отговаря пряко на съвкупността от възможните за представяне с Уникод абстрактни знаци. Уникод кодира знаците, асоциирайки абстрактен знак с конкретна кодова точка. Не всички абстрактни знаци обаче се кодират като един-единствен знак на Уникод и някои абстрактни знаци може да бъдат представени в Уникод като поредица от два или повече знака. Например малката латинска буква „i“ с огонек, точка отгоре и остро ударение, необходима за литовски език, се представя чрез поредицата U+012F, U+0307, U+301. Уникод поддържа списък от уникални по име поредици от знаци за тези от абстрактните знаци, които не се кодират пряко.
Всички графични, форматиращи и частно използвани знаци имат уникално и неизменно име, по което се идентифицират. Това се гарантира от Уникод след версия 2.0 чрез политиката за стабилност на имената (Name Stability). В случаи, в които името е дефектно или подвеждащо, или има сериозна типографска грешка, се формира официален псевдоним и програмите се насърчават да използват този псевдоним вместо официалното име на знака.
Консорциумът Уникод (Unicode Consortium) е нестопанска организация, която координира развитието на Уникод. Нейни пълноправни членове са повечето от най-големите софтуерни и хардуерни компании, заинтересовани от стандартите за обработка на текст, сред които Adobe Systems, Apple, Google, IBM, Microsoft, Oracle Corporation, Yahoo!, както и министерството на даренията и вероизповеданията в Оман.[5]
Консорциумът има амбициозната цел в даден момент да замени съществуващите знакови кодировки с Уникод и в частност с неговите стандартни схеми за кодиране UTF (Unicode Transformation Format), тъй като много от сегашните стандарти са ограничени по обем и обхват и са несъвместими с многоезични среди.
Уникод е разработен в сътрудничество с международната организация за стандартизация (International Organization for Standardization) и споделя знаковия си репертоар с ISO/IEC 10646: Universal Character Set. Уникод и ISO/IEC 10646 функционират по идентичен начин като знакови кодировки, но Уникод съдържа много повече информация за изпълнителите, разглеждайки подробно теми като побитово кодиране, сортиране и рендиране. В стандарта Уникод са изброени множество свойства на знаците, включително необходимите за поддръжката на двупосочен текст (bidirectional text). Двата стандарта използват леко различна терминология.
Консорциумът публикува стандарта Уникод (The Unicode Standard – ISVN 0-321-18578-1) за първи път през 1991 година и продължава да развива стандарти, базирани на този първоначален вариант. Последната версия на стандарта, Уникод 11.0, e публикувана през юни 2018 година и е достъпна на уебсайта на консорциума. Последната от главните версии (с номера x.0), която е публикувана на хартиен носител, е Уникод 5.0 (ISBN 0-321-48091-0). След Уникод 6.0 обаче стандартът повече не е публикуван във вид на книга. Единствено през 2012 година е обявено, че за основната спецификация на Уникод 6.1 ще бъде достъпна услуга отпечатване с меки корици в 692 страници. За разлика от предходните главни версии, достъпни на хартиени носители, отпечатваната по поръчка основна спецификация не включва таблици на кодовете и анекси, но целият стандарт, включително основната спецификация, е достъпен безплатно на уебсайта на Уникод.
Публикувани са много главни и второстепенни версии на стандарта Уникод. Версиите, които не включват промени в знаковия набор, се обозначават с трето число (например „версия 4.0.1“) и са пропуснати в таблицата по-долу.
| Версия | Дата | Книга | Съответен ISO/IEC 10646 Edition | Писмености | Знаци | |
|---|---|---|---|---|---|---|
| Общо | Съществени допълнения | |||||
| 1.0.0 | Октомври 1991 | ISBN 0-201-56788-1(Vol.1) | 24 | 7161 | Оригиналният набор покрива арабски, арменски, бенгалски, бопомофо, кирилица, деванагари, грузински, гръцки и коптски, гуджарати, гурмукхи, хангъл, иврит, хирагана, каннада, катакана, лаоски, латински, малаялам, ория, тамилски, телугу, тайски и тибетски. | |
| 1.0.1 | Юни 1992 | ISBN 0-201-60845-6(Vol.2) | 25 | 28 359 | Дефиниран е първоначалният набор от 20 902 унифицирани идеограми за китайски, японски и корейски (CJK). | |
| 1.1 | Юни 1993 | ISO/IEC 10646 – 1:1993 | 24 | 34 233 | Добавени са нови 4306 срички от хангъл към предишните 2305. Премахнат е тибетският. | |
| 2.0 | Юли 1996 | ISBN 0-201-48345-9 | ISO/IEC 10646 – 1:1993 плюс изменения 5, 6 и 7 | 25 | 38 950 | Премахнати са първоначалните срички на хангъл и са добавени нови 11 172 в нов диапазон. Тибетският е върнат обратно, но в нов диапазон и с нов знаков набор. Въвежда се механизъм за сурогатни знаци. Добавени са и нови частни области, Plane 15 и Plane 16. |
| 2.1 | Май 1998 | ISO/IEC 10646 – 1:1993 плюс изменения 5, 6 и 7, както и два знака от изменение 18 | 25 | 38 952 | Добавени са знакът на еврото и знак за заместване на обект. | |
| 3.0 | Септември 1999 | ISBN 0-201-61633-5 | ISO/IEC 10646 – 1:2000 | 38 | 49 259 | Добавени са чероки, етиопски, кхмерски, монголски, бирмански, огам, руническа азбука, синхалски, сирийска азбука, таана, обединени канадски аборигенски срички, срички на йи и набор от брайлови символи. |
| 3.1 | Март 2001 | ISO/IEC 10646 – 1:2000
ISO/IEC 10646 – 2:2001 |
41 | 94 205 | Добавени са дезерет, готически и староиталийски, както и набор от символи за западната музика и византийската музика и 42 711 идеограми за CJK. | |
| 3.2 | Март 2002 | ISO/IEC 10646 – 1:2000 плюс изменение 1
ISO/IEC 10646 – 2:2001 |
45 | 95 221 | Добавени са филипинските писмености бухид, хануну, тагалог и тагбануа. | |
| 4.0 | Април 2003 | ISBN 0-321-18578-1 | ISO/IEC 10646:2003 | 52 | 96 447 | Добавени са кипърска сричкова азбука, лимбу, линеар B, османия, знаците на Бърнард Шоу (Shavian), тай ле, угаритски, както и хексаграмни символи. |
| 4.1 | Март 2005 | ISO/IEC 10646:2003 плюс изменение 1 | 59 | 97 720 | Добавени са бугиски, глаголица, карощи, нов тай лю, староперсийски, силоти нагри и тифинаг, а коптският е отделен от гръцкия. Добавени са още старогръцки числа и музикални символи. | |
| 5.0 | Юли 2006 | ISBN 0-321-48091-0 | ISO/IEC 10646:2003 плюс изменение 1 и 2, както и четири знака от изменение 3 | 64 | 99 089 | Добавени са балийски, клинопис, н’ко, фагс па и финикийски. |
| 5.1 | Април 2008 | ISO/IEC 10646:2003 плюс изменение 1, 2, 3 и 4 | 75 | 100 713 | Добавени са карийски, чам, кая ли, лепча, ликийски, лидийски, ол чики (санталски), режанг, саураштра, сундански, вай, както и набори от символи за диска от Фестос, плочките за маджонг и плочките за домино. Има също добавки към бирманския, добавени букви и ръкописни съкращения, използвани в средновековните ръкописи, както и главната буква ẞ. | |
| 5.2 | Октомври 2009 | ISO/IEC 10646:2003 плюс изменение 1, 2, 3, 4, 5 и 6 | 90 | 107 361 | Добавени са авестийски, бамум, египетски йероглифи (наборът на Алън Гардинър от 1071 знака), имперски арамейски, пахлави, партски, явански, кайтхи, лису, мейтей майек, стар южноарабски, старотюркски, самаритски, тай тхам и тай виет. Добавени са също 4149 нови унифицирани идеограми за CJK (CJK-C), както и разширени джамо за стар хангъл и символи за ведически санскрит. | |
| 6.0 | Октомври 2010 | ISO/IEC 10646:2010 плюс знака за индийска рупия | 93 | 109 449 | Добавени са батак, брахми, мандейска азбука, символи за карти за игра, транспортни символи, символи за географски карти, алхимични символи, емотикони и емоджита, както и 222 нови унифицирани идеограми за CJK (CJK-D). | |
| 6.1 | Януари 2012 | ISO/IEC 10646:2012 | 100 | 110 181 | Добавени са чакма, ръкописен мероитски, мероитски йероглифи, мяо, шарада, сора сомпенг и такри. | |
| 6.2 | Септември 2012 | ISO/IEC 10646:2012 плюс знака на турската лира | 100 | 110 182 | Добавен е знакът на турската лира. | |
| 6.3 | Септември 2013 | ISO/IEC 10646:2012 плюс шест знака | 100 | 110 187 | Добавени са 5 двупосочни форматиращи знака. | |
| 7.0 | Юни 2014 | ISO/IEC 10646:2012 плюс изменения 1 и 2, както и знакът на рублата | 123 | 113 021 | Добавени са баса, кавказки албански, стенографската система на Дюплойе, елбасанска азбука, гранта, ходжки, худавади, линеар А, махаджани, манихейска азбука, менде кикакуй, моди, мро, набатейска азбука, стар северноарабски, старопермски, пахау хмонг, палмирски, Пау Чин Хау, псалтирен пахлави, сидхам, тирхута, варанг кшити и наборът Dingbats. | |
| 8.0 | Юни 2015 | ISO/IEC 10646:2014 плюс изменение 1, както и знакът на грузинското лари, 9 CJK идеограми и 41 емоджита | 129 | 120 737 | Добавени са ахом, анатолийски йероглифи, хатран, мултани, староунгарски, жестовото писмо на Сътън, 5771 унифицирани идеограми за CJK, набор от малки букви за черокски и пет модификатора за цвят на кожата за емоджитата. | |
| 9.0 | Юни 1016 | ISO/IEC 10646:2014 плюс изменения 1 и 2, адлам, нева, японски тв символи и 74 емоджита и други символи. | 135 | 128 237 | Добавени са адлам, бхайкшуки, марчен, нева, осейдж, тангут и 72 емоджита. | |
| 10.0 | Юни 2017 | ISO/IEC 10646:2017 плюс 56 емоджита, 285 знака от хентайгана и 3 знака от квадратната азбука на Занабазар. | 139 | 136 755 | Добавени са квадратната азбука на Занабазар, сойомбо, масарам гонди, нюшу Архив на оригинала от 2018-01-01 в Wayback Machine., хентайгана (нестандартна хирагана), 7494 унифицирани идеограми за CJK и 56 емоджита. | |
| 11.0 | Юни 2018 | 146 | 137 439 | Добавени са главните букви от грузинската писменост мтаврули, ханифи рохингя, медефайдрин, масауа, числата на маите, хентайгана (нестандартна хирагана), 5 спешно необходими унифицирани идеограми за CJK и 145 емоджита. | ||
Уникод обхваща почти всички писмености (scripts[6]), използвани днес.
В последната версия на Уникод са включени общо 146 писмености (включително азбуки, абугиди и сричкови писмености), въпреки че все още съществуват такива, които не са кодирани, особено тези, които се използват главно в исторически, литургически и академични контексти. Случва се и да се добавят знаци към вече кодирани писмености, както и символи, особено за математика и музика (във вид на ноти и ритмични символи).
Комитетът Unicode Roadmap Committee (Майкъл Еверсън, Рик Макгоуън и Кен Уистлър) поддържа списък от писмености, които са кандидати или потенциални кандидати за кодиране, заедно с временно приписаните им блокове от кодове, на страницата Unicode Roadmap (План за развитие на Уникод) в уебсайта на консорциума Уникод. За някои писмености, като чжурчженска и хитанска, са направени предложения за кодиране, които са в процес на одобряване. За други, като писмеността на маите и ронгоронго, все още не са направени предложения и се очаква постигане на съгласие сред заинтересованите общности от потребители по отношение на знаковия набор и други подробности.
Някои съвременни писмености, които още не са включени в Уникод (например тенгвар) или не подлежат на включване поради липса на реална употреба (например клингонски), са включени в регистъра ConScript Unicode Registry заедно с някои неофициални, но широко използвани дефиниции на кодове за частна употреба.
Съществува още инициативата Medieval Unicode Font Initiative (Инициатива за средновековни шрифтове в Уникод), насочена към специалните средновековни латински знаци. Част от тези предложения вече са включени в Уникод.
Проектът Script Encoding Initiative, ръководен от Дебора Андерсън в университета Бъркли, Калифорния, е стартиран през 2002 година с цел да финансира предложения за писмености, които все още не са включени в стандарта. Той става главен източник на предложения за допълнения към стандарта през последните години.
Дефинирани са няколко механизма за прилагане на Уникод. Изборът зависи от наличното място за съхранение, съвместимостта на изходния код и оперативната съвместимост с други системи.
Уникод дефинира два метода за кодиране: групата от кодировки UTF (Unicode Transformation Format, Формат за трансформация на Уникод) и групата от кодировки UCS (Universal Coded Character Set, Универсален набор от кодирани знаци). Кодировките дефинират съответствие между (подмножество на) диапазона от кодови точки на Уникод и поредици от стойности в някакъв диапазон с фиксиран размер, наречени кодови стойности. Всички кодировки UTF приписват на всяка кодова точка (освен сурогатите) уникална поредица от байтове. Числата в имената на кодировките обозначават броя на битовете (за кодировките UTF) или байтовете (за кодировките UCS) за една кодова стойност. UTF-8 и UTF-16 са вероятно най-често използваните кодировки. UCS-2 е остаряло подмножество на UTF-16; UCS-4 и UTF-32 са функционално еквивалентни.
Кодировките UTF включват:
Кодировката UTF-8 използва между един и четири байта за кодова точка, компактна е за латински букви, съвместима е с ASCII и представлява de facto стандартната кодировка за обмен на текст в Уникод. Използва се във FreeBSD и най-новите дистрибуции на Линукс като пряк заместител на традиционните кодировки за обща обработка на текст.
Кодировките UCS-2 и UTF-16 дефинират маркера на Уникод за ред на байтовете (BOM, Byte Order Mark), който се използва в началото на текстови файлове и служи за определяне реда на байтовете. Маркерът BOM (кодова точка U+FEFF) има важното свойство, че е еднозначен при пренареждане на байтовете, независимо от използваната кодировка на Уникод; U+FFFE (резултатът от размяна на байтовете на U+FEFF) не е валиден знак, а U+FEFF на място, различно от началото на текста, означава непреносим интервал с нулева ширина (знак, който няма графично изражение и няма друго действие, освен че предотвратява образуването на лигатури).
Същият знак, преобразуван в UTF-8, се превръща в поредицата от байтове EF BB BF. Стандартът Уникод позволява BOM „да служи като означение за текст, кодиран с UTF-8, когато знаковият набор не е отбелязан“. Някои разработчици на софтуер са го възприели за други кодировки, включително UTF-8, в опит да разграничават UTF-8 от местните 8-битови кодови страници. Стандартът за UTF-8 препоръчва маркерите за ред на байтовете да бъдат забранени в протоколите, използващи UTF-8, но разглежда случаи, когато това може да не е възможно. Освен това строгите ограничения за възможните поредици от байтове в UTF-8 (например не може да има самотни байтове с вдигнат старши бит) би трябвало да позволяват разграничаването на UTF-8 от други знакови кодировки, без да се разчита на BOM.
В UTF-32 и UCS-4 една 32-битова кодова стойност служи за сравнително директно представяне на кодовата точка на произволен знак (макар че редът на байтовете, който варира на различните платформи, влияе върху това как кодовата стойност се изразява като последователност от байтове). UTF-32 е широко използван за вътрешно представяне на текст в програмите (за разлика от съхраняването и предаването на текст), тъй като всички базирани на Unix операционни системи, които разчитат на компилатора gcc за генериране на софтуер, го използват като стандартно кодиране за „широки“ знаци.[7] Някои програмни езици, например Seed7, използват UTF-32 за вътрешно представяне на знаци и низове. По-новите версии на Python (от 2.2 нататък) също могат да бъдат конфигурирани да използват UTF-32 за представяне на низове в Уникод, като така това кодиране се разпространява и в софтуера, написан на програмни езици от високо ниво.
Punycode, друга форма на кодиране, позволява кодиране на низове в Уникод с ограничения знаков набор, поддържан от базираната на ASCII система Domain Name System (DNS). Тя се използва като част от IDNA – система, която позволява използването на интернационализирани имена на домейни във всички писмености, поддържани от Уникод.
GB18030 е друга форма за кодиране на Уникод, от Китайската администрация за стандартизация. Това е официалният знаков набор в Китайската народна република. BOCU-1 и SCSU са схеми за компресиране на Уникод.
Уникод включва механизъм за модифициране фо̀рмата на знаците, който значително разширява набора от поддържани глифове. Той обхваща използването на комбинирани диакритични знаци (combining diacritical marks), които се вмъкват след основния знак. Върху един и същ знак могат да се насложат няколко комбинирани диакритични знака. Уникод съдържа и предварително съставени версии на повечето често използвани съчетания от буква и диакритичен знак. Те опростяват преобразуването от и към традиционните кодировки и позволяват на приложенията да използват Уникод като вътрешен текстов формат, без да се налага да поддържат съставни знаци. Например буквата „é“ може да бъде представена в Уникод като U+0065 (LATIN SMALL LETTER E, малка латинска буква „е“), последвано от U+0301 (COMBINING ACUTE ACCENT, остро ударение за комбиниране), но може да бъде представена и като предварително съставения знак U+00E9 (LATIN SMALL LETTER E WITH ACUTE, малка латинска буква „е“ с остро ударение). Така в много случаи потребителите разполагат с различни начини за кодиране на един и същ знак. За справяне с този проблем Unicode предлага механизъм за канонична еквивалентност (canonical equivalence).
Пример за това е хангъл, корейската азбука. Уникод предлага механизъм за съставяне на сричките в хангъл от отделните им съставни части, наречени хангъл джамо. Той осигурява обаче и 11 172 предварително съставени срички, изградени от най-често употребяваните джамо.
Идеограмите от групата CJK (Chinese, Japanese, and Korean, Китайски, японски и корейски) за момента имат кодове само за предварително съставените си форми. Независимо от това, повечето от тях са изградени от по-прости елементи (често наричани радикали), така че по принцип биха могли да бъдат разложени, както е направено с хангъл. Това би намалило драстично броя необходими кодови точки и би позволило изобразяването на практически всяка мислима идеограма (което може да реши някои от проблемите, свързани с унифицирането на идеограмите). Подобна идея се използва от някои методи за въвеждане, като Cangjie и Wubi. Опитите това да се използва за кодиране на знаци обаче се сблъскват с факта, че идеограмите не се разлагат толкова лесно или регулярно като хангъл.
Много писмености, включително арабската и деванагари, имат специални правописни правила, които изискват определени комбинации от букви и изрази да се обединяват в специални лигатурни форми. Тези правила могат да бъдат доста сложни и да изискват специални технологии за оформяне на знаците като ACE (Arabic Calligraphic Engine, програма за арабска калиграфия, създадена от DecoType през 80-те години и използвана за генериране на всички примери на арабски в печатните издания на стандарта Уникод), която е послужила като тест на концепцията за по-късните OpenType (на Adobe и Microsoft), Graphite (на SIL International) и AAT (на Apple).
Освен това в шрифтовете се вграждат инструкции, които указват на операционната система как правилно да изобразява различни последователности от знаци. Просто решение за разполагането на комбиниращи се или диакритични знаци е да им се припише нулева ширина и самият глиф да се разположи отляво или отдясно спрямо лявата или дясната граница на знака (според посоката на писмеността, в която се очаква да се използва). Позиционираният по такъв начин знак ще се покаже над предходния, но няма да приспособи позицията си към ширината на основния знак и може да изглежда разместен или да припокрива някои глифове. Истинско наслагване във височина не е възможно, но може да се наподоби в ограничени случаи (например тайските гласни и маркери за тон за комбиниране отгоре могат просто поначало да бъдат на различна височина). Обикновено този подход е ефективен само в равношироки шрифтове, но може да се използва като резервен метод за рендиране, когато по-сложните методи не дадат резултат.
Няколко подмножества на Уникод са стандартизирани: от Windows NT 4.0 нататък Microsoft Windows поддържа набора WGL-4 с 656 знака, който се смята за достатъчен за всички съвременни европейски езици, използващи латиница, гръцки букви или кирилица. Други стандартизирани подмножества на Уникод са например многоезичните европейски подмножества: MES-1 (само латински букви, 335 знака), MES-2 (латински, гръцки и кирилски букви, 1062 знака) и MES-3A и MES-3B (две големи подгрупи, които не са показани тук). МЕS-2 включва всички знаци от MES-1 и WGL-4.
| WGL-4, MES-1 и MES-2 | ||
|---|---|---|
| Ред | Клетки | Диапазон |
| 00 | 20–7E | Основна латиница (00–7F) |
| A0–FF | Допълнителна латиница-1 (80–FF) | |
| 01 | 00 – 13, 14 – 15, 16–2B, 2C–2D, 2E–4D, 4E–4F, 50–7E, 7F | Разширена латиница-А (00–7F) |
| 8F, 92, B7, DE-EF, FA–FF | Разширена латиница-В (80–FF ...) | |
| 02 | 18–1B, 1E–1F | Разширена латиница-В (... 00–4F) |
| 59, 7C, 92 | Разширения за IPA (50–AF) | |
| BB–BD, C6, C7, C9, D6, D8–DB, DC, DD, DF, EE | Знаци, променящи разредката (B0–FF) | |
| 03 | 74 – 75, 7A, 7E, 84–8A, 8C, 8E–A1, A3–CE, D7, DA–E1 | Гръцки (70–FF) |
| 04 | 00, 01–0C, 0D, 0E–4F, 50, 51–5C, 5D, 5E–5F, 90 – 91, 92–C4, C7–C8, CB–CC, D0–EB, EE–F5, F8–F9 | Кирилица (00–FF) |
| 1E | 02 – 03, 0A–0B, 1E–1F, 40 – 41, 56 – 57, 60 – 61, 6A–6B, 80 – 85, 9B, F2–F3 | Допълнителна разширена латиница (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 | Разширен гръцки (00–FF) |
| 20 | 13 – 14, 15, 17, 18 – 19, 1A–1B, 1C–1D, 1E, 20 – 22, 26, 30, 32 – 33, 39–3A, 3C, 3E | Обща пунктуация (00–6F) |
| 44, 4A, 7F, 82 | Горни и долни индекси (70–9F) | |
| A3–A4, A7, AC, AF | Валутни символи (A0–CF) | |
| 21 | 05, 13, 16, 22, 26, 2E | Буквоподобни символи (00–4F) |
| 5B–5E | Числови символи (50–8F) | |
| 90 – 93, 94 – 95, A8 | Стрелки (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 | Математически оператори (00–FF) |
| 23 | 02, 0A, 20 – 21, 29–2A | Разни технически знаци (00–FF) |
| 25 | 00, 02, 0C, 10, 14, 18, 1C, 24, 2C, 34, 3C, 50–6C | Чертане на рамки (00–7F) |
| 80, 84, 88, 8C, 90 – 93 | Елементи за запълване (80–9F) | |
| A0–A1, AA–AC, B2, BA, BC, C4, CA–CB, CF, D8–D9, E6 | Геометрични фигури (A0–FF) | |
| 26 | 3A–3C, 40, 42, 60, 63, 65 – 66, 6A, 6B | Разни символи (00–FF) |
| F0 | (01 – 02) | Област за частно използване (00–FF...) |
| FB | 01 – 02 | Азбучни форми на представяне (00–4F) |
| FF | FD | Специални |
Когато софтуерът за изобразяване не може да обработи даден знак от Уникод, често го обозначава с празен правоъгълник или със „заместващия знак“ на Уникод (U+FFFD, �), за да покаже все пак позицията на непознатия знак. Някои системи правят опит да предоставят допълнителна информация за такива знаци. Шрифтът Last Resort на Apple показва заместващ глиф, който посочва съответния диапазон в Уникод, а Unicode Fallback на SIL International показва квадратче с шестнайсетичната скаларна стойност на знака.
Уникод вече е доминиращата система за вътрешна обработка и съхранение на текст. Въпреки че много текстове все още се съхраняват в традиционни кодировки, новите системи за обработка на информация се изграждат почти само с Уникод. Повечето ранни последователи на стандарта използват UCS-2 (предшественик на UTF-16 с фиксирана ширина 2 байта) и по-късно се прехвърлят на UTF-16 (настоящия стандарт с променлива ширина), тъй като това се оказва най-безболезненият начин да се добави поддръжка на знаци извън BMP. Най-известната подобна система е Windows NT (и нейните наследници Windows 2000, Windows XP, Windows Vista, Windows 7 и Windows 10), която използва UTF-16 като единствена вътрешна знакова кодировка. Виртуалните машини на Java и .NET, както и MAC OS X и KDE също я използват за вътрешно представяне. Уникод е достъпен в Windows 95 чрез модула Microsoft Layer for Unicode, както и в следващите Windows 98 и Windows ME.
UTF-8 е станала основна кодировка за съхранение в повечето подобни на UNIX операционни системи (макар някои библиотеки да използват и други), тъй като тя лесно заменя традиционните разширени ASCII набори. UTF-8 е и най-често използваната кодировка за документите на HTML в световната мрежа.
Сред многоезичните системи за изобразяване на текст, които използват Уникод, са Uniscribe и DirectWrite за Microsoft Windows, ATSUI и Core Text за macOS и Pango за GTK+ и работната среда на GNOME.
Понеже в клавиатурните подредби не може да има прости клавишни комбинации за всички знаци, няколко операционни системи предлагат алтернативни методи за въвеждане, които позволяват достъп до целия набор.
ISO 14755, който стандартизира методи за въвеждане на знаци от Уникод чрез техните кодови точки, дефинира няколко метода. Има Основен метод, при който определена начална поредица е следвана от шестнадесетичното представяне на кодовата точка и крайната поредица. Налице е също метод за въвеждане чрез избор от екрана, при който знаците са изброени в таблица на екрана.
MIME дефинира два различни механизма за кодиране на знаци извън набора на ASCII в електронната поща, в зависимост от това дали са в заглавието на съобщението (например в полето „Тема“), или в основния му текст. И в двата случая се определят оригиналният знаков набор и кодировката за прехвърляне. За предаване на Уникод по електронна поща се препоръчва наборът UTF-8 и кодировките за прехвърляне Base64 или Quoted-printable, в зависимост от това дали голяма част от съобщението е съставено от ASCII знаци. Подробностите около двата различни механизма са уточнени в стандартите MIME и обикновено остават скрити от потребителите на софтуер за електронна поща.
Внедряването на Уникод в електронната поща е много бавно. Някои източноазиатски текстове все още биват кодирани с кодировки като ISO-2022 и някои устройства, например мобилни телефони, все още не могат да работят правилно с данни в Уникод. Все пак поддръжката се подобрява. Много от големите доставчици на безплатни услуги като Yahoo, Google (Gmail) и Microsoft (Outlook.com) поддържат Уникод.
От HTML 4.0 насам Уникод се използва като знаков набор на документа във всички препоръки на W3C. Уеббраузърите от много години поддържат Уникод, в частност UTF-8. В миналото има проблеми при изобразяването, свързани главно с шрифтовете; например Microsoft Internet Explorer до версия 6 не изобразява много от кодовите точки, ако не е изрично инструктиран да използва шрифт, който ги съдържа.
Макар че синтактичните правила може да повлияят върху реда, в който е разрешено да се срещат знаците, документите на XML (включително XHTML) по дефиниция съдържат знаци от повечето кодови точки на Уникод, с изключение на:
Знаците в HTML се изразяват или директно като байтове според кодировката на документа, или като въведени от потребителите числови обръщения към съответните им кодови точки в Уникод. Например обръщенията Δ, Й, ק, م, ๗, あ, 叶, 葉 и 말 (или същите стойности, изразени в шестнадесетична бройна система с префикс &#x) би трябвало да се изобразяват във всички браузъри като Δ, Й, ק,م, ๗, あ, 叶, 葉 и 말.
Когато се задава идентификатор URI, например URL адрес в HTTP заявка, знаците извън ASCII трябва да бъдат кодирани със знак % (например при копиране адреса на тази страница в клипборда повечето браузъри биха поставили в него текста https://bg.wikipedia.org/wiki/%D0%A3%D0%BD%D0%B8%D0%BA%D0%BE%D0%B4).
Съществуват многобройни безплатни и платени шрифтове, базирани на Уникод, тъй като стандартът се поддържа от TrueType и OpenType. Тези шрифтови формати съпоставят глифове на кодови точки от Уникод.
На пазара са налице хиляди шрифтове, но за по-малко от десет от тях – понякога описвани като „пан-Уникод“ шрифтове – се полагат усилия да поддържат по-голямата част от знаковия набор на Уникод. Вместо това базираните на Уникод шрифтове обикновено са фокусирани върху основните знаци от ASCII и конкретни писмености или множества от знаци или символи. Този подход е оправдан по няколко причини: в приложенията и документите рядко се налага едновременно изобразяване на знаци от повече от една или две писмености; шрифтовете заемат изчислителни ресурси; в операционните системи се вгражда все по-интелигентно поведение по отношение използването на глифове от друг шрифт при необходимост, например чрез заместване на шрифтове. Освен това съставянето на съгласуван набор от инструкции за изобразяването на десетки хиляди глифове е колосална задача, която за повечето шрифтове далеч надхвърля разумното съотношение между положени усилия и резултат.
Уникод частично разглежда проблема със знака за нов ред, който се появява при опит за четене на текстов файл на различни платформи. Стандартът определя голям брой знаци, които приложенията трябва да разпознават като край на ред.
Що се отнася до самия знак за нов ред, Уникод въвежда U+2028 разделител на редове и U+2029 разделител на абзаци. Това е опит да се предложи решение за семантично кодиране на редовете и абзаците, което потенциално да замени разнообразните решения на различните платформи. По този начин Уникод предоставя начин за заобикаляне на историческите, зависими от платформата решения. Въпреки това почти никоя система за работа с Уникод не приема разделителите на ред и абзац като единствени знаци за завършване на ред. Чест подход за решаването на този проблем е нормализирането на новите редове. Това е постигнато с текстовата система Cocoa в Mac OS X, а също и с препоръките на W3C за XML и HTML. При този подход всички възможни знаци за нов ред се конвертират вътрешно до един общ знак. С други думи, текстовата система може правилно да разглежда знака като нов ред, независимо от кодировката на входящата информация.
Хан уеднаквяването (идентифицирането на форми в източноазиатските езици, които биха могли да се третират като стилистични вариации на един и същ знак) е един от най-противоречивите аспекти на Уникод, въпреки присъствието на множество експерти от всички източноазиатски региони в групата за идеографски доклади, която съветва консорциума Уникод и Международната организация по стандартизация относно разширяването на знаковия набор и хан уеднаквяването.
Уникод бива критикуван, че не кодира отделно по-стари и алтернативни форми на канджи което, според критиците, усложнява обработването на старояпонски и рядко срещани японски имена. Това често се дължи на факта, че Уникод кодира знаци, а не глифове (графичните представяния на базовите знаци, които често варират между езиците). Обединяването на глифовете води до усещането, че се сливат самите езици, а не само представянето на основните знаци. Имало е опити за създаване на алтернативни кодировки, които да запазват стилистичните разлики между китайските, японските и корейските логограми, за разлика от политиката на Уникод за хан уеднаквяване. Пример за такава е TRON (макар че не е широко използвана в Япония, тя се предпочита от потребители, на които се налага да боравят с исторически японски текстове).
Ранните версии на Уникод имат набор от по-малко от 21 000 хан логограми, което ограничава употребата предимно до съвременния език. Към 2018 г. Уникод включва над 87 000 хан логограми, като продължава работата по добавяне на още хиляди архаични и диалектни знаци, използвани в Китай, Япония, Корея, Тайван и Виетнам.
Съвременните технологии за представяне на шрифтове предоставят потенциални решения на проблема с нуждата от изобразяване на унифицирана хан логограма чрез набор от алтернативни глифове, под формата на селектор на вариации. Например допълнителните типографски таблици на OpenType позволяват при съпоставяне на знак към глиф да се избира един от няколко алтернативни глифа. По този начин в рамките на текста може да бъде предоставена информация, определяща кой алтернативен вариант на знака да се използва.
Ако разликата в подходящите глифове за дадена писменост е само при изписване с курсив, Уникод в общия случай ги уеднаквява, както може да се види при сравнението между руски и сръбски букви.
Уникод е проектиран с идеята да позволява двупосочно преобразуване на ниво кодова точка към и от всяка съществуваща кодировка, така, че текстови файлове в по-стари кодировки да могат да се конвертират към Уникод и обратно и да се получи идентичен файл, без да се прибягва до зависима от контекста интерпретация. Заради това в стандарта едновременно присъстват противоречащи си наследени архитектури като съчетаване на диакритични знаци и предварително съчетани знаци, което позволява един текст да се представи по няколко начина. Това е най-ярко изразено при трите различни кодировки на корейската азбука Хангъл. От версия 3.0 насам, с цел да се запази оперативната съвместимост между софтуер, използващ различни версии на Уникод, в стандарта вече не се добавят нови знаци, които могат да бъдат представени чрез комбиниране на вече съществуващите.
За да се улесни преобразуването към Уникод и оперативната съвместимост с наследен софтуер, се налага използването на инективни съответствия между съществуващи остарели знакови набори и знаците в Уникод. Липсата на последователност в правилата за преобразуване между по-ранни японски кодировки и Уникод води до несъответствия, например конвертирането на знака JIS X 0208 '～' (1 – 33, WAVE DASH), широко използван в миналото в бази данни, в U+FF5E ～ тилда (в Microsoft Windows) или U+301C 〜 вълнообразно тире (при други системи).
Някои японски програмисти са възразявали срещу въвеждането на Уникод, тъй като това би ги принудило да разграничат употребата на U+005C \ (обратна наклонена черта) и U+00A5 ¥ (символ за йена), който е бил приписан на 0x5C в JIS X 0201 и голяма част от наследения програмен код е написан по този начин. Разграничението между тези знаци съществува още в ISO 8859-1, много преди появата на Уникод.
Азбуките на индоарийските езици като тамил и деванагари имат разпределени само по 128 кодови точки, също като при стандарта ISCII. Коректното изобразяване на индоарийски текст в Уникод изисква трансформиране на съхраняваната логическа последователност от знаци във визуална последователност и формирането на лигатури от компонентите им. Някои местни учени защитават идеята на тези лигатури да се припишат кодови точки в Уникод, което е в противоречие с практиката за други писмености, въпреки че Уникод съдържа някои арабски и други лигатури с цел единствено обратна съвместимост. Кодирането на нови лигатури в Уникод няма да се случи, отчасти защото наборът лигатури е зависим от шрифта, а Уникод е кодировка, независима от шрифтовите вариации. Същите проблеми се появяват и с тибетски (китайската национална организация за стандартизация не успява да постигне аналогична промяна)
Поддръжката на тайски език бива критикувана заради подредбата на буквите. Гласните เ, แ, โ, ใ, ไ, които се изписват вляво от предшестващата съгласна, са във визуална подредба, вместо фонетична, за разлика от представянето в Уникод на други индоарийски писмености. Усложнението се дължи на факта, че Уникод наследява стандарта Thai Industrial Standard 620, който работи по аналогичен начин и е методът, по който тайският винаги е бил изписван на клавиатурите. Този проблем при подредбата усложнява сортирането в Уникод, защото се налага справка в таблици за преподреждане на тайски букви. Дори Уникод да приеме подреждане по реда на произнасяне, лексикографското сортиране на думите пак би било проблематично. Например думата แสดง (‘изпълнявам’) започва със струпването на съгласни „สด“ (със слята гласна към съгласната „ส“), гласната แ-, по реда на произнасяне, би била след съгласната ด, но в речник, думата би била подредена според изписването ѝ, с гласната след ส.
Буквите с диакритични знаци могат да бъдат представени или като предварително съчетани знаци, или като разложена последователност от основна буква и един или повече допълнителни знаци, непоставящи интервал. Например, ḗ (предварително съчетано с макрон и акут) и ḗ („е“, следвано от знаците макрон за комбиниране и акут за комбиниране) би следвало да се изобразят идентично. На практика обаче тяхното представяне може да се различава в зависимост от използвания шрифт и програмата, която изобразява буквите. Аналогично диакритичната точка, нужна за латинизация на индоарийски езици, често се разполага неправилно. Този проблем може да се избегне с използване на знаци от Уникод, които се съпоставят на предварително съчетани глифове, но когато такива липсват, проблемът може да се реши, като се използват специални шрифтове за Уникод като Charis SIL, който използва усъвършенстваните възможности за рендиране в технологиите Graphite, OpenType и AAT.
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
