NAZWA

       UTF-8 - zgodne z ASCII wielobajtowe kodowanie Unikodowe

OPIS

       The  Unicode  3.0  character  set  occupies a 16-bit code space.  The most obvious Unicode
       encoding (known as UCS-2)  consists of a sequence  of  16-bit  words.   Such  strings  can
       contain—as  part of many 16-bit characters—bytes such as '\0' or '/', which have a special
       meaning in filenames and other C library function arguments.  In addition, the majority of
       UNIX  tools  expect  ASCII  files  and can't read 16-bit words as characters without major
       modifications.  For these reasons, UCS-2 is not a suitable external encoding of Unicode in
       filenames,  text  files,  environment  variables,  and  so  on.   The  ISO 10646 Universal
       Character Set (UCS), a superset of Unicode, occupies an even larger code space—31 bits—and
       the obvious UCS-4 encoding for it (a sequence of 32-bit words) has the same problems.

       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.

       * All UCS characters greater than 0x7f are encoded as a multibyte sequence consisting only
         of  bytes  in  the  range  0x80  to 0xfd, so no ASCII byte can appear as part of another
         character and there are no problems with, for example, '\0' or '/'.

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

       * All possible 2^31 UCS codes can be encoded using UTF-8.

       * 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)

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⟩.