.\" -*- coding: UTF-8 -*- .\" Copyright (C) Markus Kuhn, 1996, 2001 .\" .\" SPDX-License-Identifier: GPL-2.0-or-later .\" .\" 1995-11-26 Markus Kuhn .\" First version written .\" 2001-05-11 Markus Kuhn .\" Update .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH UTF\-8 7 "15 czerwca 2024 r." "Linux man\-pages 6.9.1" .SH NAZWA UTF\-8 \- zgodne z ASCII wielobajtowe kodowanie Unikodowe .SH OPIS Zestaw znaków \fBUnicode 3.0\fP zajmuje szesnastobitową przestrzeń kodową. Najprostsze kodowanie Unikodowe (znane jako \fBUCS\-2\fP) składa się z sekwencji słów szesnastobitowych. Takie łańcuchy mogą zawierać jako część wielu znaków 16\-bitowych bajty takie jak \[Bq]\[rs]0\[rq] lub \[Bq]/\[rq], 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 \fBUCS\-2\fP nie jest pożądanym zewnętrznym kodowaniem \fBUnicode\fP w nazwach plików, plikach tekstowych, zmiennych środowiskowych itd. \fBISO/IEC 10646 Universal Character Set (UCS)\fP, nadzbiór Unicode, zajmuje nawet przestrzeń 31\-bitową i oczywiste dlań kodowanie \fBUCS\-4\fP (sekwencja słów 32\-bitowych) stwarza te same problemy. .P Kodowanie \fBUTF\-8\fP dla \fBUnicode\fP i \fBUCS\fP nie ma tych problemów i jest słuszną metodą używania zestawu znaków \fBUnicode\fP w systemach operacyjnych wzorowanych na UNIX\-ie. .SS WŁAŚCIWOŚCI Kodowanie \fBUTF\-8\fP ma następujące przydatne właściwości: .IP \[bu] 3 \fBUCS\fP znaki od 0x00000000 do 0x0000007f (klasyczne znaki \fBUS\-ASCII\fP) 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 \fBASCII\fP i w \fBUTF\-8\fP. .IP \[bu] Wszystkie znaki \fBUCS\fP > 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. \[Bq]\[rs]0\[rq] czy \[Bq]/\[rq]. .IP \[bu] Zachowany jest leksykograficzny porządek sortowania łańcuchów w \fBUCS\-4\fP. .IP \[bu] Za pomocą \fBUTF\-8\fP można zakodować wszystkie z możliwych 2\[ha]31 kodów UCS. .IP \[bu] Bajty 0xc0, 0xc1, 0xfe i 0xff nie są nigdy używane w kodowaniu \fBUTF\-8\fP. .IP \[bu] Pierwszy bajt ciągu wielobajtowego reprezentującego pojedynczy znak \fBUCS\fP 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. .IP \[bu] Znaki \fBUCS\fP zakodowane w \fBUTF\-8\fP mogą mieć długość do sześciu bajtów, jakkolwiek standard \fBUnicode\fP nie definiuje znaków powyżej 0x10ffff, więc znaki Unicode mogą mieć maksymalnie cztery bajty w \fBUTF\-8\fP. .SS 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: .TP 0x00000000 \- 0x0000007F: 0\fIxxxxxxx\fP .TP 0x00000080 \- 0x000007FF: 110\fIxxxxx\fP 10\fIxxxxxx\fP .TP 0x00000800 \- 0x0000FFFF: 1110\fIxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP .TP 0x00010000 \- 0x001FFFFF: 11110\fIxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP .TP 0x00200000 \- 0x03FFFFFF: 111110\fIxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP .TP 0x04000000 \- 0x7FFFFFFF: 1111110\fIx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP 10\fIxxxxxx\fP .P Pozycje bitowe \fIxxx\fP zostają wypełnione bitami numeru kodu znaku w reprezentacji dwójkowej, zaczynając od bitu najbardziej znaczącego (bit\-endian). Może zostać użyty tylko najkrótszy możliwy wielobajtowy ciąg, która reprezentuje numer kodowy danego znaku. .P Wartości kodowe \fBUCS\fP 0xd800\[en]0xdfff (zastępujące UTF\-16), jak też 0xfffe i 0xffff (nie\-znaki w UCS) nie powinny wystąpić w strumieniach zgodnych z \fBUTF\-8\fP. Zgodnie z RFC 3629 nie powinien być wykorzystywany żaden punkt powyżej U+10FFFF, co ogranicza znaki do czterech bajtów. .SS PRZYKŁADY Znak \fBUnicode\fP 0xa9 = 1010 1001 (znak copyright) kodowany jest w UTF\-8 jako .P .RS 11000010 10101001 = 0xc2 0xa9 .RE .P a znak 0x2260 = 0010 0010 0110 0000 (symbol \[Bq]nie równa się\[rq]) kodowany jest jako: .P .RS 11100010 10001001 10100000 = 0xe2 0x89 0xa0 .RE .SS "Uwagi o stosowaniu" Aby włączyć obsługę locale \fBUTF\-8\fP użytkownicy muszą wybrać na przykład .P .RS export LANG=pl_PL.UTF\-8 .RE .P aby aktywować obsługę \fBUTF\-8\fP w aplikacjach. .P Oprogramowanie, które musi wiedzieć, jakie kodowanie znaków jest używane powinno zawsze ustawiać locale, na przykład za pomocą .P .RS setlocale(LC_CTYPE, "") .RE .P a programiści mogą wówczas sprawdzać wartość wyrażenia .P .RS strcmp(nl_langinfo(CODESET), "UTF\-8") == 0 .RE .P aby określić, czy zostało wybrane locale \fBUTF\-8\fP i czy wszystko: standardowe wprowadzanie i wyprowadzanie danych otwartym tekstem, komunikacja terminalowa, zawartość plików tekstowych oraz zmienne środowiska, jest zakodowane w \fBUTF\-8\fP. .P Programiści przyzwyczajeni do jednobajtowego kodowania takiego, jak \fBUS\-ASCII\fP lub \fBISO/IEC\ 8859 8859\fP muszą wiedzieć, że dwa z dotychczasowych założeń nie są spełnione w locale \fBUTF\-8\fP. Po pierwsze, pojedynczy bajt niekoniecznie nadal odpowiada pojedynczemu znakowi. Po drugie, ponieważ nowoczesne emulatory terminali w trybie \fBUTF\-8\fP wspierają również chińskie, japońskie i koreańskie \fBznaki o podwójnej długości\fP, jak też nie rozdzielone \fBznaki kombinowane\fP, wyprowadzenie pojedynczego znaku niekoniecznie przesuwa kursor o jedną pozycję, jak to miało miejsce w \fBASCII\fP. Do zliczania znaków i pozycji kursora należy obecnie używać funkcji bibliotecznych takich, jak \fBmbsrtowcs\fP(3) i \fBwcswidth\fP(3). .P Oficjalną sekwencją unikową przełączającą ze schematu kodowania \fBISO/IEC\ 2022\fP (używaną na przykład przez terminale VT100) do \fBUTF\-8\fP jest ESC % G ("\[rs]x1b%G"). Odpowiadającą jej sekwencją powrotu z \fBUTF\-8\fP do ISO/IEC\ 2022 jest ESC % @ ("\[rs]x1b%@"). Inne sekwencje ISO/IEC\ 2022 (takie jak przełączające zbiory G0 i G1) nie mają zastosowania w trybie UTF\-8. .SS BEZPIECZEŃSTWO Standardy \fBUnicode\fP i \fBUCS\fP wymagają, aby przy generowaniu \fBUTF\-8\fP używać najkrótszej z możliwych postaci, np. generowanie dwubajtowej sekwencji o pierwszym bajcie 0xc0 nie jest zgodne ze standardem. \fBUnicode 3.1\fP 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 \fBASCII\fP wystąpień \[Bq]/../\[rq], \[Bq];\[rq] lub NUL i przeoczyć, że jest wiele niezgodnych z \fBASCII\fP sposobów przedstawienia tych rzeczy w nienajkrótszym kodowaniu \fBUTF\-8\fP. .SS STANDARDY .\" .SH AUTHOR .\" Markus Kuhn ISO/IEC 10646\-1:2000, Unicode 3.1, RFC\ 3629, Plan 9. .SH "ZOBACZ TAKŻE" \fBlocale\fP(1), \fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7), \fBunicode\fP(7) .PP .SH TŁUMACZENIE Tłumaczenie niniejszej strony podręcznika: Gwidon S. Naskrent , Andrzej Krzysztofowicz i Michał Kułach . .PP Niniejsze tłumaczenie jest wolną dokumentacją. Bliższe informacje o warunkach licencji można uzyskać zapoznając się z .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License w wersji 3 .UE lub nowszej. Nie przyjmuje się ŻADNEJ ODPOWIEDZIALNOŚCI. .PP Błędy w tłumaczeniu strony podręcznika prosimy zgłaszać na adres listy dyskusyjnej .MT manpages-pl-list@lists.sourceforge.net .ME .