.\" -*- 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 "12 marzo 2023" "Linux man\-pages 6.05.01" .SH NOME UTF\-8 \- una codifica Unicode multi\-byte compatibile con ASCII .SH DESCRIZIONE The Unicode 3.0 character set occupies a 16\-bit code space. The most obvious Unicode encoding (known as UCS\-2) consists of a sequence of 16\-bit words. Such strings can contain\[em]as part of many 16\-bit characters\[em]bytes such as \[aq]\e0\[aq] or \[aq]/\[aq], which have a special meaning in filenames and other C library function arguments. In addition, the majority of UNIX tools expect ASCII files and can't read 16\-bit words as characters without major modifications. For these reasons, UCS\-2 is not a suitable external encoding of Unicode in filenames, text files, environment variables, and so on. The ISO/IEC 10646 Universal Character Set (UCS), a superset of Unicode, occupies an even larger code space\[em]31\ bits\[em]and the obvious UCS\-4 encoding for it (a sequence of 32\-bit words) has the same problems. .PP La codifica UTF\-8 di Unicode e UCS evita questi problemi, ed è il modo comune con cui Unicode è usato nei sistemi operativi tipo UNIX. .SS Proprietà La codifica UTF\-8 possiede queste ottime proprietà: .TP 0.2i * I caratteri UCS da 0x00000000 a 0x0000007f (i caratteri US\-ASCII classici) sono codificati semplicemente come byte da 0x00 a 0x7f (compatibilità ASCII). In altre parole, file e stringhe contenenti solamente caratteri ASCII a 7 bit hanno la stessa codifica sia in ASCII che in UTF\-8. .TP * All UCS characters greater than 0x7f are encoded as a multibyte sequence consisting only of bytes in the range 0x80 to 0xfd, so no ASCII byte can appear as part of another character and there are no problems with, for example, \[aq]\e0\[aq] or \[aq]/\[aq]. .TP * L'ordinamento lessicografico delle stringhe in UCS\-4 viene preservato. .TP * All possible 2\[ha]31 UCS codes can be encoded using UTF\-8. .TP * I byte 0xc0, 0xc1, 0xfe E 0xff non sono mai usati nella codifica UTF\-8. .TP * Il primo byte di una sequenza multibyte che rappresenta un carattere UCS non ASCII è sempre nell'intervallo da 0xc0 a 0xfd e indica la lunghezza della sequenza. Tutti i byte seguenti nella sequenza multibyte sono nell'intervallo da 0x80 a 0xbf, facilitando un'eventuale risincronizzazione e facendo diventare la codifica senza memoria e resistente a byte mancanti. .TP * I caratteri UCS codificati con UTF\-8 possono arrivare ai sei byte di lunghezza, tuttavia lo standard Unicode non specifica caratteri oltre 0x10ffff, così i caratteri Unicode possono essere lunghi solo fino a quattro byte in UTF\-8. .SS Codifica Le seguenti sequenze di byte vengono usate per rappresentare un carattere. La sequenza da usare dipende dal numero del codice UCS del carattere: .TP 0.4i 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 .PP Le configurazioni di bit \fIxxx\fP sono riempite coi bit del numero del codice carattere rappresentato in binario, prima il bit più significativo (big\-endian). Viene usata solo la più breve delle sequenze multibyte che possono rappresentare il numero del codice. .PP The UCS code values 0xd800\[en]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. .SS Esempio Il carattere Unicode 0xa9 = 1010 1001 (il simbolo di copyright) si codifica in UTF\-8 come .PP .RS 11000010 10101001 = 0xc2 0xa9 .RE .PP e il carattere 0x2260 = 0010 0010 0110 0000 (il simbolo "non uguale") si codifica come: .PP .RS 11100010 10001001 10100000 = 0xe2 0x89 0xa0 .RE .SS "Note sull'applicazione" Gli utenti devono selezionare una localizzazione UTF\-8, ad esempio con .PP .RS export LANG=en_GB.UTF\-8 .RE .PP per poter attivare il supporto UTF\-8 nelle applicazioni. .PP I software applicativi che devono riconoscere la codica caratteri usata devono sempre impostare la localizzazione con, ad esempio, .PP .RS setlocale(LC_CTYPE, "") .RE .PP e i programmatori possono quindi testare l'espressione .PP .RS strcmp(nl_langinfo(CODESET), "UTF\-8") == 0 .RE .PP per determinare se una localizzazione UTF\-8 è stata selezionata e se quindi tutti gli input e output standard in testo, comunicazioni terminale, contenuto in testo dei file, nomi file e variabili d'ambiente sono codificati in UTF\-8. .PP I programmatori abituati alle codifiche a singolo byte come US\-ASCII o ISO 8859 devono ricordare che due assunzioni valide qui non sono più valide nelle localizzazioni UTF\-8. Innanzitutto un singolo byte non corrisponde più necessariamente ad un singolo carattere. In secondo luogo, poiché i moderni emulatori di terminale in modalità UTF\-8 supportano anche caratteri a doppia larghezza cinese, giapponese e coreano e i caratteri combinanti, non spaziati, l'emissione di un singolo carattere non avanza necessariamente il cursore di una posizione come avveniva in ASCII. Funzioni di libreria come \fBmbsrtowcs\fP(3) e \fBwcswidth\fP(3) oggi devono essere usate posizioni di caratteri e cursore. .PP La sequenza ufficiale ESC per commutare da uno schema di codifica ISO 2022 (usato ad esempio dai terminali VT100) a UTF\-8 è ESC % G ("\ex1b%G"). La corrispondente sequenza di ritorno da UTF\-8 a ISO 2022 è ESC % @ ("\ex1b%@"). Altre sequenze ISO 2022 (come quelle per commutare gli insiemi G0 e G1) non sono applicabili in modalità UTF\-8. .SS Sicurezza Gli standard Unicode e UCS richiedono che i produttori di UTF\-8 debbano usare la forma più breve possibile, ad esempio produrre una sequenza a due byte con primo byte 0xc0 non è conforme. Unicode 3.1 ha aggiunto la richiesta che i programmi conformi non debbano accettare le forme non brevi nel loro input. Ciò è per ragioni di sicurezza: se l'input utente è verificato per possibili violazioni di sicurezza, un programma può verificare solo la versione ASCII di "/../" o ";" o NUL e dimenticare che ci sono molti modi non\- ASCII di rappresentare queste cose in una codifica UTF\-8 non breve. .SS Standard .\" .SH AUTHOR .\" Markus Kuhn ISO/IEC 10646\-1:2000, Unicode 3.1, RFC\ 3629, Plan 9. .SH "VEDERE ANCHE" \fBlocale\fP(1), \fBnl_langinfo\fP(3), \fBsetlocale\fP(3), \fBcharsets\fP(7), \fBunicode\fP(7) .PP .SH TRADUZIONE La traduzione italiana di questa pagina di manuale è stata creata da Ottavio G. Rizzo , Giulio Daprelà , Elisabetta Galli e Marco Curreli . .PP Questa traduzione è documentazione libera; leggere la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Versione 3 .UE o successiva per le condizioni di copyright. Non ci assumiamo alcuna responsabilità. .PP Per segnalare errori nella traduzione di questa pagina di manuale inviare un messaggio a .MT pluto-ildp@lists.pluto.it .ME .