UTF-7 (7-bit Unicode Transformation Format) es una codificación de caracteres de longitud variable que fue propuesta para representar texto codificado con Unicode usando un flujo de caracteres ASCII, para ser usado, por ejemplo en mensajes de correo electrónico de Internet. A pesar del nombre, UTF-7 no es un formato de transformación y no forma parte del estándar Unicode.

El protocolo básico de transporte de mensajes de correo electrónico en Internet, SMTP especifica que el formato de transmisión es ASCII y no permite valores de bytes fuera de ese rango. MIME provee una forma de especificar un conjunto de caracteres, permitiendo el uso de diferentes conjuntos de caracteres incluyendo UTF-8 y UTF-16. Sin embargo, la infraestructura de transmisión que subyace aún no garantiza soporte para 8-bit y por tanto es necesario codificar el contenido para poder transmitirlo. Por desgracia, base64 tiene el problema de hacer ilegibles incluso los caracteres ASCII y la combinación de UTF-8 con Quoted-Printable produce un formato muy ineficiente puesto que requieren entre 6 a 9 bytes por cada carácter no ASCII dentro de BMP y 12 bytes para caracteres fuera de BMP.

Siguiendo las reglas de codificación de UTF-7 es posible enviar texto en un correo electrónico sin necesidad de utilizar un transfer encoding de MIME diferente, pero aun así debe ser explícitamente identificado con el conjunto de caracteres del texto. Si es utilizado en encabezados de correo electrónico como "Subject:" UTF-7 debe ser contenido dentro de un encoded word identificando el conjunto de caracteres. Dado que encoded word obliga al uso de quoted-printable o base64, UTF-7 está diseñado para no usar el símbolo "=" como un carácter de escape para evitar conflictos cuando se combine con quoted-printable.

UTF-7 generalmente no se utiliza como una representación nativa dentro de aplicaciones dado que es un proceso bastante difícil de manejar. También se ha introducido 8BITMIME con propósitos similares, este reduce la necesidad de codificar mensajes con formato 7-bit. A pesar de las ventajas de tamaño que presenta sobre la combinación de UTF-8 ya sea con quuoted-printable o base64, el IMC no recomienda su uso.

En el protocolo de recuperación de mensajes IMAP actualmente se utiliza una forma modificada de UTF-7. Véase la sección 5.1.3 de RFC 3501 para más detalles.

UTF-7 fue propuesto inicialmente como un protocolo experimental en la RFC 1642, A Mail-Safe Transformation Format of Unicode (Un Formato de Transformación de Unicode Amigable para Correo). Esta RFC ha quedado obsoleta por RFC 2152, una RFC informativa la cual nunca se convirtió en estándar. Según se expresa claramente en la RFC 2152, la RFC "no especifica ninguna clase de estándar de Internet". A pesar de esto la RFC 2152 es citada como la definición de UTF-7 en la lista de conjuntos de caracteres de la IANA. UTF-7 tampoco es un estándar de Unicode. El Estándar de Unicode 5.0 solamente lista UTF-8, UTF-16 y UTF-32.

Algunos conjuntos de caracteres pueden ser representados directamente con bytes únicos de ASCII. El primer conjunto es conocido como "caracteres directos" y contiene todos los 62 caracteres alfanuméricos y 9 símbolos: ' ( ) , - . / : ?. Los caracteres directos son considerados muy seguros para ser incluidos literalmente. El otro conjunto principal, conocido como "caracteres directos opcionales", contiene todos los otros caracteres imprimibles en el rango U+0020–U+007E excepto ~ \ + y el carácter espacio. Usando los caracteres directos opcionales se reduce el tamaño y se mejora la legibilidad para los seres humanos, pero, también se incrementan las posibilidades de errores a consecuencia de puertas de enlace de correo mal configuradas, además, puede requerir caracteres de ecape extra cuando se combina con encoded word.

El espacio, la tabulación, el retorno y el carácter de nueva línea pueden ser usados también directamente como bytes simples de ASCII. Sin embargo, si el texto codificado será usado en un correo electrónico, es necesario tener cuidado en garantizar que estos caracteres sean usados de manera que no requieran codificación adicional para que sean adecuados para dicho fin.

Otros caracteres tienen que ser codificados en UTF-16 y luego en base64 modificado. El inicio de estos bloques de base64 modificado codificados en UTF-16 está indicado por un símbolo +. El final se indica por cualquier carácter que no pertenezca al conjunto de base64 modificado. Como caso especial, si el carácter después del bloque base64 modificado es un - entonces este es consumido. Como otro caso especial, los caracteres literales + pueden ser codificados como +- y deben ser codificados usando base64 modificado también.

• "Hola Mundo!" es codificado como "Hola Mundo!"
• "1 + 1 = 2" es codificado como "1 +- 1 +AD0 2"
• "£1" es codificado como "+AKM-1". El código Unicode para el símbolo de libra es U+00A3 (el cual es 00A3₁₆ en UTF-16), se convierte en base64 modificado como se muestra en la tabla a continuación. Dos bits quedan fuera y son rellenados a 0.

Primeramente un codificador debe decidir qué caracteres representar directamente en ASCII y cuales colocar en bloques de caracteres unicode. Un codificado simple puede codificar todos los caracteres que considere seguro codificar directamente. Sin embargo el costo de construir un bloque unicode para representar un único carácter y luego obtenerlo de vuelta es de 3 a 3⅔ bytes, esto es más que los 2⅔ bytes necesarios para representar ese carácter como parte de una secuencia unicode.

Una vez que las secuencias unicode se han decidido, estas deben ser codificadas usando el siguiente procedimiento y luego rodeadas con los delimitadores apropiados

Se usará la secuencia de caracteres £† (0x00A3) (0x2020) como ejemplo

1. Expresar los números Unicode (UTF-16) de los caracteres en binario:
   0x00A3 → 0000 0000 1010 0011
0x2020 → 0010 0000 0010 0000
2. Concatenar las secuencias binarias
   0000 0000 1010 0011 y 0010 0000 0010 0000 → 0000 0000 1010 0011 0010 0000 0010 0000
3. Reagrupar los valores binarios en grupos de seis bits, comenzando por la izquierda:
   0000 0000 1010 0011 → 000000 001010 001100 100000 001000 00
4. Si el último grupo tiene menos de seis bits, agregar ceros al final:
   0000 0000 1010 0011 → 000000 001010 001100 100000 001000 000000
5. Reemplazar cada grupo de seis bits por su respectivo códigoo Base64:
   000000 001010 001100 100000 001000 000000 → AKMgIA

Primeramente el mensaje tiene que ser separado en texto plano ASCII y bloques unicode como se mencionó en la sección de descripción, una vez hecho esto los bloques unicode tienen que ser decodificados usando el siguiente procedimiento (se utiliza el resultado de la codificación en la sección anterior)

1. Expresar cada código Base64 como la secuencia de bits que representa:
   AKMgIA → 000000 001010 001100 100000 001000 000000
2. Reagrupar los valores binarios en grupos de 16 bits, comenzando por la izquireda:
   000000 001010 001100 → 0000000010100011 0010000000100000 0000
3. Si quedase algún grupo incompleto al final, este se descarta (Si el grupo incompleto contiene más de cuatro bits o contiene algún uno, el código es inválido):
   0000000010100011 0010000000100000
4. Cada grupo de 16 bits es un número de carácter Unicode (UTF-16) que puede ser expresado en otras formas:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163₁₀

UTF-7 permite muchas representaciones del mismo texto fuente, esto se logra intercambiando el modo base64 múltiples veces. Los transportes modernos de correo y otros pueden manejar UTF-8, así que el uso de UTF-7 ya no es requerido como lo fue históricamente. Las aplicaciones modernas deberían considerar soportar otras codificaciones más seguras en su lugar.

Algunas propuestas han tenido lugar sobre UTF-6 y UTF-5 para entornos de radiotelegrafía,^[1]​^[2]​ sin embargo hasta 2006 no se había formalizado un estándar UTF.

• Estas propuestas no están relacionadas con Punycode.