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