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.

       Można mieć nadzieję, że w przewidywalnej przyszłości UTF-8 zastąpi na wszystkich poziomach
       ASCII  i  ISO 8859 jako wspólne kodowanie znaków w systemach POSIX-owych, doprowadzając do
       znacznego wzbogacenia środowiska obsługi czystego tekstu.

   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

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

O STRONIE

       Angielska  wersja  tej  strony  pochodzi  z  wydania  3.52  projektu Linux man-pages. Opis
       projektu  oraz  informacje  dotyczące  zgłaszania  błędów  można   znaleźć   pod   adresem
       http://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ą    3.52
       oryginału.