UTF-8(7) Miscellaneous Information Manual UTF-8(7) NAZWA UTF-8 - zgodne z ASCII wielobajtowe kodowanie Unikodowe OPIS Zestaw znakow Unicode 3.0 zajmuje szesnastobitowa przestrzen kodowa. Najprostsze kodowanie Unikodowe (znane jako UCS-2) sklada sie z sekwencji slow szesnastobitowych. Takie lancuchy moga zawierac jako czesc wielu znakow 16-bitowych bajty takie jak ,,\0" lub ,,/", ktore maja specjalne znaczenie w nazwach plikow i innych parametrach funkcji z biblioteki C. Dodatkowo, wiekszosc narzedzi uniksowych spodziewa sie plikow ASCII i nie potrafi bez znacznych modyfikacji czytac slow 16-bitowych jako znakow. Z tych powodow UCS-2 nie jest pozadanym zewnetrznym kodowaniem Unicode w nazwach plikow, plikach tekstowych, zmiennych srodowiskowych itd. ISO/IEC 10646 Universal Character Set (UCS), nadzbior Unicode, zajmuje nawet przestrzen 31-bitowa i oczywiste dlan kodowanie UCS-4 (sekwencja slow 32-bitowych) stwarza te same problemy. Kodowanie UTF-8 dla Unicode i UCS nie ma tych problemow i jest sluszna metoda uzywania zestawu znakow Unicode w systemach operacyjnych wzorowanych na UNIX-ie. WLASCIWOSCI Kodowanie UTF-8 ma nastepujace przydatne wlasciwosci: o UCS znaki od 0x00000000 do 0x0000007f (klasyczne znaki US-ASCII) zakodowane sa po prostu jako bajty 0x00 do 0x7f (zgodnosc z ASCII). Oznacza to, ze pliki i lancuchy ktore zawieraja tylko siedmiobitowe znaki ASCII maja takie samo kodowanie i w ASCII i w UTF-8. o Wszystkie znaki UCS > 0x7f zakodowane sa jako wielobajtowy ciag skladajacy sie tylko z bajtow w zakresie 0x80 do 0xfd, tak wiec zadne bajty ASCII nie moga sie pojawic jako czesc innego znaku i nie wystepuja tam problemy z np. ,,\0" czy ,,/". o Zachowany jest leksykograficzny porzadek sortowania lancuchow w UCS-4. o Za pomoca UTF-8 mozna zakodowac wszystkie z mozliwych 2^31 kodow UCS. o Bajty 0xc0, 0xc1, 0xfe i 0xff nie sa nigdy uzywane w kodowaniu UTF-8. o Pierwszy bajt ciagu wielobajtowego reprezentujacego pojedynczy znak UCS nie-ASCII zawsze zawiera sie w zakresie 0xc2 do 0xfd i wskazuje jak dlugi jest ow ciag. Wszystkie pozostale bajty takiego wielobajtowego ciagu zawieraja sie w zakresie od 0x80 do 0xbf. Pozwala to na latwa resynchronizacje i sprawia, ze kodowanie jest niezalezne od stanu [systemu] oraz odporne na brakujace bajty. o Znaki UCS zakodowane w UTF-8 moga miec dlugosc do szesciu bajtow, jakkolwiek standard Unicode nie definiuje znakow powyzej 0x10ffff, wiec znaki Unicode moga miec maksymalnie cztery bajty w UTF-8. KODOWANIE Do reprezentacji znaku uzywane sa nastepujace ciagi bajtow. Ciag, ktorego nalezy uzyc zalezy 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 zostaja wypelnione bitami numeru kodu znaku w reprezentacji dwojkowej, zaczynajac od bitu najbardziej znaczacego (bit-endian). Moze zostac uzyty tylko najkrotszy mozliwy wielobajtowy ciag, ktora reprezentuje numer kodowy danego znaku. Wartosci kodowe UCS 0xd800-0xdfff (zastepujace UTF-16), jak tez 0xfffe i 0xffff (nie-znaki w UCS) nie powinny wystapic w strumieniach zgodnych z UTF-8. Zgodnie z RFC 3629 nie powinien byc wykorzystywany zaden punkt powyzej U+10FFFF, co ogranicza znaki do czterech bajtow. PRZYKLADY 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 sie") kodowany jest jako: 11100010 10001001 10100000 = 0xe2 0x89 0xa0 Uwagi o stosowaniu Aby wlaczyc obsluge locale UTF-8 uzytkownicy musza wybrac na przyklad export LANG=pl_PL.UTF-8 aby aktywowac obsluge UTF-8 w aplikacjach. Oprogramowanie, ktore musi wiedziec, jakie kodowanie znakow jest uzywane powinno zawsze ustawiac locale, na przyklad za pomoca setlocale(LC_CTYPE, "") a programisci moga wowczas sprawdzac wartosc wyrazenia strcmp(nl_langinfo(CODESET), "UTF-8") == 0 aby okreslic, czy zostalo wybrane locale UTF-8 i czy wszystko: standardowe wprowadzanie i wyprowadzanie danych otwartym tekstem, komunikacja terminalowa, zawartosc plikow tekstowych oraz zmienne srodowiska, jest zakodowane w UTF-8. Programisci przyzwyczajeni do jednobajtowego kodowania takiego, jak US-ASCII lub ISO/IEC 8859 8859 musza wiedziec, ze dwa z dotychczasowych zalozen nie sa spelnione w locale UTF-8. Po pierwsze, pojedynczy bajt niekoniecznie nadal odpowiada pojedynczemu znakowi. Po drugie, poniewaz nowoczesne emulatory terminali w trybie UTF-8 wspieraja rowniez chinskie, japonskie i koreanskie znaki o podwojnej dlugosci, jak tez nie rozdzielone znaki kombinowane, wyprowadzenie pojedynczego znaku niekoniecznie przesuwa kursor o jedna pozycje, jak to mialo miejsce w ASCII. Do zliczania znakow i pozycji kursora nalezy obecnie uzywac funkcji bibliotecznych takich, jak mbsrtowcs(3) i wcswidth(3). Oficjalna sekwencja unikowa przelaczajaca ze schematu kodowania ISO/IEC 2022 (uzywana na przyklad przez terminale VT100) do UTF-8 jest ESC % G ("\x1b%G"). Odpowiadajaca jej sekwencja powrotu z UTF-8 do ISO/IEC 2022 jest ESC % @ ("\x1b%@"). Inne sekwencje ISO/IEC 2022 (takie jak przelaczajace zbiory G0 i G1) nie maja zastosowania w trybie UTF-8. BEZPIECZENSTWO Standardy Unicode i UCS wymagaja, aby przy generowaniu UTF-8 uzywac najkrotszej z mozliwych 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 niz najkrotsze postaci jako swoich danych wejsciowych. Jest to zwiazane z bezpieczenstwem: jesli wprowadzane przez uzytkownika dane sa sprawdzane pod katem mozliwych naruszen bezpieczenstwa, program moze sprawdzac jedynie wersje ASCII wystapien ,,/../", ,,;" lub NUL i przeoczyc, ze jest wiele niezgodnych z ASCII sposobow przedstawienia tych rzeczy w nienajkrotszym kodowaniu UTF-8. STANDARDY ISO/IEC 10646-1:2000, Unicode 3.1, RFC 3629, Plan 9. ZOBACZ TAKZE locale(1), nl_langinfo(3), setlocale(3), charsets(7), unicode(7) TLUMACZENIE Tlumaczenie niniejszej strony podrecznika: Gwidon S. Naskrent , Andrzej Krzysztofowicz i Michal Kulach Niniejsze tlumaczenie jest wolna dokumentacja. Blizsze informacje o warunkach licencji mozna uzyskac zapoznajac sie z GNU General Public License w wersji 3 lub nowszej. Nie przyjmuje sie ZADNEJ ODPOWIEDZIALNOSCI. Bledy w tlumaczeniu strony podrecznika prosimy zglaszac na adres listy dyskusyjnej . Linux man-pages 6.17 8 lutego 2026 r. UTF-8(7)