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

       Pozycje  bitowe  xxx  zostają wypełnione bitami numeru kodu znaku w reprezentacji dwójkowej.  Może zostać
       użyty tylko najkrótszy możliwy wielobajtowy ciąg, która reprezentuje numer kodowy danego znaku.

       Wartości kodowe UCS 0xd800–0xdfff (zastępujące UTF-16), jak też 0xfffe i 0xffff  (nie-znaki  w  UCS)  nie
       powinny wystąpić w strumieniach zgodnych z UTF-8.

   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 4.05 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  man  są:  Gwidon  S.  Naskrent  (PTM)
       <naskrent@hoth.amu.edu.pl>, Andrzej M. Krzysztofowicz (PTM) <ankry@green.mf.pg.gda.pl>  i  Michał  Kułach
       <michal.kulach@gmail.com>.

       Polskie  tłumaczenie  jest  częścią  projektu  manpages-pl;  uwagi,  pomoc,  zgłaszanie błędów na stronie
       http://sourceforge.net/projects/manpages-pl/. Jest zgodne z wersją  4.05 oryginału.

GNU                                                2014-06-13                                           UTF-8(7)