.\" -*- 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 giugno 2024" "Linux man\-pages 6.9.1" .SH NOME UTF\-8 \- una codifica Unicode multi\-byte compatibile con ASCII .SH DESCRIZIONE L'insieme di caratteri Unicode 3.0 occupa uno spazio a 16 bit. La codifica più naturale di Unicode (nota come UCS\-2) consta di sequenze di parole a 16 bit. Queste stringhe possono contenere\[em]come parte di molti caratteri a 16 bit\[em]byte come \[aq]\[rs]0\[aq] o \[aq]/\[aq], che hanno significato speciale per i nomi di file e per i parametri di altre funzioni della libreria C. Inoltre, la maggioranza degli strumenti UNIX si aspetta file in ASCII e non sa leggere parole a 16 bit come caratteri senza grosse modifiche. Per queste ragioni UCS\-2 non è una codifica esterna di Unicode adatta a nomi di file, file di testo, variabili d'ambiente, e così via. L'Insieme universale di caratteri ISO 10646 (UCS), un'estensione di Unicode, occupa uno spazio ancora maggiore\[em]a 31 bit\[em]e la sua codifica naturale, UCS\-4 (una sequenza di parole a 32 bit), soffre degli stessi problemi. .P 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à: .IP \[bu] 3 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. .IP \[bu] Tutti i caratteri UCS maggiori di 0x7f sono codificati come una sequenza di più byte consistente esclusivamente di byte nell'intervallo da 0x80 a 0xfd, in modo tale da non trovare nessun byte ASCII all'interno di un altro carattere, e da non avere problemi con, tra gli altri, [aq]\[rs]0\[aq] o \[aq]/\[aq]. .IP \[bu] L'ordinamento lessicografico delle stringhe in UCS\-4 viene preservato. .IP \[bu] Tutti i 2\[ha]31 possibili codici UCS possono essere codificati con UTF\-8. .IP \[bu] I byte 0xc0, 0xc1, 0xfe E 0xff non sono mai usati nella codifica UTF\-8. .IP \[bu] 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. .IP \[bu] 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 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 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. .P I valori del codice UCS 0xd800\[en]0xdfff (surrogati UTF\-16), così come 0xfffe e 0xffff (non\-caratteri UCS) non devono apparire nei flussi UTF\-8 conformi. Secondo RFC 3629 nessun punto oltre U+10FFFF dovrebbe essere usato, che limita i caratteri a quattro byte. .SS Esempio Il carattere Unicode 0xa9 = 1010 1001 (il simbolo di copyright) si codifica in UTF\-8 come .P .RS 11000010 10101001 = 0xc2 0xa9 .RE .P e il carattere 0x2260 = 0010 0010 0110 0000 (il simbolo "non uguale") si codifica come: .P .RS 11100010 10001001 10100000 = 0xe2 0x89 0xa0 .RE .SS "Note sull'applicazione" Gli utenti devono selezionare una localizzazione UTF\-8, ad esempio con .P .RS export LANG=en_GB.UTF\-8 .RE .P per poter attivare il supporto UTF\-8 nelle applicazioni. .P I software applicativi che devono riconoscere la codifica caratteri usata devono sempre impostare la localizzazione come .P .RS setlocale(LC_CTYPE, "") .RE .P e i programmatori possono quindi testare l'espressione .P .RS strcmp(nl_langinfo(CODESET), "UTF\-8") == 0 .RE .P 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. .P I programmatori abituati alle codifiche a singolo byte come US\-ASCII o ISO/IEC 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 per contare caratteri e posizionare il cursore. .P La sequenza ufficiale ESC per commutare da uno schema di codifica ISO/IEC\ 2022 (usato ad esempio dai terminali VT100) a UTF\-8 è ESC % G ("\[rs]x1b%G"). La corrispondente sequenza di ritorno da UTF\-8 a ISO/IEC\ 2022 è ESC % @ ("\[rs]x1b%@"). Altre sequenze ISO/IEC\ 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 , Marco Curreli e Giuseppe Sacco . .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 .