Unicode - Unicode

Unicode
Nowe logo Unicode.svg
Skróty) Uniwersalny kodowany zestaw znaków (UCS)
Języki) Międzynarodowy
Standard Standard Unicode
Formaty kodowania
Poprzedzony ISO/IEC 8859 , różne inne

Unicode , formalnie standard Unicode , to standard technologii informacyjnej do spójnego kodowania , reprezentacji i obsługi tekstu wyrażonego w większości systemów pisma na świecie . Standard utrzymywany przez Unicode Consortium definiuje 144697 znaków obejmujących 159 nowoczesnych i historycznych skryptów , a także symbole, emotikony oraz niewizualne kody sterujące i formatujące.

Repertuar znaków Unicode jest zsynchronizowany z normą ISO/IEC 10646 , przy czym każdy kod jest identyczny z drugim. Jednak standard Unicode zawiera więcej niż tylko kod podstawowy . Oprócz kodowania znaków, oficjalna publikacja Konsorcjum zawiera szeroką gamę szczegółów dotyczących skryptów i sposobu ich wyświetlania: zasady normalizacji , dekompozycji, sortowania , renderowania i dwukierunkowej kolejności wyświetlania tekstu dla tekstów wielojęzycznych i tak dalej. Standardowe obejmuje również referencyjnych zbiorów danych i wykresy wizualnych pomocy dla programistów i projektantów poprawnie wdrożyć repertuar.

Sukces Unicode w ujednolicaniu zestawów znaków doprowadził do jego powszechnego i dominującego zastosowania w internacjonalizacji i lokalizacji oprogramowania komputerowego . Standard został zaimplementowany w wielu najnowszych technologiach, w tym w nowoczesnych systemach operacyjnych , XML , Java (i innych językach programowania ) oraz .NET Framework .

Unicode można zaimplementować za pomocą różnych kodowań znaków. Standard Unicode definiuje formaty transformacji Unicode (UTF): UTF-8 , UTF-16 i UTF-32 oraz kilka innych kodowań. Najczęściej używane kodowania to UTF-8, UTF-16 i przestarzały UCS-2 (prekursor UTF-16 bez pełnej obsługi Unicode); GB18030 , choć nie jest oficjalnym standardem Unicode, jest standaryzowany w Chinach i w pełni implementuje Unicode.

UTF-8, dominujące kodowanie w sieci WWW (używane w ponad 95% stron internetowych od 2020 r. i do 100% w przypadku niektórych języków) oraz w większości systemów operacyjnych typu Unix, wykorzystuje jeden bajt (8  bitów ) do pierwsze 128 punktów kodowych i do 4 bajtów dla innych znaków. Pierwsze 128 punktów kodowych Unicode reprezentuje znaki ASCII , co oznacza, że ​​każdy tekst ASCII jest również tekstem UTF-8.

UCS-2 używa dwóch bajtów (16 bitów) dla każdego znaku, ale może kodować tylko pierwsze 65 536 punktów kodowych , tak zwaną podstawową płaszczyznę wielojęzyczną (BMP). Z 1,112,064 możliwymi punktami kodowymi Unicode odpowiadającymi znakom (patrz poniżej ) na 17 płaszczyznach oraz z ponad 144 000 punktami kodowymi zdefiniowanymi w wersji 14.0, UCS-2 jest w stanie reprezentować tylko mniej niż połowę wszystkich zakodowanych znaków Unicode. Dlatego UCS-2 jest przestarzały, choć nadal używany w oprogramowaniu. UTF-16 rozszerza UCS-2, używając tego samego 16-bitowego kodowania co UCS-2 dla podstawowej płaszczyzny wielojęzycznej i 4-bajtowego kodowania dla pozostałych płaszczyzn. Dopóki nie zawiera punktów kodowych w zarezerwowanym zakresie U+D800–U+DFFF, tekst UCS-2 jest prawidłowym tekstem UTF-16.

UTF-32 (określany również jako UCS-4) używa czterech bajtów do zakodowania dowolnego danego punktu kodowego, ale niekoniecznie dowolnego danego znaku postrzeganego przez użytkownika (w skrócie grafem ), ponieważ znak postrzegany przez użytkownika może być reprezentowany przez klaster grafemowy (sekwencja wielu punktów kodowych). Podobnie jak UCS-2, liczba bajtów na punkt kodowy jest stała, co ułatwia indeksowanie punktów kodowych; ale w przeciwieństwie do UCS-2, UTF-32 jest w stanie zakodować wszystkie punkty kodowe Unicode. Jednak ponieważ każdy punkt kodowy używa czterech bajtów, UTF-32 zajmuje znacznie więcej miejsca niż inne kodowania i nie jest powszechnie używany. Chociaż UTF-32 ma stały rozmiar dla każdego punktu kodowego, ma również zmienną długość w odniesieniu do znaków postrzeganych przez użytkownika. Przykłady obejmują: kshi dewanagari , który jest zakodowany przez 4 punkty kodowe, oraz emotikony flagi narodowej, które składają się z dwóch punktów kodowych. Wszystkie połączone sekwencje znaków są grafemami, ale istnieją również inne sekwencje punktów kodowych, na przykład \r\n .

Pochodzenie i rozwój

Unicode ma wyraźny cel przekroczenia ograniczeń tradycyjnych kodowań znaków, takich jak te zdefiniowane w standardzie ISO/IEC 8859 , które znajdują szerokie zastosowanie w różnych krajach świata, ale pozostają w dużej mierze ze sobą niekompatybilne. Wiele tradycyjnych kodowań znaków ma wspólny problem, ponieważ umożliwiają dwujęzyczne przetwarzanie komputerowe (zwykle przy użyciu znaków łacińskich i lokalnego skryptu), ale nie wielojęzyczne przetwarzanie komputerowe (przetwarzanie komputerowe dowolnych skryptów zmieszanych ze sobą).

Unicode w zamierzeniu koduje podstawowe znaki — grafemy i jednostki podobne do grafemów — zamiast glifów wariantów (renderowania) dla takich znaków. W przypadku chińskich znaków , prowadzi to czasami do kontrowersji dotyczących odróżnienia podstawowego znaku od jego wariantów glifów (patrz ujednolicenie Han ).

W przetwarzaniu tekstu Unicode pełni rolę dostarczania unikalnego punktu kodowegoliczby , a nie glifu — dla każdego znaku. Innymi słowy, Unicode reprezentuje znak w sposób abstrakcyjny i pozostawia renderowanie wizualne (rozmiar, kształt, czcionkę lub styl) innemu oprogramowaniu, takiemu jak przeglądarka internetowa lub edytor tekstu . Ten prosty cel komplikuje się jednak z powodu ustępstw poczynionych przez projektantów Unicode w nadziei na zachęcenie do szybszego przyjęcia Unicode.

Pierwsze 256 punktów kodowych zostało uczynionych identycznymi z treścią ISO/IEC 8859-1 , aby uprościć konwersję istniejącego tekstu zachodniego. Wiele zasadniczo identycznych znaków zostało zakodowanych wiele razy w różnych punktach kodu, aby zachować rozróżnienia używane przez starsze kodowania, a zatem umożliwić konwersję z tych kodowań na Unicode (i z powrotem) bez utraty jakichkolwiek informacji. Na przykład sekcja punktów kodowych „ formy o pełnej szerokości ” obejmuje pełną kopię alfabetu łacińskiego, ponieważ czcionki chińskie, japońskie i koreańskie ( CJK ) zawierają dwie wersje tych liter, „pełna szerokość” odpowiada szerokości znaków CJK i normalna szerokość. Aby zapoznać się z innymi przykładami, zobacz zduplikowane znaki w Unicode .

Laureaci Unicode Bulldog Award to wiele nazwisk mających wpływ na rozwój Unicode, w tym Tatsuo Kobayashi , Thomas Milo, Roozbeh Pournader , Ken Lunde i Michael Everson

Historia

Bazując na doświadczeniach ze standardem Xerox Character Code Standard (XCCS) od 1980 roku, początki Unicode sięgają 1987 roku, kiedy to Joe Becker z Xeroxa z Lee Collinsem i Mark Davis z Apple zaczęli badać praktyczne możliwości stworzenia uniwersalnego zestawu znaków. Z dodatkowym wkładem Petera Fenwicka i Dave'a Opstada, Joe Becker opublikował w sierpniu 1988 r. projekt propozycji „międzynarodowego/wielojęzycznego systemu kodowania znaków tekstu, roboczo zwanego Unicode”. Wyjaśnił, że „[t]a nazwa »Unicode« ma sugerować unikalne, zunifikowane, uniwersalne kodowanie”.

W tym dokumencie, zatytułowanym Unicode 88 , Becker nakreślił 16-bitowy model znaków:

Unicode ma na celu zaspokojenie potrzeby sprawnego, niezawodnego kodowania tekstu na świecie. Unicode można z grubsza opisać jako "szerokobody ASCII", który został rozciągnięty do 16 bitów, aby objąć znaki wszystkich żywych języków świata. W odpowiednio zaprojektowanym projekcie 16 bitów na znak jest więcej niż wystarczające do tego celu.

Jego oryginalny 16-bitowy projekt opierał się na założeniu, że tylko te skrypty i znaki, które są obecnie używane, będą musiały być zakodowane:

Unicode nadaje wyższy priorytet zapewnieniu użyteczności na przyszłość niż zachowaniu dawnych zabytków. Unicode ma na celu przede wszystkim znaki publikowane we współczesnym tekście (np. w unii wszystkich gazet i czasopism drukowanych na świecie w 1988 r.), których liczba jest niewątpliwie znacznie poniżej 2 14 = 16 384. Poza tymi współczesnymi znakami, wszystkie inne można określić jako przestarzałe lub rzadkie; są one lepszymi kandydatami do rejestracji na użytek prywatny niż do przepełnienia publicznej listy ogólnie użytecznych kodów Unicode.

Na początku 1989 roku grupa robocza Unicode poszerzyła się o Kena Whistlera i Mike'a Kernaghana z Metaphor, Karen Smith-Yoshimura i Joan Aliprand z RLG oraz Glenna Wrighta z Sun Microsystems , a w 1990 roku Michel Suignard i Asmus Freytag z Microsoftu i Rick McGowan z NeXT dołączył do grupy. Do końca 1990 roku większość prac nad mapowaniem istniejących standardów kodowania znaków została ukończona, a ostateczny przeglądowy projekt Unicode był gotowy.

Konsorcjum Unicode powstała w Kalifornii w dniu 3 stycznia 1991 roku, aw październiku 1991 roku pierwszy tom standardzie Unicode został opublikowany. Drugi tom, obejmujący ideogramy Han, został opublikowany w czerwcu 1992 roku.

W 1996 roku mechanizm znaków zastępczych został zaimplementowany w Unicode 2.0, dzięki czemu Unicode nie był już ograniczony do 16 bitów. Zwiększyło to przestrzeń kodową Unicode do ponad miliona punktów kodowych, co pozwoliło na zakodowanie wielu historycznych skryptów (np. egipskich hieroglifów ) i tysięcy rzadko używanych lub przestarzałych znaków, które nie były przewidziane jako wymagające kodowania. Wśród znaków, które nie były pierwotnie przeznaczone dla Unicode, są rzadko używane znaki Kanji lub chińskie, z których wiele jest częścią nazw osobistych i miejsc, co czyni je rzadko używanymi, ale znacznie ważniejszymi niż przewidywano w oryginalnej architekturze Unicode.

Specyfikacja Microsoft TrueType w wersji 1.0 z 1992 używała nazwy „Apple Unicode” zamiast „Unicode” dla identyfikatora platformy w tabeli nazewnictwa.

Konsorcjum Unicode

Konsorcjum Unicode to organizacja non-profit, która koordynuje rozwój Unicode. Pełni członkowie obejmują większość głównych firm zajmujących się oprogramowaniem i sprzętem komputerowym, które są zainteresowane standardami przetwarzania tekstu, w tym Adobe , Apple , Facebook , Google , IBM , Microsoft , Netflix i SAP SE .

Na przestrzeni lat kilka krajów lub agencji rządowych było członkami konsorcjum Unicode. Obecnie tylko Ministerstwo Darów i Spraw Religijnych (Oman) jest pełnoprawnym członkiem z prawem głosu.

Konsorcjum ma ambitny cel ostatecznego zastąpienia istniejących schematów kodowania znaków Unicode i jego standardowymi schematami Unicode Transformation Format (UTF), ponieważ wiele istniejących schematów ma ograniczony rozmiar i zakres oraz jest niekompatybilnych ze środowiskami wielojęzycznymi .

Skrypty objęte

Wiele nowoczesnych aplikacji może renderować znaczną część wielu skryptów w Unicode , jak pokazuje ten zrzut ekranu z aplikacji OpenOffice.org .

Unicode obejmuje prawie wszystkie skrypty ( systemy pisania ) obecnie używane.

Od 2021 r. w najnowszej wersji Unicode znajduje się łącznie 159 skryptów (obejmujących alfabety , abugida i sylabariusze ), chociaż nadal istnieją skrypty, które nie są jeszcze zakodowane, zwłaszcza te używane głównie w kontekście historycznym, liturgicznym i akademickim. Pojawiają się również dalsze dopisy znaków do już zakodowanych skryptów, a także symboli, w szczególności matematycznych i muzycznych (w postaci nut i symboli rytmicznych).

Komitet mapy drogowej Unicode ( Michael Everson , Rick McGowan, Ken Whistler, VS Umamaheswaran) utrzymuje listę skryptów, które są kandydatami lub potencjalnymi kandydatami do kodowania, oraz ich wstępne przypisania bloków kodu na stronie Mapa drogowa Unicode w witrynie Unicode Consortium . W przypadku niektórych skryptów w Mapie drogowej, takich jak mały skrypt Jurchen i Khitan , zostały złożone propozycje kodowania, które przechodzą przez proces zatwierdzania. W przypadku innych skryptów, takich jak Mayan (oprócz liczb) i Rongorongo , nie złożono jeszcze żadnej propozycji i czekają one na uzgodnienie repertuaru postaci i innych szczegółów od zaangażowanych społeczności użytkowników.

Niektóre współczesne wymyślone skrypty, które nie zostały jeszcze uwzględnione w Unicode (np. Tengwar ) lub które nie kwalifikują się do włączenia do Unicode z powodu braku użycia w świecie rzeczywistym (np. Klingon ) są wymienione w rejestrze ConScript Unicode wraz z nieoficjalnymi ale szeroko stosowane przypisania kodów obszarów prywatnego użytku .

Istnieje również Inicjatywa Średniowiecznych Czcionek Unicode, skoncentrowana na specjalnych łacińskich znakach średniowiecznych. Część z tych propozycji została już uwzględniona w Unicode.

Inicjatywa kodowania skryptów

The Script Encoding Initiative, projekt prowadzony przez Deborah Anderson na Uniwersytecie Kalifornijskim w Berkeley, został założony w 2002 roku w celu sfinansowania propozycji skryptów, które nie zostały jeszcze zakodowane w standardzie. Projekt stał się w ostatnich latach głównym źródłem proponowanych uzupełnień standardu.

Wersje

Konsorcjum Unicode i Międzynarodowa Organizacja Normalizacyjna (ISO) wspólnie opracowały wspólny repertuar po pierwszej publikacji standardu Unicode w 1991 roku; Unicode i Universal Coded Character Set (UCS) ISO używają identycznych nazw znaków i punktów kodowych. Jednak wersje Unicode różnią się od swoich odpowiedników ISO na dwa istotne sposoby.

Podczas gdy UCS jest prostą mapą znaków, Unicode określa zasady, algorytmy i właściwości niezbędne do osiągnięcia interoperacyjności między różnymi platformami i językami. W ten sposób Standard Unicode zawiera więcej informacji, szczegółowo omawiając takie tematy, jak kodowanie bitowe, sortowanie i renderowanie. Zapewnia również obszerny katalog właściwości znaków, w tym te potrzebne do obsługi tekstu dwukierunkowego , a także wykresy wizualne i zestawy danych referencyjnych, które mają pomóc realizatorom. Wcześniej The Unicode Standard był sprzedawany jako tom druku zawierający pełną specyfikację rdzenia, standardowe załączniki i tabele kodów. Jednak Unicode 5.0, opublikowany w 2006 roku, był ostatnią wersją wydrukowaną w ten sposób. Począwszy od wersji 5.2, można zakupić tylko podstawową specyfikację, opublikowaną w miękkiej oprawie drukowanej na żądanie. Z drugiej strony pełny tekst jest publikowany jako bezpłatny plik PDF na stronie Unicode.

Praktyczny powód tej metody publikacji podkreśla drugą istotną różnicę między UCS a Unicode — częstotliwość, z jaką publikowane są zaktualizowane wersje i dodawane są nowe znaki. Standard Unicode regularnie publikuje coroczne wersje rozszerzone, czasami z więcej niż jedną wersją wydaną w roku kalendarzowym i w rzadkich przypadkach, w których zaplanowane wydanie musiało zostać przełożone. Na przykład w kwietniu 2020 r., zaledwie miesiąc po opublikowaniu wersji 13.0, konsorcjum Unicode ogłosiło, że zmieniło zamierzoną datę wydania wersji 14.0, przesuwając ją o sześć miesięcy od marca 2021 do września 2021 r. z powodu pandemii COVID-19 .

Do tej pory opublikowano następujące główne i pomocnicze wersje standardu Unicode. Wersje aktualizacji, które nie zawierają żadnych zmian w repertuarze postaci, są oznaczone trzecim numerem (np. „wersja 4.0.1”) i zostały pominięte w poniższej tabeli.

Wersja Data Książka Odpowiednie wydanie ISO/IEC 10646 Skrypty Postacie
Całkowity Wybitne dodatki
1.0.0 Październik 1991 ISBN  0-201-56788-1 (tom 1) 24 7,129 Początkowy repertuar obejmuje te skrypty: arabski , ormiański , bengalskiego , bopomofo , cyrylicy , dewanagari , gruziński , grecki i koptyjski , gujarati , gurmukhi , Hangul , hebrajskiego , Hiragana , kannada , Katakana , Lao , łacinę , Malayalam , orija , tamilski , telugu , tajski i tybetański .
1.0.1 Czerwiec 1992 ISBN  0-201-60845-6 (t. 2) 25 28 327
(21 204 dodane;
6 usuniętych)
Zdefiniowano początkowy zestaw 20 902 zunifikowanych ideogramów CJK .
1,1 Czerwiec 1993 ISO/IEC 10646-1:1993 24 34168
( 5963 dodane;
89 usunięte;
33 przeklasyfikowane
jako
znaki kontrolne )
Dodano 4306 więcej sylab Hangul do oryginalnego zestawu 2350 znaków. Usunięto tybetański .
2,0 Lipiec 1996 ISBN  0-201-48345-9 ISO/IEC 10646-1:1993 plus poprawki 5, 6 i 7 25 38 885
(dodanych 11
373 ; usuniętych 6656)
Usunięto oryginalny zestaw sylab Hangul i dodano nowy zestaw 11172 sylab Hangul w nowej lokalizacji. Tybetański dodany z powrotem w nowym miejscu iz innym repertuarem postaci. Zdefiniowano mechanizm znaków zastępczych i przydzielono płaszczyznę 15 i płaszczyznę 16 do użytku prywatnego .
2,1 maj 1998 ISO/IEC 10646-1:1993 plus poprawki 5, 6 i 7, a także dwa znaki z poprawki 18 25 38 887
(2 dodane)
Dodano znak Euro i znak zastępujący obiekt .
3,0 wrzesień 1999 ISBN  0-201-61633-5 ISO/IEC 10646-1:2000 38 49 194
(10 307 dodane)
Dodano czerokeski , etiopski , khmerski , mongolski , birmański , ogham , runiczny , syngaleski , syryjski , thaana , ujednolicone sylaby kanadyjskie aborygeńskie i sylaby Yi , a także zestaw wzorów brajlowskich .
3.1 Marzec 2001 ISO/IEC 10646-1:2000

ISO/IEC 10646-2:2001

41 94 140
(dodane 44 946)
Dodano pustynne , gotyckie i staroitalskie , a także zestawy symboli dla muzyki zachodniej i bizantyjskiej oraz 42 711 dodatkowych ideogramów zunifikowanych CJK .
3.2 Marzec 2002 ISO/IEC 10646-1:2000 plus poprawka 1

ISO/IEC 10646-2:2001

45 95 156
(dodane 1016)
Dodano skrypty filipińskie Buhid , Hanunó'o , Tagalog i Tagbanwa .
4.0 kwiecień 2003 ISBN  0-321-18578-1 ISO/IEC 10646:2003 52 96 382
(dodane 1226)
Dodano sylabariusz cypryjski , Limbu , Linear B , Osmanya , Shavian , Tai Le i Ugaritic , a także symbole Heksagramu .
4.1 Marzec 2005 ISO/IEC 10646:2003 plus poprawka 1 59 97 655
(dodane 1273 )
Bugiński , głagolicy , Kharoszthi , New Tai Lue , staroperski , Syloti Nagri i Tifinagh dodał i koptyjski został disunified z greki . Dodano również starożytne greckie cyfry i symbole muzyczne .
5.0 Lipiec 2006 ISBN  0-321-48091-0 ISO/IEC 10646:2003 plus Poprawki 1 i 2, a także cztery znaki z Poprawki 3 64 99 024
(dodane 1369 )
Balijski , klinowy , N'Ko , Phags-pa i fenicki .
5.1 kwiecień 2008 ISO/IEC 10646:2003 plus poprawki 1, 2, 3 i 4 75 100 648
(dodane 1624)
Dodano Carian , Cham , Kayah Li , Lepcha , Lycian , Lydian , Ol Chiki , Rejang , Saurashtra , Sundanese i Vai , a także zestawy symboli dla płytek Phaistos Disc , Mahjong i Domino . Były też ważne dodatki dla języka birmańskiego , dodatki liter i skrótów skrybów używanych w średniowiecznych rękopisach , a także dodatek Wielkiego .
5.2 Październik 2009 ISBN  978-1-936213-00-9 ISO/IEC 10646:2003 plus poprawki 1, 2, 3, 4, 5 i 6 90 107 296
(dodane 6648 )
Avestan , Bamum , egipskie hieroglify ( zestaw Gardinera zawierający 1071 znaków), cesarski aramejski , inskrypcyjny pahlavi , inskrypcyjny Partów , jawajski , Kaithi , Lisu , Meetei Mayek , Old South Arabian , Old Turkic , Samarytan , Tai Tham i Tai Vit . 4149 dodatkowych zunifikowanych ideogramów CJK (CJK-C), a także rozszerzone Jamo dla Old Hangul i postacie dla sanskrytu wedyjskiego .
6,0 Październik 2010 ISBN  978-1-936213-01-6 ISO/IEC 10646:2010 plus znak rupii indyjskiej 93 109 384
(2 088 dodane)
Batak , Brahmi , Mandaic , symbole kart do gry, symbole transportu i mapy, symbole alchemiczne , emotikony i emotikony . Dodano 222 dodatkowe ujednolicone ideogramy CJK (CJK-D).
6,1 styczeń 2012 ISBN  978-1-936213-02-3 ISO/IEC 10646:2012 100 110 116
(dodano 732)
Czakma , meroickie kursywa , hieroglify meroickie , Miao , Sharada , Sora Sompeng i Takri .
6,2 wrzesień 2012 ISBN  978-1-936213-07-8 ISO/IEC 10646:2012 plus znak tureckiej liry 100 110 117
(1 dodano)
Znak liry tureckiej .
6,3 wrzesień 2013 ISBN  978-1-936213-08-5 ISO/IEC 10646:2012 plus sześć znaków 100 110 122
(5 dodanych)
5 dwukierunkowych znaków formatujących.
7,0 czerwiec 2014 ISBN  978-1-936213-09-2 ISO/IEC 10646:2012 plus poprawki 1 i 2, a także znak rubla 123 112 956
(2834 dodane)
Bassa Wach , Kaukaski albański , Duployan , Elbasan , grantha , Khojki , Khudawadi , normalny , Mahadżani , Manichaean , Mende Kikakui , Modi , Mro , Nabataean , Old North Arabian , Old Permic , Pismo Pahawh Hmong , Palmyrene , Pau Cin Hau , Psałterz Pahlavi , Siddham , Tirhuta , Warang Citi i Dingbats .
8,0 Czerwiec 2015 ISBN  978-1-936213-10-8 ISO / IEC 10646: 2014 plus poprawka 1, a także znak Lari , dziewięć zunifikowanych ideogramów CJK i 41 znaków emoji 129 120 672
(dodane 7716 )
Ahom , anatolijskie hieroglify , Hatran , Multani , staro węgierski , SignWriting , 5771 ujednoliconych ideogramów CJK , zestaw małych liter dla Cherokee i pięć modyfikatorów odcieni skóry emoji .
9,0 czerwiec 2016 ISBN  978-1-936213-13-9 ISO / IEC 10646: 2014 plus poprawki 1 i 2, a także Adlam, Newa, japońskie symbole telewizyjne oraz 74 emotikony i symbole 135 128 172
(dodano 7500)
Adlam , Bhaiksuki , Marchen , Newa , Osage , Tangut i 72 emoji .
10,0 Czerwiec 2017 ISBN  978-1-936213-16-0 ISO / IEC 10646: 2017 plus 56 znaków emoji , 285 znaków hentaigana i 3 znaki kwadratowe Zanabazar 139 136 690
(dodane 8518)
Plac Zanabazar , Soyombo , Masaram Gondi , Nüshu , hentaigana (niestandardowa hiragana ), 7494 ujednolicone ideogramy CJK , 56 emoji i symbol bitcoina .
11,0 czerwiec 2018 ISBN  978-1-936213-19-1 ISO / IEC 10646: 2017 plus poprawka 1, a także 46 gruzińskich wielkich liter Mtavruli, 5 ujednoliconych ideogramów CJK i 66 znaków emoji. 146 137 374
(684 dodane)
Dogra , gruziński Mtavruli litery, Gunjala Gondi , Hanifi Rohingya , numery Indic Siyaq , Makasar , Medefaidrin , Old Sogdian i Sogdian , liczebników Majów , 5 pilnie potrzebne ujednoliconych ideogramów CJK , symbole Xiangqi (chińskie szachy) i ocen w postaci gwiazdek i 145 emotikonami .
12,0 Marzec 2019 ISBN  978-1-936213-22-1 ISO/IEC 10646:2017 plus poprawki 1 i 2, a także 62 dodatkowe znaki. 150 137 928
(554 dodane)
Elymaic , Nandinagari , Nyiakeng Puachue Hmong , Wancho , Miao dodatki do skryptów dla kilku dialektów Miao i Yi w Chinach, małe litery hiragana i katakana do pisania archaicznego języka japońskiego, historyczne ułamki i symbole tamilskie , litery laotańskie dla palijskiego , litery łacińskie dla transliteracji egiptologicznej i ugaryckiej , kontrolki formatu hieroglifów i 61 emotikonów .
12,1 Maj 2019 ISBN  978-1-936213-25-2 150 137 929
(1 dodano)
Dodaje pojedynczy znak przy U+32FF dla formy ligatury kwadratowej nazwy epoki Reiwa .
13,0 Marzec 2020 ISBN  978-1-936213-26-9 ISO/IEC 10646:2020 154 143 859
( 5930 dodanych)
Chorasmian , Dives Akuru , Khitan mały skrypt , jazydów , 4,969 ujednoliconych ideogramów CJK dodanej (w tym 4,939 w wew. G ), arabski uzupełnienia Skrypt używany do pisania hausa , wolof i innych języków w Afryce i innych dodatków używany do pisania Hindko i Punjabi w Pakistan, dodatki Bopomofo używane w kantońskim, symbole licencji Creative Commons, znaki graficzne zapewniające kompatybilność z teletekstem i domowymi systemami komputerowymi z lat 70. i 80. XX wieku oraz 55 emotikonów.
14,0 wrzesień 2021 ISBN  978-1-936213-29-0 159 144.697
(dodano 838)
Toto , Cypro-Mino , Vithkuqi , Stary Ujgur , Tangsa , dodatki w alfabecie łacińskim w blokach SMP (Ext-F, Ext-G) do użytku w rozszerzonym IPA , dodatki w alfabecie arabskim do użytku w językach w całej Afryce oraz w Iranie, Pakistanie i Malezji , Indonezji, Jawy i Bośni oraz pisać zwroty grzecznościowe , dodatki do użytku Koranu, inne dodatki do obsługi języków w Ameryce Północnej, Filipinach, Indiach i Mongolii, dodanie symbolu waluty kirgiskiej som , obsługa notacji muzycznej Znamenny , oraz 37 emotikonów.

Architektura i terminologia

Standard Unicode definiuje przestrzeń kodową, zestaw wartości liczbowych z zakresu od 0 do 10FFFF 16 , zwanych punktami kodowymi i oznaczonych jako U+0000 do U+10FFFF ("U+" plus wartość punktu kodowego w systemie szesnastkowym , poprzedzona w razie potrzeby wiodącymi zerami spowoduje co najmniej czterech cyfr, np. g. U + 00F7 na znak podziału ÷ ale u + 13254 do hieroglifu egipskiej Hiero O4.png wyznaczającej schronienie kontaktronowy lub uzwojenia ściany . Spośród tych 2 16 + 2 20 punktami kodowe, kody punktów od U+D800 do U+DFFF, które są używane do kodowania par zastępczych w UTF-16 , są zarezerwowane przez normę i nie mogą być używane do kodowania poprawnych znaków, co daje sumę netto 2 16 − 2 11 + 2 20 = 1 112 064 możliwych punktów kodowych odpowiadających prawidłowym znakom Unicode. Nie wszystkie z tych punktów kodowych muszą koniecznie odpowiadać widocznym znakom; kilka, na przykład, jest przypisanych do kodów kontrolnych, takich jak powrót karetki .

Samoloty kodowe i bloki

Przestrzeń kodowa Unicode jest podzielona na siedemnaście płaszczyzn , ponumerowanych od 0 do 16:

Wszystkie punkty kodowe w BMP są dostępne jako pojedyncza jednostka kodu w kodowaniu UTF-16 i mogą być zakodowane w jednym, dwóch lub trzech bajtach w UTF-8 . Punkty kodowe w płaszczyznach od 1 do 16 ( płaszczyzny dodatkowe ) są dostępne jako pary zastępcze w UTF-16 i zakodowane w czterech bajtach w UTF-8.

W każdej płaszczyźnie znaki są alokowane w nazwanych blokach powiązanych znaków. Chociaż bloki mają dowolny rozmiar, zawsze są wielokrotnością 16 punktów kodowych i często wielokrotnością 128 punktów kodowych. Znaki wymagane w danym skrypcie mogą być rozłożone na kilka różnych bloków.

Właściwość kategorii ogólnej

Każdy punkt kodowy ma jedną właściwość Kategoria ogólna . Oznaczone są główne kategorie: Litera, Znak, Cyfra, Interpunkcja, Symbol, Separator i Inne. W ramach tych kategorii istnieją podpodziały. W większości przypadków należy użyć innych właściwości, aby wystarczająco określić charakterystykę punktu kodowego. Możliwe kategorie ogólne to:

Kategoria ogólna ( właściwość znaku Unicode )
Wartość Kategoria Główne, drobne Typ podstawowy Przypisana postać Liczyć
(od 14.0)
Uwagi
 
L, litera; LC, list w obudowie (tylko Lu, Ll i Lt)
Lu Litera, wielkie litery Graficzny Postać 1,831
NS Litera, małe litery Graficzny Postać 2227
Lt List, tytułowy Graficzny Postać 31 Ligatury zawierające wielkie litery, po których następują małe litery (np. Dž , Lj , Nj i Dz )
Lm List, modyfikator Graficzny Postać 334 Modyfikator list
Lo List, inne Graficzny Postać 127,333 Ideogram lub list w Unicase alfabetu
M, Mark
Mn Znak, bez odstępów Graficzny Postać 1950
Mc Znak, odstępy łączenie Graficzny Postać 445
Ja Znak, załączając Graficzny Postać 13
N, liczba
NS Liczba, cyfra dziesiętna Graficzny Postać 660 Wszystkie te i tylko te mają Typ Numeryczny = De
Nl Cyfra, litera Graficzny Postać 236 Cyfry składające się z liter lub symboli literopodobnych (np. cyfry rzymskie )
Nie Liczba, inne Graficzny Postać 895 Np frakcje wulgarne , górny i dolny cyfry
P, interpunkcja
PC Interpunkcja, łącznik Graficzny Postać 10 Zawiera podkreślenie „_”
Pd Interpunkcja, myślnik Graficzny Postać 26 Zawiera kilka myślnikiem znaków
Ps Interpunkcja, otwarta Graficzny Postać 79 Znaki nawiasu otwierającego
Pe Interpunkcja, zamknij Graficzny Postać 77 Znaki nawiasu zamykającego
Liczba Pi Interpunkcja, początkowy cytat Graficzny Postać 12 Otwarcie cudzysłów . Nie zawiera „neutralnego” cudzysłowu ASCII. Może zachowywać się jak Ps lub Pe w zależności od zastosowania
Pf Interpunkcja, ostatni cytat Graficzny Postać 10 Końcowy cudzysłów. Może zachowywać się jak Ps lub Pe w zależności od zastosowania
Po Interpunkcja, inne Graficzny Postać 605
S, symbol
Sm Symbol, matematyka Graficzny Postać 948 Symbole matematyczne (np. + , , = , × , ÷ , , , ). Nie zawiera nawiasów i nawiasów, które należą do kategorii Ps i Pe. Również nie obejmuje ! , * , - lub / , które pomimo częstego używania jako operatorów matematycznych, są przede wszystkim uważane za „interpunkcyjne”.
Sc Symbol, waluta Graficzny Postać 63 Symbole walut
Sk Symbol, modyfikator Graficzny Postać 125
Więc Symbol, inne Graficzny Postać 6605
Z, separator
Zs Separator, spacja Graficzny Postać 17 Zawiera spację, ale nie TAB , CR ani LF , które są Cc
Złoty Separator, linia Format Postać 1 Tylko SEPARATOR LINII U+2028 (LSEP)
Z p Separator, akapit Format Postać 1 Tylko SEPARATOR AKAPITÓW U+2029 (PSEP)
C, inne
DW Inne, kontrola Kontrola Postać 65 (nigdy się nie zmieni) Bez imienia, <sterowanie>
cf Inne, format Format Postać 163 Zawiera łącznik miękki , łączące znaki sterujące ( zwnj i zwj ), znaki sterujące obsługujące tekst dwukierunkowy oraz znaki znaczników języka
Cs Inne, surogat Surogat Nie (używany tylko w UTF-16 ) 2048 (nigdy się nie zmieni) Bez imienia, <surogat>
Współ Inne, do użytku prywatnego Użytek prywatny Charakter (ale nie określono interpretacji) 137 468 ogółem (nigdy się nie zmieni) ( 6 400 w BMP , 131 068 w samolotach 15-16 ) Brak nazwy, <do użytku prywatnego>
Cn Inne, nieprzypisane Nieznakowy Nie 66 (nigdy się nie zmieni) Bez imienia, <nieznakowy>
Skryty Nie 829 768 Bez imienia, <zarezerwowane>

Punkty kodu w zakresie U + D800-U + DBFF (1024 punktów kodu) są znane jako wysokiej zastępczym punktów kodowych i punktów kodowych w zakresie U + DC00-U + DFFF (1024 punktów kodu) są znane jako surogat niskiej punkty kodowe. Punkt kodowy o wysokim surogacie, po którym następuje punkt kodowy o niskim surogacie, tworzą parę zastępczą w UTF-16, aby reprezentować punkty kodowe większe niż U+FFFF. W przeciwnym razie te punkty kodowe nie mogą być użyte (ta reguła jest często ignorowana w praktyce, zwłaszcza gdy nie używa się UTF-16).

Gwarantuje się, że mały zestaw punktów kodowych nigdy nie zostanie użyty do kodowania znaków, chociaż aplikacje mogą korzystać z tych punktów kodowych wewnętrznie, jeśli sobie tego życzą. Istnieje sześćdziesiąt sześć takich nieznaków : U+FDD0–U+FDEF i dowolny punkt kodowy kończący się wartością FFFE lub FFFF (tj. U+FFFE, U+FFFF, U+1FFFE, U+1FFFF, ... U +10FFFE, U+10FFFF). Zbiór nieznaków jest stabilny i nigdy nie zostaną zdefiniowane żadne nowe nieznaki. Podobnie jak w przypadku surogatów, reguła, że ​​nie można ich użyć, jest często ignorowana, chociaż działanie znacznika kolejności bajtów zakłada, że ​​U+FFFE nigdy nie będzie pierwszym punktem kodowym w tekście.

Z wyłączeniem surogatów i nieznaków pozostawia 1111998 punktów kodowych dostępnych do użycia.

Punkty kodowe do użytku prywatnego są uważane za przypisane znaki, ale nie mają interpretacji określonej przez standard Unicode, więc każda zamiana takich znaków wymaga porozumienia między nadawcą a odbiorcą w sprawie ich interpretacji. W przestrzeni kodowej Unicode istnieją trzy obszary prywatnego użytku:

  • Obszar prywatnego użytku: U+E000–U+F8FF (6400 znaków),
  • Dodatkowy obszar prywatnego użytku-A: U+F0000–U+FFFFD (65 534 znaków),
  • Dodatkowy obszar prywatnego użytku B: U+10000–U+10FFFD (65 534 znaków).

Znaki graficzne to znaki zdefiniowane przez Unicode, które mają określoną semantykę i albo mają widoczny kształt glifu, albo reprezentują widoczną przestrzeń. Od Unicode 14.0 jest 144,532 znaków graficznych.

Znaki formatowania to znaki, które nie mają widocznego wyglądu, ale mogą mieć wpływ na wygląd lub zachowanie sąsiednich znaków. Na przykład, U+200C ZERO WIDTH NON-JOINER i U+200D ZERO WIDTH JOINER mogą być użyte do zmiany domyślnego zachowania kształtowania sąsiednich znaków (np. w celu zahamowania ligatur lub żądania tworzenia ligatur). W Unicode 14.0 jest 165 znaków formatu.

Sześćdziesiąt pięć punktów kodowych (U+0000-U+001F i U+007F-U+009F) jest zarezerwowanych jako kody kontrolne i odpowiadają kodom kontrolnym C0 i C1 zdefiniowanym w ISO/IEC 6429 . U+0009 (Tab), U+000A (Line Feed) i U+000D (Carriage Return) są szeroko stosowane w tekstach zakodowanych w Unicode. W praktyce punkty kodowe C1 są często nieprawidłowo tłumaczone ( mojibake ) jako starsze znaki Windows-1252 używane w niektórych tekstach angielskich i zachodnioeuropejskich.

Znaki graficzne, znaki formatujące, znaki kodu sterującego i znaki do użytku prywatnego są określane zbiorczo jako znaki przypisane . Zarezerwowane punkty kodowe to te punkty kodowe, które są dostępne do użytku, ale nie zostały jeszcze przypisane. Od Unicode 14.0 istnieje 829 768 zarezerwowanych punktów kodowych.

Abstrakcyjne postacie

Zestaw znaków graficznych i formatujących zdefiniowanych przez Unicode nie odpowiada bezpośrednio repertuarowi znaków abstrakcyjnych, które są reprezentowane w Unicode. Unicode koduje znaki, kojarząc abstrakcyjny znak z określonym punktem kodowym. Jednak nie wszystkie znaki abstrakcyjne są kodowane jako pojedynczy znak Unicode, a niektóre znaki abstrakcyjne mogą być reprezentowane w Unicode przez sekwencję dwóch lub więcej znaków. Na przykład, małe łacińska litera „i” o Ogonek , A dot powyżej , oraz ostra nacisk , który jest wymagany w litewskim jest reprezentowana przez ciąg znaków U + 012F, U + 0307, U + 0301. Unicode utrzymuje listę unikatowo nazwanych sekwencji znaków dla znaków abstrakcyjnych, które nie są bezpośrednio zakodowane w Unicode.

Wszystkie znaki graficzne, formatowe i do użytku prywatnego mają unikalną i niezmienną nazwę, dzięki której mogą być identyfikowane. Ta niezmienność jest gwarantowana od wersji Unicode 2.0 przez zasady stabilności nazw. W przypadkach, gdy nazwa jest poważnie błędna i wprowadza w błąd lub zawiera poważny błąd typograficzny, można zdefiniować alias formalny, a aplikacje zachęca się do używania aliasu formalnego w miejsce oficjalnej nazwy postaci. Na przykład, U + A015 YI sylaby WU ma formalne alias YI sylaby iteracji MARK i U + FE18 PRZEDSTAWIENIE POSTAĆ do pionowego prawej biały soczewkowe BRA KC ET ( sic! ) Ma formalne ps postaci użytkowej do pionowego prawej biały soczewkowe BRA CK ET .

Gotowe a złożone postacie

Unicode zawiera mechanizm modyfikacji znaków, który znacznie rozszerza obsługiwany repertuar glifów. Obejmuje to użycie łączenia znaków diakrytycznych, które mogą być dodawane przez użytkownika po znaku bazowym. Wielokrotne kombinacje znaków diakrytycznych mogą być stosowane jednocześnie do tego samego znaku. Unicode zawiera również wstępnie skomponowane wersje większości kombinacji liter i znaków diakrytycznych w normalnym użyciu. Ułatwiają one konwersję do i ze starszych kodowań i umożliwiają aplikacjom używanie Unicode jako wewnętrznego formatu tekstu bez konieczności implementowania łączenia znaków. Na przykład é może być reprezentowane w Unicode jako U+ 0065 ( LATIN MAŁA LITERA E ), a następnie U+0301 ( POŁĄCZENIE OSTREGO AKCENTU ), ale może być również reprezentowane jako prekomponowany znak U+00E9 ( ŁACIŃSKA MAŁA LITERA E Z OSTRĄ ) . Dlatego w wielu przypadkach użytkownicy mają wiele sposobów kodowania tego samego znaku. Aby sobie z tym poradzić, Unicode zapewnia mechanizm równoważności kanonicznej .

Przykładem tego jest Hangul , alfabet koreański. Unicode zapewnia mechanizm do komponowania sylab Hangul z ich indywidualnymi podkomponentami, znany jako Hangul Jamo . Jednak zapewnia również 11172 kombinacji wstępnie skomponowanych sylab wykonanych z najczęstszego jamo.

Do znaków CJK mają obecnie kody tylko dla ich precomposed formie. Mimo to większość z tych znaków zawiera prostsze elementy (nazywane rodnikami ), więc w zasadzie Unicode mógł je rozłożyć, tak jak w przypadku Hangul. To znacznie zmniejszyłoby liczbę wymaganych punktów kodowych, jednocześnie umożliwiając wyświetlanie praktycznie każdego wyobrażalnego znaku (co może wyeliminować niektóre problemy spowodowane przez unifikację Han ). Podobny pomysł jest używany przez niektóre metody wprowadzania , takie jak Cangjie i Wubi . Jednak próby zrobienia tego dla kodowania znaków natknęły się na fakt, że chińskie znaki nie rozkładają się tak prosto i tak regularnie, jak robi to Hangul.

Zestaw rodników został dostarczony w Unicode 3.0 (rodniki CJK między U+2E80 i U+2EFF, radykały KangXi w U+2F00 do U+2FDF i znaki opisu ideograficznego od U+2FF0 do U+2FFB), ale standard Unicode (rozdz. 12.2 Unicode 5.2) ostrzega przed używaniem sekwencji opisu ideograficznego jako alternatywnej reprezentacji wcześniej zakodowanych znaków:

Ten proces różni się od formalnego kodowania ideogramu. Nie ma kanonicznego opisu niekodowanych ideogramów; nie ma semantyki przypisanej opisywanym ideogramom; nie ma zdefiniowanej ekwiwalencji dla opisanych ideogramów. Koncepcyjnie opisy ideograficzne są bardziej zbliżone do angielskiego wyrażenia „an 'e' z ostrym akcentem” niż do sekwencji znaków <U+0065, U+0301>.

Ligatury

Wiele skryptów, w tym arabski i devanāgarī , ma specjalne zasady ortograficzne, które wymagają łączenia pewnych kombinacji form liter w specjalne formy ligatur . Zasady rządzące tworzeniem ligatur mogą być dość złożone, wymagając specjalnych technologii kształtowania skryptów, takich jak ACE (Arabic Calligraphic Engine firmy DecoType w latach 80. i używany do generowania wszystkich arabskich przykładów w drukowanych wydaniach standardu Unicode), co stało się dowodem koncepcji dla OpenType (firmy Adobe i Microsoft), Graphite (firmy SIL International ) lub AAT (firmy Apple).

W czcionkach osadzone są również instrukcje, które informują system operacyjny, jak poprawnie wypisać różne sekwencje znaków. Prostym rozwiązaniem na umieszczenie znaków łączących lub diakrytycznych jest przypisanie znakom szerokości zerowej i umieszczenie samego glifu po lewej lub prawej stronie lewego łożyska bocznego (w zależności od kierunku pisma, z którym mają być używane). Tak obsłużony znacznik pojawi się na znaku poprzedzającym go, ale nie dostosuje swojego położenia względem szerokości lub wysokości glifu bazowego; może to być niewygodne wizualnie i może nakładać się na niektóre glify. Rzeczywiste układanie w stos jest niemożliwe, ale może być przybliżone w ograniczonych przypadkach (na przykład tajskie samogłoski łączące górne i znaki tonów mogą być na początku po prostu na różnych wysokościach). Ogólnie to podejście jest skuteczne tylko w przypadku czcionek o stałej szerokości, ale może być używane jako zastępcza metoda renderowania, gdy bardziej złożone metody zawiodą.

Standaryzowane podzbiory

Kilka podzbiorów Unicode jest standaryzowanych: Microsoft Windows od Windows NT 4.0 obsługuje WGL-4 z 657 znakami, który jest uważany za obsługujący wszystkie współczesne języki europejskie używające alfabetu łacińskiego, greckiego lub cyrylicy. Inne znormalizowane podzbiory Unicode obejmują wielojęzyczne podzbiory europejskie:

MES-1 (tylko alfabety łacińskie, 335 znaków), MES-2 (znaki łacińskie, greckie i cyrylica 1062) oraz MES-3A i MES-3B (dwa większe podzbiory, nie pokazane tutaj). Zauważ, że MES-2 zawiera wszystkie znaki w MES-1 i WGL-4.

WGL-4 , MES-1 i MES-2
Wiersz Komórki Zakres(y)
00 20-7E Łacina podstawowa (00–7F)
A0–FF Dodatek Latin-1 (80-FF)
01 00-13, 14-15, 16-2B, 2C-2D, 2E-4D, 4E-4F, 50-7E, 7F Rozszerzony łaciński-A (00–7F)
8F, 92, B7, DE-EF, FA-FF Łacińska Rozszerzona-B (80-FF ... )
02 18-1B, 1E-1F Rozszerzony łaciński-B ( ... 00–4F)
59, 7C, 92 Rozszerzenia IPA (50–AF)
BB–BD, C6, C7, C9, D6, D8–DB, DC, DD, DF, EE Odstępy między literami modyfikującymi (B0–FF)
03 74-75, 7A, 7E, 84-8A, 8C, 8E-A1, A3-CE, D7, DA-E1 Grecki (70-FF)
04 00–5F, 90–91, 92–C4, C7–C8, CB–CC, D0–EB, EE–F5, F8–F9 cyrylica (00–FF)
1E 02–03, 0A–0B, 1E–1F, 40–41, 56–57, 60–61, 6A–6B, 80–85, 9B, F2–F3 Rozszerzony łaciński dodatkowy (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–WF Rozszerzony grecki (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 Ogólna interpunkcja (00–6F)
7F , 82 Indeksy górne i dolne (70-9F)
A3–A4, A7, AC, AF Symbole walut (A0–CF)
21 05, 13, 16, 22, 26, 2E Symbole literopodobne (00–4F)
5B-5E Formy liczbowe (50–8F)
90–93, 94–95, A8 Strzały (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 Operatory matematyczne (00-FF)
23 02, 0A, 20–21, 29–2A Różne techniczne (00–FF)
25 00, 02, 0C, 10, 14, 18, 1C, 24, 2C, 34, 3C, 50–6C Rysunek w pudełku (00–7F)
80, 84, 88, 8C, 90–93 Elementy blokowe (80–9F)
A0–A1, AA–AC, B2, BA, BC, C4, CA–CB, CF, D8–D9, E6 Kształty geometryczne (A0–FF)
26 3A–3C, 40, 42, 60, 63, 65–66, 6A, 6B Różne symbole (00–FF)
F0 (01–02) Obszar prywatnego użytku (00–FF ...)
pełne wyżywienie 01–02 Alfabetyczne formularze prezentacji (00–4F)
FF FD Promocje

Oprogramowanie renderujące, które nie może odpowiednio przetworzyć znaku Unicode, często wyświetla go jako otwarty prostokąt lub „ znak zastępczy ” Unicode (U+FFFD, ), aby wskazać pozycję nierozpoznanego znaku. Niektóre systemy podjęły próby dostarczenia większej ilości informacji o takich postaciach. Apple czcionki Last Resort wyświetli glif zastępczej wskazujący zakres Unicode znaku i SIL International „s czcionki Unicode awaryjny zostanie wyświetlone okno pokazujące wartość skalarna szesnastkowy znaku.

Mapowanie i kodowanie

Określono kilka mechanizmów przechowywania serii punktów kodowych jako serii bajtów.

Unicode definiuje dwie metody mapowania: kodowanie Unicode Transformation Format (UTF) i kodowanie Universal Coded Character Set (UCS). Kodowanie odwzorowuje (prawdopodobnie podzbiór) zakresu punktów kodu Unicode na sekwencje wartości w pewnym zakresie o stałym rozmiarze, określanym jako jednostki kodu . Wszystkie kodowania UTF mapują punkty kodu na unikatową sekwencję bajtów. Liczby w nazwach kodowań wskazują liczbę bitów na jednostkę kodu (dla kodowań UTF) lub liczbę bajtów na jednostkę kodu (dla kodowań UCS i UTF-1 ). UTF-8 i UTF-16 to najczęściej używane kodowania. UCS-2 to przestarzały podzbiór UTF-16; UCS-4 i UTF-32 są funkcjonalnie równoważne.

Kodowania UTF obejmują:

  • UTF-8 , używa od jednego do czterech bajtów na każdy punkt kodowy, maksymalizuje kompatybilność z ASCII
  • UTF-EBCDIC , podobny do UTF-8, ale zaprojektowany pod kątem zgodności z EBCDIC (nie jest częścią standardu Unicode )
  • UTF-16 , wykorzystuje jedną lub dwie 16-bitowe jednostki kodu na punkt kodowy, nie może kodować surogatów
  • UTF-32 , używa jednej 32-bitowej jednostki kodu na punkt kodowy

UTF-8 wykorzystuje od jednego do czterech bajtów na punkt kodowy i, będąc kompaktowym dla skryptów łacińskich i kompatybilnym z ASCII, zapewnia de facto standardowe kodowanie do wymiany tekstu Unicode. Jest używany przez FreeBSD i najnowsze dystrybucje Linuksa jako bezpośredni zamiennik starszego kodowania w ogólnej obsłudze tekstu.

Kodowania UCS-2 i UTF-16 określają Unicode Byte Order Mark (BOM) do użycia na początku plików tekstowych, który może być użyty do wykrywania kolejności bajtów (lub wykrywania końca bajtów ). BOM, punkt kodowy U + FEFF, ma ważną właściwość jednoznaczności przy zmianie kolejności bajtów, niezależnie od użytego kodowania Unicode; U+FFFE (wynik zamiany bajtów U+FEFF) nie oznacza znaku prawnego, a U+FEFF w miejscach innych niż początek tekstu przekazuje spację o zerowej szerokości nierozdzielającej (znak bez wyglądu i nie ma innego efektu niż zapobieganie tworzeniu się podwiązek ).

Ten sam znak przekonwertowany na UTF-8 staje się sekwencją bajtów EF BB BF. Standard Unicode umożliwia, że ​​BOM „może służyć jako podpis dla tekstu zakodowanego w UTF-8, w którym zestaw znaków jest nieoznaczony”. Niektórzy twórcy oprogramowania przyjęli go do innych kodowań, w tym UTF-8, próbując odróżnić UTF-8 od lokalnych 8-bitowych stron kodowych . Jednak RFC  3629 , standard UTF-8, zaleca, aby znaki kolejności bajtów były zabronione w protokołach używających UTF-8, ale omawia przypadki, w których może to nie być możliwe. Ponadto duże ograniczenie możliwych wzorców w UTF-8 (na przykład nie może być żadnych pojedynczych bajtów z ustawionym wysokim bitem) oznacza, że ​​powinno być możliwe odróżnienie UTF-8 od innych kodowań znaków bez polegania na BOM.

W UTF-32 i UCS-4 jedna 32-bitowa jednostka kodu służy jako dość bezpośrednia reprezentacja punktu kodowego dowolnego znaku (chociaż endianowość, która różni się na różnych platformach, wpływa na sposób, w jaki jednostka kodu manifestuje się jako sekwencja bajtów). W innych kodowaniach każdy punkt kodowy może być reprezentowany przez zmienną liczbę jednostek kodu. UTF-32 jest szeroko stosowany jako wewnętrzna reprezentacja tekstu w programach (w przeciwieństwie do przechowywanego lub przesyłanego tekstu), ponieważ każdy system operacyjny Unix, który używa kompilatorów gcc do generowania oprogramowania, używa go jako standardowego kodowania „ znaków szerokich ”. Niektóre języki programowania, takie jak Seed7 , używają UTF-32 jako wewnętrznej reprezentacji ciągów i znaków. Najnowsze wersje języka programowania Python (począwszy od 2.2) mogą być również skonfigurowane do używania UTF-32 jako reprezentacji ciągów Unicode, skutecznie rozpowszechniając takie kodowanie w kodowanym oprogramowaniu wysokiego poziomu .

Punycode , inna forma kodowania, umożliwia kodowanie Unicode do ograniczonego zestawu znaków obsługiwanego przez ASCII -na Domain Name System (DNS). Kodowanie jest wykorzystywane w ramach IDNA , czyli systemu umożliwiającego stosowanie międzynarodowych nazw domen we wszystkich skryptach obsługiwanych przez Unicode. Wcześniejsze i obecnie historyczne propozycje obejmują UTF-5 i UTF-6 .

GB18030 to kolejna forma kodowania dla Unicode od Chińskiej Administracji Normalizacyjnej . Jest to oficjalny zestaw znaków ogłoszenia tego Republiki Ludowej (ChRL). BOCU-1 i SCSU to schematy kompresji Unicode. W primaaprilisowym RFC 2005 r. określono dwa kodowania parodii UTF, UTF-9 i UTF-18 .

Przyjęcie

System operacyjny

Unicode stał się dominującym schematem wewnętrznego przetwarzania i przechowywania tekstu. Chociaż duża część tekstu jest nadal przechowywana w starszych kodowaniach, Unicode jest używany prawie wyłącznie do tworzenia nowych systemów przetwarzania informacji. Pierwsi użytkownicy mieli tendencję do używania UCS-2 (dwubajtowego prekursora UTF-16 o stałej szerokości), a później przenieśli się na UTF-16 (bieżący standard o zmiennej szerokości), ponieważ był to najmniej destrukcyjny sposób na dodanie obsługi nie -Znaki BMP. Najbardziej znanym takim systemem jest Windows NT (i jego potomkowie, Windows 2000 , Windows XP , Windows Vista , Windows 7 , Windows 8 i Windows 10 ), który używa UTF-16 jako jedynego wewnętrznego kodowania znaków. Środowiska kodu bajtowego Java i .NET , macOS i KDE również używają go do wewnętrznej reprezentacji. Częściową obsługę Unicode można zainstalować w systemie Windows 9x za pośrednictwem warstwy Microsoft dla Unicode .

UTF-8 (pierwotnie opracowany dla Planu 9 ) stał się głównym kodowaniem pamięci masowej w większości systemów operacyjnych podobnych do Uniksa (chociaż inne są również używane przez niektóre biblioteki), ponieważ jest stosunkowo łatwym zamiennikiem tradycyjnych rozszerzonych zestawów znaków ASCII . UTF-8 jest również najpopularniejszym kodowaniem Unicode używanym w dokumentach HTML w sieci WWW .

Wielojęzyczne silniki renderowania tekstu, które używają Unicode, obejmują Uniscribe i DirectWrite dla Microsoft Windows, ATSUI i Core Text dla macOS oraz Pango dla GTK+ i pulpitu GNOME .

Metody wprowadzania

Ponieważ układy klawiatury nie mogą mieć prostych kombinacji klawiszy dla wszystkich znaków, kilka systemów operacyjnych zapewnia alternatywne metody wprowadzania, które umożliwiają dostęp do całego repertuaru.

Norma ISO/IEC 14755 , która standaryzuje metody wprowadzania znaków Unicode z ich punktów kodowych, określa kilka metod. Istnieje metoda Basic , w której po sekwencji początkowej następuje szesnastkowa reprezentacja punktu kodowego i sekwencja końcowa . Istnieje również określona metoda wprowadzania wyboru ekranu , w której znaki są wymienione w tabeli na ekranie, na przykład w programie mapowania znaków.

Narzędzia online do znajdowania punktu kodowego dla znanej postaci obejmują Unicode Lookup autorstwa Jonathana Hedleya i Shapecatcher autorstwa Benjamina Milde. W wyszukiwaniu Unicode wpisuje się klucz wyszukiwania (np. "ułamki") i zwracana jest lista odpowiadających im znaków wraz z ich punktami kodowymi. W Shapecatcher, w oparciu o Shape context , rysuje się znak w polu i zwracana jest lista znaków przybliżających rysunek wraz z ich punktami kodowymi.

E-mail

MIME definiuje dwa różne mechanizmy kodowania znaków spoza zestawu ASCII w wiadomości e-mail , w zależności od tego, czy znaki te znajdują się w nagłówkach wiadomości e-mail (takich jak „Temat:”), czy w treści wiadomości. w obu przypadkach identyfikowany jest oryginalny zestaw znaków oraz kodowanie transferu. W przypadku przesyłania wiadomości e-mail w formacie Unicode zaleca się zestaw znaków UTF-8 i kodowanie transferu Base64 lub Quoted-printable , w zależności od tego, czy znaczna część wiadomości składa się ze znaków ASCII . Szczegóły tych dwóch różnych mechanizmów są określone w standardach MIME i generalnie są ukryte przed użytkownikami oprogramowania pocztowego.

Przyjęcie Unicode w wiadomościach e-mail było bardzo powolne. Niektóre teksty wschodnioazjatyckie są nadal zakodowane w kodowaniach, takich jak ISO-2022 , a niektóre urządzenia, takie jak telefony komórkowe, nadal nie mogą poprawnie obsługiwać danych Unicode. Wsparcie poprawia się jednak. Obsługuje go wielu głównych dostawców bezpłatnej poczty, takich jak Yahoo , Google ( Gmail ) i Microsoft ( Outlook.com ).

Sieć

Wszystkie zalecenia W3C używały Unicode jako zestawu znaków dokumentu od czasu HTML 4.0. Przeglądarki internetowe od wielu lat obsługują Unicode, zwłaszcza UTF-8. Kiedyś występowały problemy z wyświetlaniem wynikające głównie z problemów związanych z czcionkami ; np. wersja 6 i starsza programu Microsoft Internet Explorer nie renderowała wielu punktów kodowych, chyba że wyraźnie nakazano użycie czcionki, która je zawiera.

Chociaż reguły składni mogą wpływać na kolejność, w jakiej znaki mogą się pojawiać, dokumenty XML (w tym XHTML ) z definicji zawierają znaki z większości punktów kodowych Unicode, z wyjątkiem:

Znaki HTML manifestują się bezpośrednio jako bajty zgodnie z kodowaniem dokumentu, jeśli kodowanie je obsługuje, lub użytkownicy mogą zapisywać je jako odwołania do znaków numerycznych na podstawie punktu kodowego Unicode znaku. Na przykład odwołania &#916;, &#1049;, &#1511;, &#1605;, &#3671;, &#12354;, &#21494;, &#33865;, i &#47568;(lub te same wartości liczbowe wyrażone w systemie szesnastkowym, z &#xprefiksem) powinny być wyświetlane we wszystkich przeglądarkach jako Δ, Й, ק ,م, ๗, あ, 叶, 葉i .

Podczas określania identyfikatorów URI , na przykład jako adresy URL w żądaniach HTTP , znaki spoza zestawu ASCII muszą być zakodowane w procentach .

Czcionki

Unicode w zasadzie nie zajmuje się czcionkami per se , traktując je jako wybory implementacyjne. Dowolny znak może mieć wiele allografów , od bardziej powszechnych liter pogrubionych, kursywnych i podstawowych po złożone style dekoracyjne. Czcionka jest „zgodna z Unicode”, jeśli dostęp do glifów w czcionce można uzyskać za pomocą punktów kodowych zdefiniowanych w standardzie Unicode. Norma nie określa minimalnej liczby znaków, które muszą być zawarte w czcionce; niektóre czcionki mają dość mały repertuar.

Darmowe i detaliczne czcionki oparte na Unicode są powszechnie dostępne, ponieważ TrueType i OpenType obsługują Unicode. Te formaty czcionek mapują punkty kodowe Unicode na glify, ale czcionka TrueType jest ograniczona do 65 535 glifów.

Na rynku istnieją tysiące czcionek , ale mniej niż tuzin czcionek — czasami określanych jako czcionki „pan-Unicode” — usiłuje obsługiwać większość repertuaru znaków Unicode. Zamiast tego czcionki oparte na Unicode zwykle koncentrują się na obsłudze tylko podstawowego ASCII i określonych skryptów lub zestawów znaków lub symboli. Kilka powodów uzasadnia takie podejście: aplikacje i dokumenty rzadko muszą renderować znaki z więcej niż jednego lub dwóch systemów pisma; czcionki zwykle wymagają zasobów w środowiskach komputerowych; a systemy operacyjne i aplikacje wykazują coraz większą inteligencję w zakresie uzyskiwania informacji o glifach w razie potrzeby z oddzielnych plików czcionek, tj . zastępowania czcionek . Co więcej, zaprojektowanie spójnego zestawu instrukcji renderowania dla dziesiątek tysięcy glifów stanowi monumentalne zadanie; takie przedsięwzięcie mija punkt malejących zysków dla większości krojów pisma.

Nowe linie

Unicode częściowo rozwiązuje problem nowego wiersza, który występuje podczas próby odczytania pliku tekstowego na różnych platformach. Unicode definiuje dużą liczbę znaków, które zgodne aplikacje powinny rozpoznawać jako terminatory wierszy.

W odniesieniu do nowej linii, Unicode wprowadzono U + 2028 linię oddzielającą i U + 2029 separatora akapitu . Była to próba dostarczenia rozwiązania Unicode do semantycznego kodowania akapitów i wierszy, potencjalnie zastępującego wszystkie różne rozwiązania platformowe. W ten sposób Unicode zapewnia sposób na obejście historycznych rozwiązań zależnych od platformy. Niemniej jednak niewiele rozwiązań Unicode przyjęło te separatory wierszy i akapitów Unicode jako jedyne kanoniczne znaki końca linii. Jednak powszechnym podejściem do rozwiązania tego problemu jest normalizacja nowej linii. Osiąga się to dzięki systemowi tekstowemu Cocoa w Mac OS X, a także dzięki rekomendacjom W3C XML i HTML. W tym podejściu każdy możliwy znak nowej linii jest konwertowany wewnętrznie na zwykły znak nowej linii (co nie ma tak naprawdę znaczenia, ponieważ jest to wewnętrzna operacja tylko do renderowania). Innymi słowy, system tekstowy może poprawnie potraktować znak jako znak nowej linii, niezależnie od rzeczywistego kodowania wejścia.

Zagadnienia

Filozoficzna i kompletna krytyka

Unifikacja Han (identyfikacja form w językach wschodnioazjatyckich, które można traktować jako odmiany stylistyczne o tym samym historycznym charakterze) stała się jednym z najbardziej kontrowersyjnych aspektów Unicode, mimo obecności większości ekspertów ze wszystkich trzech regionów w Ideographic Research Group (IRG), która doradza Konsorcjum i ISO w sprawie uzupełnień repertuaru i zjednoczenia Han.

Unicode był krytykowany za niepowodzenie oddzielnego kodowania starszych i alternatywnych form kanji, co, jak twierdzą krytycy, komplikuje przetwarzanie starożytnych japońskich i niecodziennych japońskich nazw. Wynika to często z faktu, że Unicode koduje znaki, a nie glify (wizualne reprezentacje podstawowego znaku, które często różnią się w zależności od języka). Unifikacja glifów prowadzi do przekonania, że ​​same języki, a nie tylko podstawowe reprezentacje znaków, są scalane. Podjęto kilka prób stworzenia alternatywnych kodowań, które zachowałyby różnice stylistyczne między znakami chińskimi, japońskimi i koreańskimi, w przeciwieństwie do polityki unikodowania Hanów przez Unicode. Przykładem jednego z nich jest TRON (chociaż nie jest on powszechnie stosowany w Japonii, są użytkownicy, którzy muszą poradzić sobie z historycznym tekstem japońskim i faworyzować go).

Chociaż repertuar składający się z mniej niż 21 000 znaków Han w najwcześniejszej wersji Unicode był w dużej mierze ograniczony do znaków w powszechnym współczesnym użyciu, Unicode zawiera teraz ponad 92 000 znaków Han, a prace trwają nad dodawaniem tysięcy kolejnych znaków historycznych i dialektalnych używanych w Chinach, Japonia, Korea, Tajwan i Wietnam.

Nowoczesna technologia czcionek zapewnia środki do rozwiązania praktycznego problemu konieczności przedstawienia ujednoliconego znaku Han w kategoriach zbioru alternatywnych reprezentacji glifów, w postaci sekwencji wariacji Unicode . Na przykład, zaawansowane tabele typograficzne OpenType pozwalają na wybranie jednej z wielu alternatywnych reprezentacji glifów podczas wykonywania procesu mapowania znaku na glif. W takim przypadku informacje można podać w postaci zwykłego tekstu, aby wskazać, którą alternatywną formę znaku należy wybrać.

Różne znaki cyrylicy pokazane z kursywą i bez

Jeśli różnica w odpowiednich glifach dla dwóch znaków w tym samym skrypcie różni się tylko kursywą, Unicode generalnie je ujednolicił, co widać w porównaniu między znakami rosyjskimi (oznaczonymi jako standard) i serbskimi po prawej stronie, co oznacza, że ​​różnice są wyświetlane za pomocą inteligentnej technologii czcionek lub ręcznej zmiany czcionek.

Mapowanie do starszych zestawów znaków

Unicode został zaprojektowany, aby zapewnić konwersję formatu w obie strony punkt po punkcie kodu do i z dowolnego istniejącego kodowania znaków, dzięki czemu pliki tekstowe w starszych zestawach znaków można przekonwertować na Unicode, a następnie z powrotem i odzyskać ten sam plik, bez stosowania interpretacji zależnej od kontekstu. Oznacza to, że niespójne starsze architektury, takie jak łączenie znaków diakrytycznych i prekomponowanych znaków , istnieją w Unicode, dając więcej niż jedną metodę reprezentowania tekstu. Jest to najbardziej widoczne w trzech różnych formach kodowania dla koreańskiego Hangul . Od wersji 3.0 wszelkie prekomponowane znaki, które mogą być reprezentowane przez kombinację sekwencji już istniejących znaków, nie mogą być już dodawane do standardu w celu zachowania interoperacyjności między oprogramowaniem używającym różnych wersji Unicode.

Mapowania iniekcyjne muszą być zapewnione między znakami w istniejących starszych zestawach znaków i znakami w Unicode, aby ułatwić konwersję do Unicode i umożliwić współdziałanie ze starszym oprogramowaniem. Brak spójności w różnych mapowaniach między wcześniejszymi japońskimi kodowaniami, takimi jak Shift-JIS lub EUC-JP i Unicode, doprowadził do niezgodności konwersji formatu w obie strony , w szczególności mapowania znaku JIS X 0208 '~' (1-33, WAVE DASH) , często używany w starszych danych baz danych, do U+FF5E FULLWIDTH TILDE (w Microsoft Windows ) lub U+301C WAVE DASH (inni dostawcy).

Niektórzy japońscy programiści sprzeciwiali się Unicode, ponieważ wymaga on oddzielenia użycia U+005C \ REVERSE SOLIDUS (odwrotny ukośnik) i U+00A5 ¥ YEN SIGN , który został zmapowany na 0x5C w JIS X 0201, i istnieje wiele starszych kodów z tym użyciem. (To kodowanie zastępuje również tyldę '~' 0x7E makronem '¯', teraz 0xAF.) Separacja tych znaków istnieje w ISO 8859-1 , na długo przed Unicode.

skrypty indyjskie

Skrypty indyjskie, takie jak tamilski i dewanagari, mają przydzielone tylko 128 punktów kodowych, co odpowiada standardowi ISCII . Prawidłowe renderowanie tekstu Unicode Indic wymaga przekształcenia zapisanych znaków porządku logicznego na porządek wizualny i utworzenia ligatur (czyli koniunkcji) z komponentów. Niektórzy lokalni uczeni opowiadali się za przypisaniem punktów kodu Unicode do tych ligatur, co jest sprzeczne z praktyką dla innych systemów pisania, chociaż Unicode zawiera niektóre ligatury arabskie i inne tylko dla celów zgodności wstecznej. Kodowanie nowych ligatur w Unicode nie nastąpi, częściowo dlatego, że zestaw ligatur jest zależny od czcionki, a Unicode to kodowanie niezależne od odmian czcionki. Ten sam rodzaj problemu pojawił się w przypadku pisma tybetańskiego w 2003 r., gdy chińska administracja normalizacyjna zaproponowała zakodowanie 956 wstępnie złożonych sylab tybetańskich, ale zostały one odrzucone przez odpowiedni komitet ISO ( ISO/IEC JTC 1/SC 2 ).

Obsługa alfabetu tajskiego została skrytykowana za kolejność znaków tajskich. Samogłoski เ, แ, โ, ใ, ไ zapisane po lewej stronie poprzedniej spółgłoski są w porządku wizualnym zamiast fonetycznym, w przeciwieństwie do reprezentacji Unicode innych skryptów indyjskich. Ta komplikacja wynika z tego, że Unicode odziedziczył Thai Industrial Standard 620 , który działał w ten sam sposób i był sposobem, w jaki tajski zawsze był pisany na klawiaturach. Ten problem z porządkowaniem nieco komplikuje proces sortowania Unicode, wymagając wyszukiwania tabel w celu zmiany kolejności znaków tajlandzkich do sortowania. Nawet gdyby Unicode przyjął kodowanie zgodnie z kolejnością mówioną, nadal byłoby problematyczne zestawianie słów w kolejności słownikowej. Na przykład słowo แสดง [sa dɛːŋ] „wykonać” zaczyna się od zbitki spółgłosek „สด” (z samogłoską wrodzoną dla spółgłoski „ส”), samogłoska แ-, w kolejności mówionej występuje po ด, ale w słowniku słowo to jest zestawione tak, jak jest napisane, z samogłoską po ส.

Łączenie znaków

Znaki ze znakami diakrytycznymi mogą być ogólnie reprezentowane albo jako pojedynczy prekomponowany znak, albo jako rozłożona sekwencja litery podstawowej plus jeden lub więcej znaków nieoddzielonych. Na przykład ḗ (wstępnie złożone e z makronem i ostrym powyżej) i ḗ (e, po którym następuje łączący makron powyżej i połączenie ostre powyżej) powinny być renderowane identycznie, oba pojawiają się jako e z makronem i ostrym akcentem , ale w praktyce ich wygląd może się różnić w zależności od silnika renderującego i czcionek używanych do wyświetlania znaków. Podobnie, niedociągnięcia , które są potrzebne w latynizacji języka indyjskiego , są często umieszczane niepoprawnie. Znaki Unicode, które mapują się do prekomponowanych glifów, mogą być używane w wielu przypadkach, co pozwala uniknąć problemu, ale gdy nie zakodowano żadnego prekomponowanego znaku, problem może często można rozwiązać za pomocą specjalistycznej czcionki Unicode, takiej jak Charis SIL, która wykorzystuje technologie Graphite , OpenType lub AAT do zaawansowanych funkcji renderowania.

Anomalie

Standard Unicode narzucił reguły mające na celu zagwarantowanie stabilności. W zależności od surowości reguły, zmiana może być zabroniona lub dozwolona. Na przykład „nazwa” nadana punktowi kodowemu nie może i nie zmieni się. Ale właściwość "script" jest bardziej elastyczna, zgodnie z własnymi zasadami Unicode. W wersji 2.0 Unicode zmienił wiele "nazw" punktów kodowych od wersji 1. W tym samym momencie Unicode stwierdził, że od tego czasu przypisana nazwa do punktu kodowego już się nie zmieni. Oznacza to, że jeśli błędy są publikowane, te błędy mogą nie być korygowane, nawet jeśli są one trywialne (jak to miało miejsce w jednym przypadku z jęz BRAKCET dla UCHWYTU w nazwie znak). W 2006 roku po raz pierwszy opublikowano listę anomalii w imionach postaci, a według stanu na czerwiec 2021 było 104 postaci ze zidentyfikowanymi problemami, na przykład:

  • U+2118 SCRIPT CAPITAL P : To jest mała litera. Kapitał to U+1D4AB 𝒫 SKRYPT MATEMATYCZNY KAPITAŁ P .
  • U+034F ͏ COMBINING GRAPHEM JOINER : Nie łączy grafemów.
  • U+A015 ꀕ SYLABA YI WU : To nie jest sylaba Yi, ale znak iteracji Yi.
  • U+FE18 FORMULARZ PREZENTACJI PRAWEJ PIONOWEJ BIAŁY UCHWYT SOCZEWKOWY : nawias jest błędnie napisany.

Błędy pisowni są rozwiązywane przy użyciu nazw aliasów i skrótów Unicode .

Zobacz też

Uwagi

Bibliografia

Dalsza lektura

  • Standard Unicode, wersja 3.0 , Konsorcjum Unicode , Addison-Wesley Longman, Inc., kwiecień 2000. ISBN  0-201-61633-5
  • Unicode Standard, wersja 4.0 , Konsorcjum Unicode , Addison-Wesley Professional, 27 sierpnia 2003. ISBN  0-321-18578-1
  • Standard Unicode, wersja 5.0, wydanie piąte , Konsorcjum Unicode , Addison-Wesley Professional, 27 października 2006. ISBN  0-321-48091-0
  • Julie D. Allen. Standard Unicode, wersja 6.0 , Konsorcjum Unicode , Mountain View, 2011, ISBN  9781936213016 , ( [1] ).
  • Kompletny podręcznik typografii , James Felici, Adobe Press; Wydanie I, 2002. ISBN  0-321-12730-7
  • Unicode: Primer , Tony Graham, książki M&T, 2000. ISBN  0-7645-4625-2 .
  • Unicode Demystified: Praktyczny przewodnik programisty po standardzie kodowania , Richard Gillam, Addison-Wesley Professional; Wydanie I, 2002. ISBN  0-201-70052-2
  • Wyjaśnienie Unicode , Jukka K. Korpela, O'Reilly; Wydanie 1, 2006. ISBN  0-596-10121-X

Zewnętrzne linki