Provided by: manpages-pl_20060617-4_all bug

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  moga  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 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 0xc0 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ę  UTF-8  w  aplikacjach,  użytkownicy  muszą  wybrać locale UTF-8, na
       przykład poprzez

              export LANG=en_GB.UTF-8

       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,   zawartosc   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.

ZABEZPIECZENIA

       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 nie-najkrótszym kodowaniu UTF-8.

STANDARDY

       ISO/IEC 10646-1:2000, Unicode 3.1, RFC 2279, Plan 9.

AUTOR

       Markus Kuhn <mgk25@cl.cam.ac.uk>

ZOBACZ TAKŻE

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

INFORMACJE O TŁUMACZENIU

       Powyższe tłumaczenie pochodzi z nieistniejącego już Projektu Tłumaczenia  Manuali  i  może
       nie  być  aktualne.  W  razie  zauważenia  różnic  między  powyższym opisem a rzeczywistym
       zachowaniem opisywanego programu lub  funkcji,  prosimy  o  zapoznanie  się  z  oryginalną
       (angielską) wersją strony podręcznika.