Provided by:
manpages-pl_20060617-4_all 
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.