UTF-7: differenze tra le versioni

Versione delle 13:20, 5 feb 2014

Versione attuale delle 19:02, 21 mar 2025

(7 versioni intermedie di 7 utenti non mostrate)

Riga 1:

'''UTF-7''' (Unicode Transformation Format, ''7 bit'') è una [[codifica deidi caratteri]] in sequenze di byte di lunghezza variabile, proposto per la rappresentazione di testo [[Unicode]] utilizzando un flusso di caratteri [[ASCII]]. Originariamente destinato alla codifica del testo in [[Unicode]] per la composizione di messaggi di [[posta elettronica]] in modo più efficiente rispetto alla combinazione di codifiche [[UTF-8]] e [[quoted-printable]], non diventò mai una codifica standard.

{{Avvisounicode}}

{{Tabella Unicode}}

'''UTF-7''' (Unicode Transformation Format, ''7 bit'') è una [[codifica dei caratteri]] in sequenze di byte di lunghezza variabile, proposto per la rappresentazione di testo [[Unicode]] utilizzando un flusso di caratteri [[ASCII]]. Originariamente destinato alla codifica del testo in [[Unicode]] per la composizione di messaggi di [[posta elettronica]] in modo più efficiente rispetto alla combinazione di codifiche [[UTF-8]] e [[quoted-printable]], non diventò mai una codifica standard.

== Motivazione ==

Il moderno standard [[MIME]] che definisce il formato dei messaggi [[e-mail]], vieta la codifica delle [[Header | intestazioni]] utilizzando valori di byte superiori ai 7 bit dello [[ASCII]] standard. Anche se MIME consente la codifica del corpo del messaggio usando vari [[Codifica di caratteri | set di caratteri]], l'infrastruttura di trasmissione di base ([[Simple Mail Transfer Protocol | SMTP]], il principale standard di trasferimento e-mail) non è adatta per rappresentare correttamente caratteri a [[8 bit]]. Pertanto, in caso di ambiguità, è necessario applicare una codifica di trasferimento non banale. D'altro canto una codifica [[base64]] avrebbe lo svantaggio di rendere anche i caratteri [[ASCII]] illeggibili ai [[client]] non-MIME. UTF-8 combinato con [[quoted-printable]] è inefficiente e richiede 6-9 byte per i caratteri non ASCII compresi nel [[Unicode#Piano_di_base_multilinguistico_.28BMP.29| BMP]] e 12 byte per i caratteri al di fuori del BMP.

Qualora vengano seguite determinate regole di codifica, un testo UTF-7 potrà essere inviato per e-mail senza passare per una un'ulteriore codifica di trasferimento MIME, ma deve essere esplicitamente identificato come set di caratteri di testo. Inoltre, se viene usato all'interno di intestazioni e-mail come "Oggetto:", una parola codificata in UTF-7 deve necessariamente essere incapsulata in un MIME che identifica il set di caratteri. Dal momento che le parole codificate mediante [[quoted-printable]] o [[base64]], usano un carattere = come carattere di escape di inizio sequenza, viene vanificato il risparmio di spazio che UTF-7 consentirebbe.

UTF-7 non è generalmente usato come una rappresentazione nativa all'interno di applicazioni in quanto è molto difficile da trattare. Nonostante i vantaggi in termini di spazio rispetto UTF-8 con quoted-printable o base64, il suo utilizzo è sconsigliato dall'[[Internet Mail Consortium]].

Line 17 ⟶ 15:

Alcuni caratteri possono essere rappresentati direttamente come singoli byte ASCII. Il primo gruppo è conosciuto come ''"caratteri diretti"'' e contiene 62 caratteri alfanumerici e 9 simboli: <code> ' ( ) , - . / : ? </code>. I caratteri diretti non hanno bisogno di codifica. L'altro gruppo principale, noto come "caratteri diretti opzionali", contiene tutti gli altri caratteri stampabili nell'intervallo U+0020–U+007E tranne <code> ~ \ + </code> e lo '''spazio'''. Utilizzando i caratteri diretti opzionali si riducono le dimensioni e migliora la leggibilità umana, ma aumentano le probabilità che il flusso sia corrotto da gateway di posta mal progettati e può richiedere più codifiche quando viene usato in campi di intestazione.

Spazio, tab, [[ritorno a capo]] e avanzamento di riga possono anche essere rappresentati direttamente come singoli byte ASCII. Tuttavia, se il testo codificato deve essere utilizzato in posta elettronica, è necessario fare in modo che questi caratteri sono utilizzati per scopi che non richiedano ulteriori codifiche di trasferimento per le e-mail. Il segno più (<code>+</code>) ''potrebbe'' essere codificato come <code>+-</code>.

Altri caratteri devono essere codificati in [[UTF-16]] (quindi U+10000 e superiori sarebbero codificati in loro surrogati) e poi in Base 64 modificato. L'avvio di questi blocchi è indicato da un segno <code>+</code>. La fine è indicato da qualsiasi carattere che non sia nel set Base64 modificato. Se il carattere dopo il blocco in Base64 modificato è un <code>-</code>, questo viene mangiato dal decoder e la decodifica prosegue con il carattere successivo. In caso contrario la decodifica riprende con il carattere che segue il blocco in Base64.

Line 41 ⟶ 39:

===Decodifica===

Il primo passo consiste nel separare il dato in semplici pezzi di testo ASCII e in blocchi Unicode non vuoti. Fatto questo, ogni [[Blocco (Unicode)|blocco Unicode]] deve essere decodificato con la seguente procedura (utilizzando il risultato dell'esempio precedente come esempio di decodifica):

#Esprimere ogni codice Base64 con la sequenza di bit che lo rappresenta:<br /><ttkbd>AKMgIA → 000000 001010 001100 100000 001000 000000</ttkbd>

#Raggruppare le cifre binarie in gruppi di sedici bit, a partire da sinistra:<br /><ttkbd>000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000</ttkbd>

#Se alla fine rimane un gruppo incompleto, scartarlo (Se il gruppo incompleto contiene più di quattro bit o contiene quelli, il codice non è valido): <br /><ttkbd>0000000010100011 0010000000100000</ttkbd>

#Ogni gruppo di [[16 bit]] corrisponde al numero di un carattere Unicode (UTF-16) e può essere espresso in altre forme:<br><ttkbd>0000 0000 1010 0011 ≡ 0x00A3 ≡ 163₁₀</ttkbd>

== Voci correlate ==

Line 58 ⟶ 56:

* RFC 2152, UTF-7 - A Mail-Safe Transformation Format of Unicode (Update)

* RFC 2060, IMAP - Version 4 rev1

{{Tabella Unicode}}

{{Portale|informatica}}

[[Categoria:Repertori di caratteri]]