Network Working Group F. Yergeau Request for Comments: 2279 Alis Technologies Obsoletes: 2044 January 1998 Category: Standards Track Traduzione a cura di Jinko - jinko [at] email [dot] com (Giugno 2008) Distribuita da .::http://www.rfc.altervista.org::. UTF-8, un formato di trasformazione dell'ISO 10646 Stato di questo Documento Questo documento specifica una traccia di protocollo Internet standard per la comunita' Internet, e richiede discussioni e suggerimenti per migliorie. Per la standardizzazione e lo stato di questo protocollo si faccia riferimento all'edizione corrente dell'"Internet Official Protocol Standards". La distribuzione di questo documento non e' soggetta a limitazioni. Nota di Copyright Copyright (C) The Internet Society (1998). All Rights Reserved. Sunto L'ISO/IEC 10646-1 definisce un set di carattere multi-ottetto chiamato Universal Character Set (UCS), il quale racchude la maggior parte dei sistemi di scrittura internazionali. I caratteri multi-ottetto, tuttavia, non sono compatibili con molte applicazioni e protocolli correnti, e questo ha portato allo sviluppo di alcuni dei cosiddetti protocolli di trasformazione dei formati UCS (UTF - UCS Transformation Formats)), ognuno con caratteristiche differenti. L'UTF-8, oggetto di questo documento, ha le caratteristiche di preservare il completo range US-ASCII, fornendo compatibilita' con i file systems, parsers e altro software che fa affidamento sui valori US-ASCII ma che e' trasparente agli altri valori. Questo documento aggiorna e sostituisce l'RFC 2044, in particolare indirizzando la questione delle versioni dei relativi standards. Yergeau Standards Track [Pagina 1] RFC 2279 UTF-8 January 1998 1. Introduzione L'ISO/IEC 10646-1 [ISO-10646] definisce un set multi-ottetto di caratteri chiamato Universal Character Set (UCS), il quale racchude la maggior parte dei sistemi di scrittura internazionali. Vengono definite due codifiche multi-ottetto, una codifica a quattro-ottetti per carattere denominata UCS-4 e una codifica a due-ottetti per carattere chiamata UCS-2, capaci di indirizzare solo i primi 64K caratteri dell'UCS (the Basic Multilingual Plane, BMP), al di fuori di quelli che non sono attualmente assegnati. E' da rilevare che lo stesso insieme di caratteri viene definito dall' Unicode standard [UNICODE], il quale definisce in aggiunta delle ulteriori proprieta' di carattere nonche' altri dettagli d'applicazione di grande interesse per gli implementatori, ma non ha la codifica UCS-4. Fino ad oggi si sono susseguiti cambiamenti nell'Unicode e nel ISO/IEC 10646, cosi' che i repositories dei caratteri e le assegnazioni del punto di codice sono rimaste sincronizzati. I comitati relativi alla standardizzazione si sono impegnati per mantenere questo utile sincronismo. Le codifiche UCS-2 e UCS-4 sono tuttavia difficili da usare in molte delle applicazioni correnti e dei protocolli che assumono a volte caratteri di 8 o 7 bit. Perfino i piu' nuovi sistemi capaci di operare con caratteri a 16 bit non processano dati di tipo UCS-4. Questa situazione ha condotto allo sviluppo dell'UCS Transformation Formats (UTF), ogni formato con caratteristiche differenti. L'UTF-1 ha solamente interesse storico, essendo stato rimosso dall'ISO/IEC 10646. L'UTF-7 ha la qualita'  di codificare tutto il repertorio BMP usando solo ottetti con bit distinti dell'ordine piu' alto (valori US-ASCII di 7 bit, [US-ASCII]), e cosi' la codifica viene ritenuta sicura ([RFC2152]). L'UTF-8, oggetto di questo documento, usa tutti i bit di un ottetto, ma ha la caratteristica di preservare tutto il campo US-ASCII: i caratteri US-ASCII sono codificati in un ottetto avente il normale valore US-ASCII, e qualsiasi ottetto con un tale valore puo' essere valido solamente per un carattere US-ASCII e null'altro. L'UTF-16 e' uno schema per la trasformazione di un sottinsieme del repertorio UCS-4 in una coppia di valori UCS-2 da un range riservato. L'UTF-16 comprime l'UTF-8 in tali valori UCS-2 dal range riservato che dev'essere gestito specialmente nella trasformazione UTF-8. L'UTF-8 codifica caratteri UCS-2 o UCS-4 come un numero variabile di ottetti, dove il numero di ottetti, e il valore di ognuno, dipendono dal valore intero assegnato al carattere nell'ISO/IEC 10646. Questo formato di trasformazione ha le seguenti caratteristiche (tutti i valori sono in esadecimale): - I valori dei caratteri da 0000 0000 a 0000 007F (repertorio US-ASCII) corrispondono agli ottetti da 00 a 7F (valori di US-ASCII di 7 bit). Una diretta conseguenza e' che una semplice stringa US-ASCII e' anche una stringa UTF-8 valida - I valori US-ASCII non appaiono d'altro canto in un flusso di caratteri UTF-8 codificati. Questo fornisce compatibilita' con file system o altro software (ad es. la funzione printf() della libreria C) che parsa basandosi sui valori US-ASCII ma che risulta trasparente ad altri valori. - La conversione circolare risulta semplice tra l'UTF-8 e l'UCS-2, UCS-4. Yergeau Standards Track [Pagina 2] RFC 2279 UTF-8 January 1998 - Il primo ottetto di una sequenza di piu' ottetti indica il numero degli ottetti nella sequenza. - I valori FE ed FF dell'otteto non compaiono mai. - I limiti dei caratteri sono facimente rinvenibili ovunque all'interno di un flusso di ottetti. - Viene mantenuto il metodo d'ordinamento lessicografico delle stringhe UCS-4. Ovviamente questo e' di interesse limitato dal momento che il metodo d'ordinamento non e' culturalmente valido in alcun caso. - L'algoritmo di ricerca veloce di Boyer-Moore puo' essere impiegato con i dati UTF-8. - Le stringhe UTF-8 possono essere riconosciute come tali, con ragionevole attendibilita', tramite un semplice algoritmo, e dunque la possibilita' che una stringa di caratteri codificata in una qualunque altra forma appaia come UTF-8 valido e' molto bassa e diminuisce con l'aumento della lunghezza della stringa. L'UTF-8 fu in origine un progetto del X/Open Joint Internationalization Group (XOJIG) e aveva l'obiettivo di specificare un formato di trasformazione UCS che garantisse il file system (File System Safe UCS Transformation Format [FSS-UTF]), compatibile con i sistemi unix, fornendo supporto multilingua in una singola codifica. Gli autori originali erano Gary Miller, Greger Leijonhufvud e John Entenmann. In seguito Ken Thompson e Rob Pike svolsero un lavoro significativo per il formato UTF-8. Una descrizione puo' inoltre essere trovata nel Rapporto Tecnico Unicode #4 e nello Unicode Standard, versione 2.0 [Unicode]. Il riferimento finale, che comprende le disposizioni per i dati UTF-16 all'interno dell'UTF-8, e' l'Annex R dell'ISO/IEC 10646-1 [ISO-10646] 2. Definizione dell'UTF-8 In UTF-8 i caratteri sono codificati usando una sequenza da 1 a 6 ottetti. L'unico ottetto di "una sequenza" di un singolo ottetto ha il bit di ordine piu' alto impostato a zero mentre i restanti 7 bit sono utilizzati per codificare il valore del carattere. In una sequenza di n ottetti, con n>1, l'ottetto iniziale ha gli n bit di ordine piu' alto impostati ad 1 seguiti da un bit impostato a 0. I restanti bits di quell'ottetto contengono i bits dal valore del carattere da decodificare. Gli ottetti successivi hanno tutti il bit di ordine piu' alto settato a 1 e il bit successivo settato a 0, lasciando 6 bits in ciascuno per contemnere i bits dal carattere da codificare. La tabella sottostante riassume il formato di questi diversi tipi di ottetti. La lettera x indica i bits disponibili per la codifica dei bits del valore del carattere UCS-4. Yergeau Standards Track [Pagina 3] RFC 2279 UTF-8 January 1998 range UCS-4 (esadecimale) sequenza dell'ottetto UTF-8(binario) 0000 0000-0000 007F 0xxxxxxx 0000 0080-0000 07FF 110xxxxx 10xxxxxx 0000 0800-0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx 0001 0000-001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx 0020 0000-03FF FFFF 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 0400 0000-7FFF FFFF 1111110x 10xxxxxx ... 10xxxxxx La codifica da UCS-4 a UITF-8 procede nel seguente modo: 1) Determina il numero degli otteti richiesti dal valore del carattere e la prima colonna della tabella sovrastante. E' importante notare che le righe della tabella sono mutuamente esclusive, cioe c'e' soltanto una via valida per codificare un dato carattere UCS-4. 2) Prepara i bits di ordine piu' alto degli ottetti come per la seconda colonna della tabella. 3) Mette nei bits marcati dalla x i bits del valore del carattere, iniziando dai bit di ordine piu' basso del valore del carattere e mettendoli prima nell'ultima sequenza dell'ottetto, poi il successivo all'ultimo, eccetera, finche' tutti i bits x sono stati riempiti. L'algortimo per la codifica da UCS-2 (o Unicode) a UTF-8 puo' essere ottenuto in linea di principio da quanto sopra estendendo semplicemente ogni carattere UCS-2 con due ottetti di valore zero. Tuttavia, la coppia di valori UCS-2 tra D800 e DFFF (coppie surrogate nel linguaggio Unicode), essendo attualmente caratteri UCS-4 trasformati attraverso UTF-16, necessitano di uno speciale trattamento: la trasformaione UTF-16 deve essere annullata, cedendo un carattere UCS-4 che viene poi trasformato come sopra. La decodifica da UTF-8 a UCS-4 procede invece come segue: 1) Inizializza i 4 ottetti del carattere UCS-4 con tutti i bit settati a 0. 2) Determina quali bit codificano il valore del carattere dal numero di ottetti nella sequenza e dalla seconda colonna della tabella di cui sopra (i bit marcati con la x) 3) Distribuisce i bit dalla sequenza al carattere UCS-4, prima i bit di ordine piu' basso dall'ultimo ottetto della sequenza e procedendo verso sinistra finche' non vi sono piu' bits x. Se la sequenza UTF-8 non e' piu' lunga di 3 ottetti, la decodifica puo' procedere direttamente all'UCS-2 Yergeau Standards Track [Page 4] RFC 2279 UTF-8 January 1998 NOTA -- le attuali inplementazioni dell'algoritmo di decodifica di cui sopra dovrebbero proteggersi contro la decodifica di sequenze non valide. Per esempio, un implementazione ingenua potrebbe (erroneamente) decodificare la sequenza UTF-8 non valida C0 80 nel carattere U+0000, il che potrebbe avere conseguenze nella sicurezza e/o causare altri problemi. Si veda la sezione Considerazioni di Sicurezza piu' avanti. Formule ed un algoritmo piu' dettagliato possono essere reperiti in [FSS_UTF], [UNICODE] o nel Annex R del [ISO-10646]. 3. Versione degli Standards L'ISO/IEC 10646 viene aggiornato di tanto in tanto dalle pubblicazioni di correzioni; similmente, esistono differenti versioni dello standard Unicode: al momento del presente documento troviamo la 1.0, 1.1 e la 2.0 . Ogni nuova versione rende obsoleta e sostutuisce quella precedente, ma le implementazioni, e piu' significativamente i dati, non sono aggiornati immediatamente. Generalmente, i cabiamenti riguardano l'aggiunta di nuovi caratteri, i quali non pongono particolari problemi con i vecchi dati. La quinta revisione all'ISO/IEC 10646, tuttavia, ha corretto ed espanso il blocco Korean Hangul, redendo non piu' valido in questa versione qualsiasi dato precedente che conteneva caratteri Hangul. Unicode 2.0 ha le stesse differenze dallo Unocide 1.1. La giustificazione ufficiale che permise un tale cambiamento incompatibile fu che non esisteva nessuna implementazione o dato contenente Hangul, una dichiarazione che poteva anche essere vera ma era non dimostrabile. La questione e' stata nominata "Korean mess" [N.d.T. - confusione del set Korean], e i relativi committenti si sono impegnati a non effettuare mai e poi mai piu' un cambiamento cosi' incompatibile. Le nuove versioni e in particolare tutti i cambiamenti incompatibili, hanno conseguenze riguardanti la codifica delle etichette dei caratteri MIME, che sono discusse nella sezione 5. 4. Esempi La sequenza UCS-2 "A." (0041, 2262, 0391, 002E) puo' essere codificata in UTF-8 come segue: 41 E2 89 A2 CE 91 2E La sequenza UCS-2 che rappresenta i caratteri Hangul per la parola coreana "hangugo" (D55C, AD6D, C5B4) puo' essere codificata come segue: ED 95 9C EA B5 AD EC 96 B4 Yergeau Standards Track [Pagina 5] RFC 2279 UTF-8 January 1998 La sequenza UCS-2 che rappresenta i caratteri Han per la parola giapponese "nihongo" (D55C, AD6D, C5B4) puo' essere codificata come segue: E6 97 A5 E6 9C AC E8 AA 9E 5. Registrazione MIME Questo documento viene inteso come base per la registrazione di un parametro MIME per un insieme di caratteri (charset) [CHARSET-REG]. Il valore del parametro proposto e' UTF-8. Questa stringa contrassegna i tipi di supporto contenenti testo consistente in caratteri dal repertorio dell'ISO/IEC 10646 comprese tutte le correzioni fino all'ultima revisione 5 (Korean block), codificata in una sequenza di ottetti attraverso lo schema di codifica di cui sopra. L'UTF-8 puo' essere utilizzato per la gestione dei tipi di contenuto MIME al di sotto del tipo di livello piu' alto "text". Si noti che il marcatore "UTF-8" non contiene una versione di identificazione, riferendosi genericamente all'ISO/IEC 10646. Questa scelta e' voluta, per i motivi che seguono. Un etichetta di un insieme di caratteri MIME e' concepita per dare solo le informazioni necessarie ad interpretare una sequenza di bytes ricevuta in una sequenza di caratteri, nulla di piu' (vedasi l'RFC 2045, sezione 2.2, in [MIME]). Finche' un set standard di caratteri non cambia incompatibilmente, i numeri di versione servono a nessun scopo, perchè non si guadagan nulla dall'apprendimento dall'etichetta che ha nuovamente assegnato caratteri possono essere ricevuti senza consocere nulal a riguardo. L'etichetta non insegna nulla a se stessa circa i nuovi caratteri, i quali saranno ricevuti ugualmente. Fintanto che gli standars si evolvono in maniera compatibile i numeri di versione non hanno ragione di esistere, poiche' non ci si guadagna nulla dalla loro presenza. La tag di per se' non da alcuna informazione sui nuovi caratteri che vengono ricevuti in ogni caso. Dunque, fermo restando l'evoluzione compatibile degli standards, il vantaggio apparente di avere etichette che identifichino le versioni null'altro e' che apparenza. Vi e' anzi uno svantaggio ad avere delle etichette dipendenti dalla versione: quando un'applicazione piu' vecchia riceve dei dati accompagnati da una etichetta piu' recente e quindi sconosciuta, essa potrebbe non riconoscerla ed non essere cosi' in grado di gestire i dati, quando invece un'etichetta generica, e quindi conosciuta, avrebbe determinato la piu' corretta elaborazione degli stessi dati che avrebbero potuto anche non contenere alcun nuovo carattere. Ora il "Korean mess" (ISO/IEC 10646 amendment 5) e' una modifica non comaptibile, per lo piu' contraddicendo alla convenienza d'avere un'etichetta indipendente dalla versione del charset MIME come descritto prima. Ma il problema di compatibilita' puo' presentarsi solamente con i dati contenenti caratteri Hangul coreani codificati secondo l'Unicode 1.1 (o l'equivalente ISO/IEC 10646 prima della revisione 5) e non vi sono discutibilmente dei dati tali da preoccuparsi, e' questo e' il motivo per cui la modifica incompatibile e' stata ritenuta accettabile. Yergeau Standards Track [Page 6] RFC 2279 UTF-8 January 1998 Nella pratica, inoltre, un'etichetta indipendente dalla versione viene autorizzata, a condizione che l'etichetta venga intesa riferirsi a tutte le versioni successive alla revisione 5 e non vi siano al presente modifiche non compatibili. Modifiche non compatibili potrebbero presentarsi in una successiva versione dell'ISO/IEC 10646, l'etichetta del charset MIME qui definita sara' allineata con le versioni precedenti finquando l'IETF non decida diversamente. Si propone inoltre di registrare il valore del paramentro charset "UNICODE-1-1-UTF-8" al solo scopo di etichettare dei dati di testo contenenti sillabe Hangul codificate in UTF-8 senza tener conto della revisione 5 dell'ISO/IEC 10646 (vale a dire, usando i punti precedenti alla revisione 5). Qualsiasi altro dato UTF-8 NO DOVREBBE utilizzare questa etichetta, in particolare i dati che non contengono alcuna sillaba Hangul, e ci sentiamo inoltre di dover fortemente raccomandare di non creare alcun tipo di dato contenente Hangul senza tener conto della revisione 5 dell'ISO/IEC 10646. 6. Considerazioni di Sicurezza Gli implementatori dell'UTF-8 devono valutare gli aspetti relativi alla sicurezza in merito alla gestione dell sequenze UTF-8 illegali. E' pensabile che in alcune circostanze un utente malintenzionato potrebbe essere in grado di sfruttare un incauto parser UTF-8 inviandogli una seqeunza di ottetto che non e' permessa dalla sintassi UTF-8. Una forma particolarmente sottile di quest'attacco potrebbe essere effettuata nei confronti di quei parsers che eseguono controlli di sicurezza sulla validita' della forma di codifica UTF-8 degli input che ricevono ma che interpretano determinate sequenze illegali come caratteri. Ad esempio, un parser potrebbe vietare il caarattere NULL quando codificato come una sequenza di singolo ottetto 00, ma consentire l'illegale sequenza di due ottetti C0 80 ed interpretarla come carattere NULL. Un altro esempio potrebbere essere un parser che vieta la sequenza di ottetti 2F 2E 2E 2F ("/../") ma che permette l'illegale sequenza di ottetti 2F C0 AE 2E 2F. Ringraziamenti Quanti seguono hanno partecipato nella redazione e discussione del presente documento: James E. Agenbroad Andries Brouwer Martin J. D|rst Ned Freed David Goldsmith Edwin F. Hart Kent Karlsson Markus Kuhn Michael Kung Alain LaBonte John Gardiner Myers Murray Sargent Keld Simonsen Arnold Winkler Yergeau Standards Track [Pagina 7] RFC 2279 UTF-8 January 1998 Bibliografia [CHARSET-REG] Freed, N., and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998. [FSS_UTF] X/Open CAE Specification C501 ISBN 1-85912-082-2 28cm. 22p. pbk. 172g. 4/95, X/Open Company Ltd., "File System Safe UCS Transformation Format (FSS_UTF)", X/Open Preleminary Specification, Document Number P316. Also published in Unicode Technical Report #4. [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- Information technology -- Universal Multiple-Octet Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Five amendments and a technical corrigendum have been published up to now. UTF-8 is described in Annex R, published as Amendment 2. UTF-16 is described in Annex Q, published as Amendment 1. 17 other amendments are currently at various stages of standardization. [MIME] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045. N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046. K. Moore, "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047. N. Freed, J. Klensin, J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048. N. Freed, N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049. All November 1996. [RFC2152] Goldsmith, D., and M. Davis, "UTF-7: A Mail-safe Transformation Format of Unicode", RFC 1642, Taligent inc., May 1997. (Obsoletes RFC1642) [UNICODE] The Unicode Consortium, "The Unicode Standard -- Version 2.0", Addison-Wesley, 1996. [US-ASCII] Coded Character Set--7-bit American Standard Code for Information Interchange, ANSI X3.4-1986. Yergeau Standards Track [Pagina 8] RFC 2279 UTF-8 January 1998 Indirizzo dell'Autore Francois Yergeau Alis Technologies 100, boul. Alexis-Nihon Suite 600 Montreal QC H4M 2P2 Canada Phone: +1 (514) 747-2547 Fax: +1 (514) 747-2561 EMail: fyergeau@alis.com