sourCEntral - mobile manpages

pdf

UTF−8

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 mogą 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 0xc0, 0xc1, 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 0xc2 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ę locale UTF−8 użytkownicy muszą wybrać na przykład

export LANG=pl_PL.UTF−8

aby aktywować obsługę UTF−8 w aplikacjach.

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, zawartość 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.

BEZPIECZEŃSTWO
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 nienajkrótszym kodowaniu UTF−8.

STANDARDY
ISO/IEC 10646−1:2000, Unicode 3.1, RFC 3629, Plan 9.

ZOBACZ TAKŻE

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

O STRONIE

Angielska wersja tej strony pochodzi z wydania 4.05 projektu Linux man−pages. Opis projektu, informacje dotyczące zgłaszania błędów, oraz najnowszą wersję oryginału można znaleźć pod adresem https://www.kernel.org/doc/man−pages/.

TŁUMACZENIE

Autorami polskiego tłumaczenia niniejszej strony podręcznika man są: Gwidon S. Naskrent (PTM) <naskrent AT hoth DOT amu DOT edu DOT pl>, Andrzej M. Krzysztofowicz (PTM) <ankry AT green DOT mf DOT pg DOT gda DOT pl> i Michał Kułach <michal DOT kulach AT gmail DOT com>.

Polskie tłumaczenie jest częścią projektu manpages-pl; uwagi, pomoc, zgłaszanie błędów na stronie http://sourceforge.net/projects/manpages-pl/. Jest zgodne z wersją 4.05 oryginału.

pdf