Unicode

• Niektóre programy (na przykład baza danych Oracle ) wewnętrznie reprezentujące swoje dane Unicode w formacie UTF-16 mają (lub doświadczyły) defektu konwersji do UTF-8: znak między U + 10000 a U + 10FFFF, przechowywany w dwóch 16- słowa bitowe są konwertowane do UTF-8 jako sekwencja dwóch znaków Unicode. Doprowadziło to do „przypadkowego” stworzenia CESU-8 i ma tę zaletę, że ułatwia korzystanie z Unicode na platformach 16-bitowych.
• Znak null Unicode U + 0000 jest zakodowany w UTF-8 jako pojedynczy bajt null 0x00 . Zgodnie ze standardem Unicode ten znak nie ma specjalnego znaczenia; jednak (ze względów historycznych, koncepcyjnych), biblioteki przetwarzające łańcuchy w języku C uważają ten znak kontrolny za koniec łańcucha, co komplikuje implementację niektórych aplikacji . W ramach platformy Java  narodziła się wersja „  (en) Modified UTF-8 ” wykorzystująca „16-bitową” przenośność CESU-8 i dodanie możliwości kodowania U+0000 pod sekwencją 0xC0 0x80 (normalnie zabronione w UTF-8): wymieniając w ten sposób z natywnymi bibliotekami C obsługiwanej platformy, platforma może łatwo zarządzać wszystkimi poprawnymi tekstami Unicode, a także skompilowanymi plikami klas (przenośny alternatywny format, niezależny od endianness i word rozmiar).

UTF-16 jest dobrym kompromisem, gdy pamięć nie jest zbyt mały, gdyż zdecydowana większość znaków Unicode przypisanych do pism współczesnych języków (w tym najczęściej używanych znaków) znajdują się w wielojęzycznej bazy planu, a zatem może być reprezentowany na 16 bitach. Francuska wersja ISO/IEC 10646 nazywa te 16-bitowe słowa „seizets”, ale wersja międzynarodowa opisuje je jako klasyczne 16-bitowe słowa składające się z dwóch bajtów i podlegające zwykłym regułom endyzmu .

Punkty kodowe szesnastu dodatkowych płaszczyzn wymagają przekształcenia na dwóch 16-bitowych słowach:

• odejmij 0x10000 od punktu kodu, pozostawiając 20-bitową liczbę z zakresu od 0x00 do 0xFFFFF;
• 10 najbardziej znaczących bitów (liczba pomiędzy 0x00 a 0x3FF) jest dodawanych do 0xD800 i daje pierwszą jednostkę kodu w wysokiej półstrefie ( 0xD800 do 0xDBFF );
• 10 najmniej znaczących bitów (liczba między 0x00 a 0x3FF) jest dodawanych do 0xDC00 i daje drugą jednostkę kodu w dolnej połowie strefy ( 0xDC00 do 0xDFFF );

Ponieważ większość powszechnie używanych znaków znajduje się w płaszczyźnie podstawowej, kodowanie dodatkowych klipów jest często słabo testowane w oprogramowaniu, co prowadzi do błędów lub problemów z bezpieczeństwem nawet w szeroko rozpowszechnionym oprogramowaniu. Niektóre ramy prawne, takie jak GB 18030 , mogą wymagać wsparcia dodatkowych planów, zawierających w szczególności znaki występujące w nazwach własnych.

Możliwe jest określenie początku sekwencji kodującej z dowolnego punktu w tekście reprezentowanym w UTF-16 przez wykonanie co najwyżej jednego dodatkowego odczytu, tylko jeśli ten punkt kodowy znajduje się w dolnej połowie obszaru. Ta forma jest bardziej ekonomiczna i łatwiejsza do szybkiego przetwarzania niż UTF-8 do reprezentacji tekstów zawierających kilka znaków ASCII (U + 0000 do U + 007F).

Jednak ta transformacja ma dwa niezgodne schematy kodowania, które zależą od kolejności bajtów w 16-bitowej reprezentacji liczb całkowitych. Aby rozwiązać tę niejednoznaczność i umożliwić transmisję między systemami heterogenicznymi, konieczne jest dodanie informacji wskazujących na zastosowany schemat kodowania (UTF-16BE lub UTF-16LE) lub poprzedzenie zakodowanego tekstu reprezentacją punktu kodowego ważne U + FEFF (przypisany do znaku „nierozdzielająca spacja o zerowej szerokości”, znak zarezerwowany teraz do tego wyłącznego użytku jako znacznik porządkowania bajtów), ponieważ punkt kodowy „odwrócony” U + FFFE prawidłowy jest nieznakiem, zabronionym w tekstach zgodnie z Unicode i ISO/IEC 10646 .

Inną wadą UTF-16 jest to, że tekst przekształcony za jego pomocą i przesłany za pomocą jednego z dwóch schematów kodowania zawiera dużą liczbę bajtów, które są puste lub mają wartość sprzeczną z wartościami d. bajtów zarezerwowanych przez niektóre protokoły wymiany.

Jest to w szczególności kodowanie, którego platforma Java używa wewnętrznie, a także Windows dla swoich interfejsów API zgodnych z Unicode (z typem wchar).

UTF-32 jest używany, gdy pamięć nie jest problem i musimy mieć dostęp do znaków bezpośrednio i bez zmian w wielkości ( egipskich hieroglifów ).

Zaletą tej znormalizowanej transformacji jest to, że wszystkie elementy kodu mają ten sam rozmiar. Dlatego nie jest konieczne odczytywanie dodatkowych punktów kodowych, aby określić początek reprezentacji punktu kodowego.

Jednak ten format jest szczególnie nieekonomiczny (w tym w pamięci), ponieważ niepotrzebnie „marnuje” co najmniej jeden bajt (zawsze zero) na znak. Rozmiar tekstu w pamięci ma negatywny wpływ na wydajność, ponieważ wymaga większej liczby odczytów i zapisów na dysku w przypadku pełnej pamięci RAM , a także zmniejsza wydajność pamięci podręcznej procesorów.

W przypadku tekstów pisanych w obecnych językach nowożytnych (poza pewnymi rzadkimi znakami dodatkowej płaszczyzny ideograficznej), a zatem wykorzystujących tylko punkty kodowe podstawowej płaszczyzny wielojęzycznej, ta transformacja podwaja ilość wymaganej pamięci w porównaniu z UTF-16.

Podobnie jak UTF-16, UTF-32 ma kilka schematów kodowania w zależności od kolejności bajtów tworzących liczbę całkowitą większą niż 8 bitów (dwa schematy kodowania UTF-32 są standaryzowane, UTF-32BE i UTF-32LE). Dlatego konieczne jest również określenie tego schematu kodowania lub określenie go przez poprzedzenie tekstu przedstawieniem w UTF-32 punktu kodowego U + FEFF. Podobnie jak UTF-16, obecność bajtów zerowych w standardowych schematach kodowania UTF-32 sprawia, że ​​jest niekompatybilny z wieloma protokołami wymiany między systemami heterogenicznymi.

Również ten format jest używany najczęściej tylko bardzo lokalnie do pewnego przetwarzania jako forma pośrednia, która jest łatwiejsza w obsłudze i często preferujemy transformację UTF-16, która jest często bardziej wydajna do przetwarzania i przechowywania dużych ilości tekstów, konwersji między oba są bardzo proste do wykonania i bardzo tanie pod względem złożoności przetwarzania.

W rzeczywistości wiele bibliotek edytorów tekstu jest pisanych tylko w UTF-16 i jest bardziej wydajnych niż UTF-32, nawet jeśli teksty zawierają znaki z dodatkowych płaszczyzn (ponieważ ten przypadek liczby pozostaje rzadki w zdecydowanej większości przypadków).

Należy jednak pamiętać, że transformacja do UTF-32 wykorzystuje 32-bitowe punkty kodowe, z których wiele może nie reprezentować żadnego ważnego punktu kodowego (wartości poza dwoma przedziałami reprezentującymi ważne punkty kodowe U+0000 do U+D7FF i U+ E000 do U + 10FFFF), w związku z tym brak ważnego lub zastrzeżonego znaku (żadne informacje w nim zawarte nie mogą zatem być tekstem w sensie Unicode). Przesyłanie tekstów przy użyciu tych nieprawidłowych wartości kodu w jednym ze znormalizowanych schematów kodowania UTF-32 jest zabronione dla każdego systemu zgodnego z Unicode (zamiast tego konieczne jest użycie punktów kodowych do użytku prywatnego), ponieważ będzie to niemożliwe do reprezentowania ich w innej transformacji UTF, z którą trzy standardowe kody UTF są zgodne bijective.

chińska norma GB 18030

Jest to transformacja Unicode, która nie jest definiowana przez Konsorcjum Unicode, ale przez administrację standardów w Chinach, gdzie jego obsługa jest obowiązkowa w aplikacjach. Historycznie był to zakodowany zestaw znaków, który został rozszerzony o obsługę całego repertuaru UCS przez transformację algorytmiczną uzupełniającą dużą tabelę korespondencji między kodami.

Czcionki Unicode

Twierdzenie, że Unicode koduje znaki, jest równoznaczne z twierdzeniem, że przypisuje liczbę abstrakcyjnym symbolom, zgodnie z zasadą kodowania logicznego. Z drugiej strony Unicode nie koduje graficznych reprezentacji znaków, glifów . Nie ma zatem bijekcji między przedstawieniem znaku a jego liczbą, ponieważ wszystkie graficzne odmiany stylu są zunifikowane.

Ponadto, w przeciwieństwie do klasycznej czcionki ASCII lub Latin-1 , wybór glifu przez kod nie jest unikalny i często jest kontekstowy, a także może wyświetlać ten sam glif dla różnych kodów. Tak więc francuski znak "é" można opisać na dwa sposoby: albo bezpośrednio przy użyciu liczby odpowiadającej "é", albo po liczbie "e" za pomocą ostrego akcentu bez polowania. Niezależnie od wybranej opcji zostanie wyświetlony ten sam glif. O pierwszym znaku powiemy, że jest prekomponowany, o drugim, że jest to kompozycja (dwa znaki tworzą jeden glif złożony z obu). Jest to dozwolone, a nawet wysoce zalecane, ponieważ różne formy kodowania są klasyfikowane przez Unicode jako „kanonicznie równoważne”, co oznacza, że ​​dwie równoważne formy kodowania powinny być traktowane identycznie.

W tym przypadku występuje wiele znaków złożonych i można je zakodować na dwa sposoby (lub więcej, niektóre znaki złożone można rozłożyć na więcej niż jeden sposób, zwłaszcza gdy mają kilka znaków diakrytycznych). Najczęściej znak prekomponowany jest preferowany do zakodowania tekstu, jeśli taki istnieje (tak jest na przykład w przypadku politonicznej greki , która zakodowana w rozkładzie może nie być zadowalająca graficznie: w zależności od czcionek znaki różne składniki glifu są czasami źle ułożone i trudne do odczytania). Jednak nie wszystkie znaki złożone mają unikalny punkt kodowy dla ich wstępnie złożonej formy.

Podobnie niektóre systemy pisma, takie jak Devânagarî , perski lub arabski , wymagają złożonego traktowania ligatur  : grafemy zmieniają kształt w zależności od ich położenia lub sąsiadów (patrz Wariant kontekstowy i Litera łączona ). Wybranie prawidłowego glifu wymaga przetwarzania w celu określenia, który kształt kontekstowy wybrać w czcionce, mimo że wszystkie kształty kontekstowe są zakodowane identycznie w Unicode.

Z tych powodów należy ostrożnie obchodzić się z czcionką Unicode. Na przykład czcionka ze wszystkimi istniejącymi glifami nie jest wystarczająca. Niezbędne jest również, aby system wyświetlania ( silnik renderujący ) posiadał mechanizmy zdolne do przetwarzania ligatur , wariantów kontekstowych i formularzy łączonych specyficznych dla określonych języków. I odwrotnie, czcionka, która reprezentuje tylko część znaków, ale wie, jak je poprawnie wyświetlić, lepiej zasługuje na tytuł „czcionka Unicode”. Wreszcie pewne ograniczenia techniczne formatów czcionek mogą uniemożliwić im obsługę całego katalogu. W praktyce nie da się (w 2009 roku) znaleźć jednej czcionki obsługującej cały katalog.

Czcionka znakowa Unicode jest zatem tylko czcionką umożliwiającą bezpośrednie wyświetlanie tekstu zakodowanego we wszystkich formach autoryzowanych przez Unicode i umożliwiającą obsługę spójnego podzbioru dostosowanego do jednego lub więcej języków w celu obsługi jednego lub więcej skryptów. Żaden krój pisma Unicode nie może „działać” samodzielnie, a pełna obsługa pisania wymaga obsługi tych elementów w silniku renderującym , zdolnym do wykrywania równoważnych formularzy kodowania, wyszukiwania formularzy kontekstowych w tekście i wybierania różnych glifów czcionki zakodowanej za pomocą Unicode, korzystając w razie potrzeby z tabel korespondencji zawartych w samej czcionce.

Szczegóły techniczne

Biblioteki oprogramowania

ICU wieloplatformowa biblioteka oprogramowanie pozwala na manipulowanie danych zakodowanych z Unicode. Obsługa Unicode specyficzna dla platformy jest również zintegrowana z nowoczesnymi systemami ( Java , Microsoft Windows , GNU/Linux , standardowe biblioteki C/C++ , Python itp.).

Typy używane do przechowywania zmiennych Unicode to:

1. W UTF-8
2. Należy jednak pamiętać, że wchar_tjęzyk C nie zawsze umożliwia kodowanie wszystkich znaków Unicode, ponieważ standard tego języka nie zapewnia wystarczającej liczby minimalnej dla tego standardowego typu. Jednak wiele kompilatorów języka definiuje wchar_t32 bity (lub nawet 64 bity w środowiskach obsługujących standardowe 64-bitowe liczby całkowite), co jest wystarczające do przechowywania dowolnego punktu standardowego kodu Unicode. Ale inne kompilatory reprezentują wchar_t16 bitów (w szczególności w systemie Windows w środowisku 16 lub 32 bitów), nawet tylko 8 bitów (w szczególności w środowiskach osadzonych, które nie mają ogólnego systemu operacyjnego), ponieważ wchar_tmogą używać tej samej reprezentacji, co typ, charktóry ma minimum 8 bitów.
3. Podobnie jak C i C++, język Java posiada typ jednostki pozwalający na zakodowanie 16 bitów, ale nie pozwalający na zakodowanie pojedynczego punktu kodowego o dowolnej wartości (typ natywny charto tylko dodatnia 16-bitowa liczba całkowita) . Aby manipulować standardowymi znakami z pierwszego planu, musisz użyć pary punktów kodowych, z których każdy zawiera wartość równą dwóm punktom kodowym zdefiniowanym przez formularz UTF-16. Również typy obiektów Stringlub char[2]są najbardziej odpowiednie do reprezentowania znaku Unicode. Od wersji Java 1.4.1 biblioteka standardowa zapewnia pełną obsługę Unicode dzięki typowi natywnemu int(który jest liczbą całkowitą zdefiniowaną na 32 bitach) oraz statycznym metodom klasy standardowej Character(jednakże obiekt tego typu Characternie pozwala, podobnie jak typ natywny char, aby przechowywać dowolny punkt kodowy).
4. JavaScript ma różne niestandaryzowane implementacje, niektóre starsze obsługujące nie więcej niż 16 bitów na znak, a czasami tylko 8 bitów. Jednak standard ECMAScript tego języka definiuje klasę użytkową Characterna 32 bitach (w rzeczywistości opartą na klasie Number), która musi obsługiwać wszystkie punkty kodowe 17 znormalizowanych planów, podczas gdy ciągi znaków używają znaków zakodowanych obowiązkowo na 16 bitach (ale bez ograniczenie wzmacniające parowanie jednostek kodu UTF-16, ciągi typu ECMAScript Stringnie są ograniczone do jedynego kodowania UTF-16, ale są wektorami stałych całkowitych zakodowanych na 16 bitach bez ograniczeń, w celu zapewnienia (współpracy z Javą i innymi języki, które również nie wymuszają ograniczeń zgodności UTF-16 w swoich natywnych typach danych). Te dwa języki nie obsługują jawnego wpisywania zmiennych, przy czym typ jest definiowany dynamicznie przez przypisane im wartości (możliwych jest również kilka reprezentacji wewnętrznych, których różnice są zwykle niewidoczne dla programisty).

Unicode wciąż jednak cierpi z powodu słabej obsługi wyrażeń regularnych przez niektóre programy, chociaż biblioteki takie jak ICU i Java mogą je obsługiwać. Takie wsparcie nie zostało jeszcze ustandaryzowane dla ECMAScript i jest zapewniane jedynie za pomocą bibliotek stworzonych z tym językiem lub interfejsów dla interoperacyjności z innymi systemami (zwłaszcza z CORBA , COM ) lub językami (zwłaszcza C++ i Java ).

Partycjonowanie

Aktualne partycjonowanie można znaleźć na oficjalnej stronie Unicode. Jednak biorąc pod uwagę ważną rolę Unicode w dzisiejszych czasach ( ISO/IEC 10646 ), główne bloki znaków zostaną tutaj opisane. Francuskie nazwy są oficjalnymi nazwami ISO/IEC 10646 , międzynarodowego dwujęzycznego standardu, który używa tych samych znaków co Unicode. Są tak oficjalne, jak nazwy angielskie.

Stary standard Unicode 1.0 jest przestarzały i niekompatybilny z ISO/IEC 10646 i Unicode 1.1 oraz wszystkimi jego późniejszymi wersjami; główna niezgodność dotyczy bloków znaków Hangul używanych do pisania języka koreańskiego, które zmieniły położenie i których stare punkty kodowe zostały od tego czasu przypisane do innych bloków. Poniższa tabela jest zgodna z ISO/IEC 10646 (wszystkie wersje) i Unicode 1.1 (lub nowszym).

NB Przypadek nazw bloków nie jest normatywny. „Basic Latin” jest zatem odpowiednikiem „BASIC LATIN”.

W poniższych tabelach dowolna nazwa bloku z uwagą odnoszącą się do oficjalnego pliku PDF w formacie Unicode oznacza, że ​​strona Wikipedii powiązana z tym blokiem nie istnieje lub jest nieprawidłowa.