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

       to  determine whether a UTF-8 locale has been selected and whether therefore all plaintext
       standard input and output, terminal communication, plaintext file content, filenames,  and
       environment variables are encoded in 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.13  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
       ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩  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⟩.