UTF-7 (Unicode Transformation Format, 7 bit) è una codifica di 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.
Il moderno standard MIME che definisce il formato dei messaggi e-mail, vieta la codifica delle intestazioni utilizzando valori di byte superiori ai 7 bit dello ASCII standard. Anche se MIME consente la codifica del corpo del messaggio usando vari set di caratteri, l'infrastruttura di trasmissione di base (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 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 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.
Una forma modificata di UTF-7 è attualmente utilizzata nel protocollo IMAP per i nomi delle cassette postali.
UTF-7 è stato proposto come un protocollo sperimentale nella RFC 1642, "A Mail-Safe Transformation Format of Unicode". Questa RFC è diventata obsoleta dopo la RFC 2152, RFC informativo che non è mai diventato uno standard. Come la RFC 2152 afferma chiaramente, "non specifica uno standard Internet di alcun tipo". Nonostante ciò, la RFC 2152 è citata come la definizione di UTF-7 nella lista di set di caratteri IANA. UTF-7 non è nemmeno uno standard Unicode. Lo standard Unicode 5.0 contempla solo UTF-8, UTF-16 e UTF-32. Ne esiste anche una versione modificata, specificata nella RFC 2060, a volte identificata come UTF-7.
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: ' ( ) , - . / : ? . 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 ~ \ + 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ù (+) potrebbe essere codificato come +-.
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 +. La fine è indicato da qualsiasi carattere che non sia nel set Base64 modificato. Se il carattere dopo il blocco in Base64 modificato è un -, 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.
In primo luogo, un codificatore deve decidere quali caratteri rappresentare direttamente in ASCII, quale segno + deve diventare +-, e quali includere in blocchi di caratteri Unicode. Un codificatore molto semplice potrebbe rendere tutti i caratteri sicuri in maniera diretta. Avrebbe tuttavia un costo maggiore il dover terminare una sequenza Unicode per rendere un singolo carattere direttamente e poi iniziare un'altra sequenza Unicode. Meglio rappresentare quel carattere come parte di una sequenza Unicode. Ogni sequenza Unicode va codificata utilizzando la procedura riportata di seguito, quindi racchiusa dai delimitatori appropriati.
Usando come esempio questa sequenza di due caratteri £† (U+00A3 U+2020):
0x00A3 → 0000 0000 1010 00110x2020 → 0010 0000 0010 0000
0000 0000 1010 0011 and 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
0000 0000 1010 0011 0010 0000 0010 0000 → 000000 001010 001100 100000 001000 00
000000 001010 001100 100000 001000 00 → 000000 001010 001100 100000 001000 000000
000000 001010 001100 100000 001000 000000 → AKMgIA
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 deve essere decodificato con la seguente procedura (utilizzando il risultato dell'esempio precedente come esempio di decodifica):