Ubuntu Manpage: UTF-8 - zgodne z ASCII wielobajtowe kodowanie Unikodowe

NAZWA

       UTF-8 - zgodne z ASCII wielobajtowe kodowanie Unikodowe

OPIS

Zestaw znaków Unicode 3.0 zajmuje szesnastobitową przestrzeń kodową. Najprostsze kodowanie Unikodowe
(znane jako UCS-2) składa się z sekwencji słów szesnastobitowych. Takie łańcuchy mogą zawierać jako
część wielu znaków 16-bitowych bajty takie jak '\0' lub '/', które mają specjalne znaczenie w nazwach
plików i innych parametrach funkcji z biblioteki C. Dodatkowo, większość narzędzi uniksowych spodziewa
się plików ASCII i nie potrafi bez znacznych modyfikacji czytać słów 16-bitowych jako znaków. Z tych
powodów UCS-2 nie jest pożądanym zewnętrznym kodowaniem Unicode w nazwach plików, plikach tekstowych,
zmiennych środowiskowych itd. ISO 10646 Universal Character Set (UCS), nadzbiór Unicode, zajmuje nawet
przestrzeń 31-bitową i oczywiste dlań kodowanie UCS-4 (sekwencja słów 32-bitowych) stwarza te same
problemy.

Kodowanie UTF-8 dla Unicode i UCS nie ma tych problemów i jest słuszną metodą używania zestawu znaków
Unicode w systemach operacyjnych wzorowanych na UNIX-ie.

WŁAŚCIWOŚCI
Kodowanie UTF-8 ma następujące przydatne właściwości:

* UCS znaki od 0x00000000 do 0x0000007f (klasyczne znaki US-ASCII) zakodowane są po prostu jako bajty
0x00 do 0x7f (zgodność z ASCII). Oznacza to, że pliki i łańcuchy które zawierają tylko siedmiobitowe
znaki ASCII mają takie samo kodowanie i w ASCII i w UTF-8.

* Wszystkie znaki UCS > 0x7f zakodowane są jako wielobajtowy ciąg składający się tylko z bajtów w
zakresie 0x80 do 0xfd, tak więc żadne bajty ASCII nie mogą się pojawić jako część innego znaku i nie
występują tam problemy z np. '\0' czy '/'.

* Zachowany jest leksykograficzny porządek sortowania łańcuchów w UCS-4.

* Za pomocą UTF-8 można zakodować wszystkie z możliwych 2^31 kodów UCS.

* Bajty 0xc0, 0xc1, 0xfe i 0xff nie są nigdy używane w kodowaniu UTF-8.

* Pierwszy bajt ciągu wielobajtowego reprezentującego pojedynczy znak UCS nie-ASCII zawsze zawiera się w
zakresie 0xc2 do 0xfd i wskazuje jak długi jest ów ciąg. Wszystkie pozostałe bajty takiego
wielobajtowego ciągu zawierają się w zakresie od 0x80 do 0xbf. Pozwala to na łatwą resynchronizację i
sprawia, że kodowanie jest niezależne od stanu [systemu] oraz odporne na brakujące bajty.

* Znaki UCS zakodowane w UTF-8 mogą mieć długość do sześciu bajtów, jakkolwiek standard Unicode nie
definiuje znaków powyżej 0x10ffff, więc znaki Unicode mogą mieć maksymalnie cztery bajty w UTF-8.

KODOWANIE
Do reprezentacji znaku używane są następujące ciągi bajtów. Ciąg, którego należy użyć zależy od numeru
kodu UCS znaku:

0x00000000 - 0x0000007F:
0xxxxxxx

0x00000080 - 0x000007FF:
110xxxxx 10xxxxxx

0x00000800 - 0x0000FFFF:
1110xxxx 10xxxxxx 10xxxxxx

0x00010000 - 0x001FFFFF:
11110xxx 10xxxxxx 10xxxxxx 10xxxxxx

0x00200000 - 0x03FFFFFF:
111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

0x04000000 - 0x7FFFFFFF:
1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx

The xxx bit positions are filled with the bits of the character code number in binary representation,
most significant bit first (big-endian). Only the shortest possible multibyte sequence which can
represent the code number of the character can be used.

The UCS code values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0xffff (UCS noncharacters)
should not appear in conforming UTF-8 streams. According to RFC 3629 no point above U+10FFFF should be
used, which limits characters to four bytes.

PRZYKŁADY
Znak Unicode 0xa9 = 1010 1001 (znak copyright) kodowany jest w UTF-8 jako

11000010 10101001 = 0xc2 0xa9

a znak 0x2260 = 0010 0010 0110 0000 (symbol "nie równa się") kodowany jest jako:

11100010 10001001 10100000 = 0xe2 0x89 0xa0

Uwagi o stosowaniu
Aby włączyć obsługę locale UTF-8 użytkownicy muszą wybrać na przykład

export LANG=pl_PL.UTF-8

aby aktywować obsługę UTF-8 w aplikacjach.

Oprogramowanie, które musi wiedzieć, jakie kodowanie znaków jest używane powinno zawsze ustawiać locale,
na przykład za pomocą

setlocale(LC_CTYPE, "")

a programiści mogą wówczas sprawdzać wartość wyrażenia

strcmp(nl_langinfo(CODESET), "UTF-8") == 0

aby określić, czy zostało wybrane locale UTF-8 i czy wszystko: standardowe wprowadzanie i wyprowadzanie
danych otwartym tekstem, komunikacja terminalowa, zawartość plików tekstowych oraz zmienne środowiska,
jest zakodowane w UTF-8.

Programiści przyzwyczajeni do jednobajtowego kodowania takiego, jak US-ASCII lub ISO 8859 muszą wiedzieć,
że dwa z dotychczasowych założeń nie są spełnione w locale UTF-8. Po pierwsze, pojedynczy bajt
niekoniecznie nadal odpowiada pojedynczemu znakowi. Po drugie, ponieważ nowoczesne emulatory terminali w
trybie UTF-8 wspierają również chińskie, japońskie i koreańskie znaki o podwójnej długości, jak też nie
rozdzielone znaki kombinowane, wyprowadzenie pojedynczego znaku niekoniecznie przesuwa kursor o jedną
pozycję, jak to miało miejsce w ASCII. Do zliczania znaków i pozycji kursora należy obecnie używać
funkcji bibliotecznych takich, jak mbsrtowcs(3) i wcswidth(3).

Oficjalną sekwencją unikową przełączającą ze schematu kodowania ISO 2022 (używaną na przykład przez
terminale VT100) do UTF-8 jest ESC % G ("\x1b%G"). Odpowiadającą jej sekwencją powrotu z UTF-8 do ISO
2022 jest ESC % @ ("\x1b%@"). Inne sekwencje ISO 2022 (takie jak przełączające zbiory G0 i G1) nie mają
zastosowania w trybie UTF-8.

BEZPIECZEŃSTWO
Standardy Unicode i UCS wymagają, aby przy generowaniu UTF-8 używać najkrótszej z możliwych postaci, np.
generowanie dwubajtowej sekwencji o pierwszym bajcie 0xc0 nie jest zgodne ze standardem. Unicode 3.1
dodał wymaganie, aby zgodne ze standardem programy nie akceptowały innych niż najkrótsze postaci jako
swoich danych wejściowych. Jest to związane z bezpieczeństwem: jeśli wprowadzane przez użytkownika dane
są sprawdzane pod kątem możliwych naruszeń bezpieczeństwa, program może sprawdzać jedynie wersje ASCII
wystąpień "/../", ";" lub NUL i przeoczyć, że jest wiele niezgodnych z ASCII sposobów przedstawienia tych
rzeczy w nienajkrótszym kodowaniu UTF-8.

STANDARDY
ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9.

ZOBACZ TAKŻE

       locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

O STRONIE

       Angielska  wersja  tej strony pochodzi z wydania 5.10 projektu Linux man-pages. Opis projektu, informacje
       dotyczące   zgłaszania   błędów   oraz   najnowszą   wersję   oryginału   można   znaleźć   pod   adresem
       https://www.kernel.org/doc/man-pages/.

T◈UMACZENIE

       Autorami    polskiego    tłumaczenia    niniejszej    strony   podręcznika   są:   Gwidon   S.   Naskrent
       <naskrent@hoth.amu.edu.pl>,   Andrzej   Krzysztofowicz   <ankry@green.mf.pg.gda.pl>   i   Michał   Kułach
       <michal.kulach@gmail.com>

       Niniejsze  tłumaczenie  jest  wolną  dokumentacją.  Bliższe informacje o warunkach licencji można uzyskać
       zapoznając  się  z  GNU General Public License w wersji 3  lub  nowszej.   Nie   przyjmuje   się   ŻADNEJ
       ODPOWIEDZIALNOŚCI.

       Błędy  w  tłumaczeniu  strony  podręcznika  prosimy  zgłaszać  na  adres  listy  dyskusyjnej manpages-pl-
       list@lists.sourceforge.net.

GNU                                              6 marca 2019 r.                                        UTF-8(7)