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