Provided by: manpages-pl_20060617-4_all bug

NAZWA

       UTF-8 - zgodne z ASCII wielobajtowe kodowanie Unikodowe

OPIS

       Zestaw  znakow  Unicode  3.0  zajmuje  szesnastobitow  przestrze kodow.
       Najprostsze  kodowanie  Unikodowe  (znane  jako  UCS-2)  sklada  si   z
       sekwencji  slow  szesnastobitowych.  Takie  lacuchy mog zawiera jako cz
       wielu znakow 16-bitowych bajty  takie  jak  '\0'  lub  '/',  ktore  maj
       specjalne  znaczenie  w  nazwach  plikow i innych parametrach funkcji z
       biblioteki C. Dodatkowo, wikszo narzdzi uniksowych spodziewa si  plikow
       ASCII  i  nie  potrafi bez znacznych modyfikacji czyta slow 16-bitowych
       jako  znakow.  Z  tych  powodow  UCS-2  nie  jest  podanym   zewntrznym
       kodowaniem  Unicode  w  nazwach  plikow,  plikach tekstowych, zmiennych
       rodowiskowych itd.  ISO 10646 Universal Character Set  (UCS),  nadzbior
       Unicode,  zajmuje  nawet  przestrze  31-bitow i oczywiste dla kodowanie
       UCS-4 (sekwencja slow 32-bitowych) stwarza te same problemy.

       Kodowanie UTF-8 dla Unicode i UCS nie ma tych problemow i  jest  sluszn
       metod   uywania   zestawu   znakow  Unicode  w  systemach  operacyjnych
       wzorowanych na UNIX-ie.

W/LACIWOCI

       Kodowanie UTF-8 ma nastpujce przydatne wlaciwoci:

       * 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  lacuchy  ktore  zawieraj  tylko  siedmiobitowe
         znaki ASCII maj takie samo kodowanie i w ASCII i w UTF-8.

       * Wszystkie  znaki  UCS  >  0x7f  zakodowane  s  jako  wielobajtowy cig
         skladajcy si tylko z bajtow w zakresie 0x80 do  0xfd,  tak  wic  adne
         bajty ASCII nie moga si pojawi jako cz innego znaku i nie wystpuj tam
         problemy z np.  '\0' czy '/'.

       * Zachowany jest leksykograficzny porzdek sortowania lacuchow w UCS-4.

       * Za pomoc UTF-8 mona zakodowa wszystkie z moliwych 2^31 kodow UCS.

       * Bajty 0xfe i 0xff nie s nigdy uywane w kodowaniu UTF-8.

       * Pierwszy bajt cigu wielobajtowego reprezentujcego pojedynczy znak UCS
         nie-ASCII  zawsze  zawiera  si w zakresie 0xc0 do 0xfd i wskazuje jak
         dlugi jest ow cig. Wszystkie pozostale bajty  takiego  wielobajtowego
         cigu  zawieraj  si  w  zakresie  od  0x80 do 0xbf. Pozwala to na latw
         resynchronizacj i  sprawia,  e  kodowanie  jest  niezalene  od  stanu
         [systemu] oraz odporne na brakujce bajty.

       * Znaki  UCS  zakodowane  w  UTF-8  mog  mie  dlugo  do  szeciu bajtow,
         jakkolwiek standard Unicode nie definiuje znakow powyej 0x10ffff, wic
         znaki Unicode mog mie maksymalnie cztery bajty w UTF-8.

KODOWANIE

       Do  reprezentacji  znaku  uywane  s nastpujce cigi bajtow. Cig, ktorego
       naley uy zaley 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  wypelnione  bitami  numeru  kodu  znaku  w
       reprezentacji  dwojkowej.   Moe  zosta  uyty  tylko  najkrotszy  moliwy
       wielobajtowy cig, ktora reprezentuje numer kodowy danego znaku.

       Wartoci kodowe UCS 0xd800-0xdfff (zastpujce UTF-16), jak  te  0xfffe  i
       0xffff  (nie-znaki  w UCS) nie powinny wystpi w strumieniach zgodnych z
       UTF-8.

PRZYK/LADY

       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 rowna si") kodowany
       jest jako:

              11100010 10001001 10100000 = 0xe2 0x89 0xa0

UWAGI O STOSOWANIU

       Aby wlczy obslug UTF-8 w  aplikacjach,  uytkownicy  musz  wybra  locale
       UTF-8, na przyklad poprzez

              export LANG=en_GB.UTF-8

       Oprogramowanie,  ktore musi wiedzie, jakie kodowanie znakow jest uywane
       powinno zawsze ustawia locale, na przyklad za pomoc

              setlocale(LC_CTYPE, "")

       a programici mog wowczas sprawdza warto wyraenia

              strcmp(nl_langinfo(CODESET), "UTF-8") == 0

       aby  okreli,  czy  zostalo  wybrane  locale  UTF-8  i   czy   wszystko:
       standardowe  wprowadzanie  i  wyprowadzanie  danych  otwartym  tekstem,
       komunikacja  terminalowa,  zawartosc  plikow  tekstowych  oraz  zmienne
       rodowiska, jest zakodowane w UTF-8.

       Programici  przyzwyczajeni do jednobajtowego kodowania takiego, jak US-
       ASCII lub ISO 8859 musz wiedzie, e dwa z dotychczasowych  zaloe  nie  s
       spelnione  w  locale UTF-8.  Po pierwsze, pojedynczy bajt niekoniecznie
       nadal odpowiada pojedynczemu znakowi.  Po  drugie,  poniewa  nowoczesne
       emulatory  terminali w trybie UTF-8 wspieraj rownie chiskie, japoskie i
       koreaskie znaki o podw'ojnej  d/lugoci,  jak  te  nie  rozdzielone  znaki
       kombinowane,  wyprowadzenie  pojedynczego  znaku niekoniecznie przesuwa
       kursor o jedn pozycj, jak to  mialo  miejsce  w  ASCII.   Do  zliczania
       znakow  i  pozycji  kursora  naley  obecnie uywa funkcji bibliotecznych
       takich, jak mbsrtowcs(3) i wcswidth(3).

       Oficjaln sekwencj unikow przelczajc  ze  schematu  kodowania  ISO  2022
       (uywan  na  przyklad  przez  terminale  VT100)  do  UTF-8  jest ESC % G
       ("\x1b%G"). Odpowiadajc jej sekwencj powrotu z UTF-8 do ISO  2022  jest
       ESC  %  @  ("\x1b%@").  Inne  sekwencje ISO 2022 (takie jak przelczajce
       zbiory G0 i G1) nie maj zastosowania w trybie UTF-8.

       Mona mie  nadziej,  e  w  przewidywalnej  przyszloci  UTF-8  zastpi  na
       wszystkich  poziomach  ASCII i ISO 8859 jako wspolne kodowanie znakow w
       systemach POSIX-owych, doprowadzajc do znacznego wzbogacenia  rodowiska
       obslugi czystego tekstu.

ZABEZPIECZENIA

       Standardy  Unicode  i  UCS  wymagaj,  aby  przy  generowaniu UTF-8 uywa
       najkrotszej z moliwych postaci, np. generowanie dwubajtowej sekwencji o
       pierwszym bajcie 0xc0 nie jest zgodne ze standardem.  Unicode 3.1 dodal
       wymaganie, aby zgodne ze standardem programy nie akceptowaly innych  ni
       najkrotsze  postaci  jako  swoich  danych wejciowych. Jest to zwizane z
       bezpieczestwem: jeli wprowadzane przez uytkownika dane s sprawdzane pod
       ktem  moliwych  narusze  bezpieczestwa,  program  moe  sprawdza jedynie
       wersje ASCII wystpie "/../", ";" lub  NUL  i  przeoczy,  e  jest  wiele
       niezgodnych   z  ASCII  sposobow  przedstawienia  tych  rzeczy  w  nie-
       najkrotszym 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 TAKE

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

INFORMACJE O T/LUMACZENIU

       Powysze tlumaczenie pochodzi z nieistniejcego ju  Projektu  Tlumaczenia
       Manuali  i  moe nie by aktualne. W razie zauwaenia ronic midzy powyszym
       opisem a rzeczywistym zachowaniem  opisywanego  programu  lub  funkcji,
       prosimy o zapoznanie si z oryginaln (angielsk) wersj strony podrcznika.