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¶

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

The xxx bit positions are filled with the bits of the character code number in binary representation, most significant bit first (big-endian). Only the shortest possible multibyte sequence which can represent the code number of the character can be used.

The UCS code values 0xd800–0xdfff (UTF-16 surrogates) as well as 0xfffe and 0xffff (UCS noncharacters) should not appear in conforming UTF-8 streams. According to RFC 3629 no point above U+10FFFF should be used, which limits characters to four bytes.

PRZYKŁADY¶

a znak 0x2260 = 0010 0010 0110 0000 (symbol "nie równa się") kodowany jest jako:

Uwagi o stosowaniu¶

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ą

a programiści mogą wówczas sprawdzać wartość wyrażenia

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¶