UTF-8: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
ValterVBot (discussione | contributi)
m Bot: Elimino tutti gli interlinks vedi Wikidata: D:Q193537
FrescoBot (discussione | contributi)
m Bot: overlinking giorni e mesi dell'anno e modifiche minori
Riga 7:
Quattro byte possono sembrare troppi per un solo carattere; tuttavia questo è richiesto solo per i caratteri che stanno fuori dal ''Basic Multilingual Plane'', generalmente molto rari. Inoltre anche [[UTF-16]] (la principale alternativa a UTF-8) richiede quattro byte per questi caratteri. Quale sia più efficiente, UTF-8 o UTF-16, dipende dall'intervallo di caratteri utilizzati, e l'uso di [[Compressione dei dati|algoritmi di compressione]] tradizionali riduce in maniera significativa la differenza tra le due codifiche. Per brevi brani di testo, su cui gli algoritmi di compressione tradizionali non sono efficienti e una ridotta occupazione di memoria è importante si potrebbe utilizzare lo [[Schema di compressione standard per Unicode]].
 
La [[Internet Engineering Task Force|IETF]] (''Internet Engineering Task Force'') richiede che tutti i [[Protocollo di rete|protocolli]] [[Internet]] identifichino la codifica dei caratteri utilizzata, e che siano in grado di utilizzare almeno UTF-8.
 
== Descrizione ==
Riga 49:
Per esempio, il carattere [[aleph|alef]] (א), corrispondente all'Unicode U+05D0, viene rappresentato in UTF-8 con questo procedimento:
 
* ricade nell'intervallo da 0x0080 a 0x07FF. Secondo la tabella verrà rappresentato con due byte. ''110xxxxx 10xxxxxx''.
* l'esadecimale 0x05D0 equivale al binario 101-1101-0000.
* gli undici bit vengono copiati in ordine nelle posizioni marcate con "x". 110-'''10111''' 10-'''010000'''.
* il risultato finale è la coppia di byte 11010111 10010000, o in esadecimale 0xD7 0x90
 
Riassumendo, i primi 128 caratteri vengono rappresentati con un singolo byte. I successivi 1920 ne richiedono due, e comprendono gli alfabeti [[Alfabeto latino|Latino]] con [[Diacritico|diacritici]], [[Alfabeto greco|Greco]], [[Alfabeto cirillico|Cirillico]], [[Alfabeto copto|Copto]], [[Alfabeto armeno|Armeno]], [[Alfabeto ebraico|Ebraico]] e [[Alfabeto arabo|Arabo]]. I restanti caratteri nel ''Basic Multilingual Plane'' hanno bisogno di tre byte, tutto il resto di quattro.
 
Potenzialmente, UTF-8 sarebbe in grado di usare sequenze fino a 6 byte, coprendo l'intervallo da U+0000 a U+7FFFFFFF (31 bit), ma nel [[2003]] UTF-8 è stato limitato dallo standard RFC 3629 per coprire solo l'intervallo descritto formalmente nello standard Unicode, ovvero da U+0000 a U+10FFFF. In precedenza i soli byte che non potevano comparire in una sequenza UTF-8 valida erano 0xFE e 0xFF. Con l'introduzione del precedente limite, il numero di byte non usati dalla codifica UTF-8 è salito a 13: 0xC0, 0xC1, e da 0xF5 a 0xFF. Anche se la nuova definizione di UTF-8 limita in modo consistente l'insieme di caratteri Unicode rappresentabili, il problema delle rappresentazioni multiple dello stesso carattere, un potenziale rischio per la sicurezza, scompare in quanto ognuna di queste sequenze conterrebbe uno dei byte non usati, risultando non valida.
Riga 85:
Tutte le possibilità hanno vantaggi e svantaggi, ma bisogna prestare particolare attenzione alla sicurezza se la verifica di validità dell'input viene compiuta prima della conversione da UTF-8.
 
Le forme lunghe (in cui un carattere viene codificato con più byte di quelli strettamente necessari, ma sempre nel rispetto delle regole precedenti) sono uno dei tipi di input che presentano maggiori problemi. Lo standard corrente prescrive che queste forme non vengano decodificate, ma specifiche più vecchie si limitavano a segnalare il problema, e molti ''decoder'' dei più semplici procedono alla decodifica senza nessun messaggio di avvertimento. Le forme lunghe sono state usate per scavalcare i controlli di sicurezza in prodotti di alto profilo, incluso il ''[[web server]]'' [[Internet Information Services]] (IIS) di [[Microsoft]]
 
Per mantenere la sicurezza nel caso di ''input'' non valido ci sono due opzioni. La prima è di decodificare il codice UTF-8 ''prima'' di fare qualsiasi controllo di validità necessario sull'''input''. La seconda è di usare un ''decoder'' più rigido, che nel caso di ''input'' non valido restituisca un errore o un testo che l'applicazione consideri innocuo.
Riga 94:
* Una sequenza di byte che codifica un carattere non può apparire come parte di una sequenza più lunga che codifica un altro carattere, come succedeva per codifiche a lunghezza variabile meno recenti (vedi la sezione precedente).
* Il primo byte di una sequenza è sufficiente a determinarne la lunghezza (è sufficiente contare il numero di bit più significativi con valore uno). Questo rende molto semplice estrarre una sotto-stringa da una stringa più lunga, senza bisogno di decodificare la sequenza di byte UTF-8.
* La maggioranza del [[software]] esistente (inclusi i [[Sistema operativo|sistemi operativi]]) è stata scritta senza tener conto di Unicode, e l'uso di Unicode creerebbe problemi di compatibilità. Per esempio la libreria standard del [[C (linguaggio)|C]] marca la fine di una stringa con un byte nullo (0x00). Usando UTF-16 il carattere Unicode "A" verrebbe codificato come 0x0041. Il primo byte verrebbe trattato come il marcatore di fine stringa, e il secondo e tutti i successivi verrebbero ignorati. UTF-8 è pensato in modo che nessuno dei byte codificati possa assumere uno dei valori speciali del codice ASCII, evitando questo e problemi simili.
* UTF-8 è la codifica predefinita per il formato [[XML]].
 
Riga 103:
 
== Storia ==
UTF-8 è stato ideato da [[Ken Thompson]] e [[Rob Pike]] il [[2 settembre]] [[1992]] su una tovaglietta in una tavola calda del [[New Jersey]]. Il giorno dopo Pike e Thompson l'hanno implementato e hanno aggiornato [[Plan 9]], il loro [[Sistema operativo]], per usarlo.
 
UTF-8 è stato presentato ufficialmente nel gennaio del [[1993]] a [[San Diego (California)|San Diego]] in occasione della conferenza annuale di [[Usenix]].