Linux.pl
Opcje wyszukiwania podręcznika man:
Lista stron man zaczynających się od znaku:
A   B   C   D   E   F   G   H   I   J   K   L   M   N   O   P   Q   R   S   T   U   V   W   X   Y   Z   ALPHA   NUM   OTHER   ALL
UTF-8(7)                Podręcznik programisty Linuksa                UTF-8(7)

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  sek-
       wencji  słów szesnastobitowych. Takie łańcuchy mogą zawierać jako część
       wielu znaków 16-bitowych bajty takie jak '\0' lub '/', które mają spec-
       jalne  znaczenie  w  nazwach plików i innych parametrach funkcji z bib-
       lioteki 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 moga 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 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 0xc0 do 0xfd  i  wskazuje
         jak  długi  jest ów ciąg. Wszystkie pozostałe bajty takiego wielobaj-
         towego 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ę  UTF-8  w  aplikacjach,  użytkownicy muszą wybrać
       locale UTF-8, na przykład poprzez

              export LANG=en_GB.UTF-8

       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: standar-
       dowe wprowadzanie i wyprowadzanie danych otwartym tekstem,  komunikacja
       terminalowa,  zawartosc 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.

       Można  mieć  nadzieję, że w przewidywalnej przyszłości UTF-8 zastąpi na
       wszystkich poziomach ASCII i ISO 8859 jako wspólne kodowanie  znaków  w
       systemach   POSIX-owych,   doprowadzając   do   znacznego   wzbogacenia
       środowiska obsługi czystego tekstu.

ZABEZPIECZENIA
       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 nie-najkrótszym 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 TAKŻE
       nl_langinfo(3), setlocale(3), charsets(7), unicode(7)

GNU                               2001-05-11                          UTF-8(7)

Time taken: 0.00073 seconds


Created with the man page lookup class by Andrew Collington, php@amnuts.com