UTF-7

UTF-7 ( formato de transformación Unicode de 7 bits ) es una codificación de caracteres de longitud variable obsoleta para representar texto Unicode mediante un flujo de caracteres ASCII . En un principio, su objetivo era proporcionar un medio de codificación de texto Unicode para su uso en mensajes de correo electrónico de Internet que fuera más eficiente que la combinación de UTF-8 con quoted-printable .

UTF-7 (según su RFC) no es un " formato de transformación Unicode ", ya que la definición solo puede codificar puntos de código en el BMP (los primeros 65536 puntos de código Unicode, que no incluyen emojis y muchos otros caracteres). Sin embargo, si un traductor UTF-7 va de/hacia UTF-16 , entonces puede (y probablemente lo hace) ^{[ cita requerida ]} codificar cada mitad sustituta como si fuera un punto de código de 16 bits y, por lo tanto, puede codificar todos los puntos de código. No está claro si otro software UTF-7 (como los traductores a UTF-32 o UTF-8) admiten esto.

UTF-7 nunca ha sido un estándar oficial del Consorcio Unicode . Se sabe que tiene problemas de seguridad, por lo que se han realizado cambios en el software para deshabilitar su uso. ^[1] Está prohibido en HTML 5. [ ^{2] [3]}

MIME , el estándar moderno para formatos de correo electrónico, prohíbe la codificación de encabezados utilizando valores de bytes por encima del rango ASCII. Aunque MIME permite codificar el cuerpo del mensaje en varios conjuntos de caracteres (más amplios que ASCII), aún no se garantiza que la infraestructura de transmisión subyacente ( SMTP , el principal estándar de transferencia de correo electrónico) sea de 8 bits . Por lo tanto, se debe aplicar una codificación de transferencia de contenido no trivial en caso de duda. Desafortunadamente, Base64 tiene la desventaja de hacer que incluso los caracteres ASCII sean ilegibles en clientes que no sean MIME. Por otro lado, UTF-8 combinado con quoted-printable produce un formato muy ineficiente en términos de tamaño que requiere de 6 a 9 bytes para caracteres no ASCII del BMP y 12 bytes para caracteres fuera del BMP.

Si se siguen ciertas reglas durante la codificación, UTF-7 se puede enviar por correo electrónico sin utilizar una codificación de transferencia MIME subyacente , pero aún así debe identificarse explícitamente como el conjunto de caracteres de texto. Además, si se utiliza en encabezados de correo electrónico como "Asunto:", UTF-7 debe estar incluido en palabras codificadas con MIME que identifiquen el conjunto de caracteres. Dado que las palabras codificadas obligan al uso de quoted-printable o Base64 , UTF-7 se diseñó para evitar el uso del signo = como carácter de escape para evitar el doble escape cuando se combina con quoted-printable (o su variante, la codificación "Q" de encabezados RFC 2047/1522).

UTF-7 no suele utilizarse como representación nativa en las aplicaciones, ya que es muy difícil de procesar. A pesar de su ventaja de tamaño sobre la combinación de UTF-8 con quoted-printable o Base64, el ahora extinto Consorcio de Correo de Internet recomendó no utilizarlo. ^[4]

También se ha introducido 8BITMIME , que reduce la necesidad de codificar los cuerpos de los mensajes en un formato de 7 bits.

Una forma modificada de UTF-7 (a veces denominada 'mUTF-7' ^[5] ) se utilizó en el protocolo de recuperación de correo electrónico IMAP (Internet Message Access Protocol) , versión 4 rev 1, para nombres de buzones de correo "internacionales". ^[6] La siguiente versión, IMAP versión 4 rev 2, utiliza UTF-8 en su lugar. ^[7]

UTF-7 se propuso por primera vez como protocolo experimental en el RFC 1642, A Mail-Safe Transformation Format of Unicode . Este RFC ha quedado obsoleto a raíz del RFC 2152, un RFC informativo que nunca se convirtió en estándar. Como indica claramente el RFC 2152, el RFC "no especifica ningún tipo de estándar de Internet". A pesar de ello, el RFC 2152 se cita como la definición de UTF-7 en la lista de conjuntos de caracteres de la IANA. UTF-7 tampoco es un estándar Unicode. El estándar Unicode 5.0 solo incluye UTF-8, UTF-16 y UTF-32. También existe una versión modificada, especificada en el RFC 2060, que a veces se identifica como UTF-7.

Algunos caracteres se pueden representar directamente como bytes ASCII individuales. El primer grupo se conoce como "caracteres directos" y contiene 62 caracteres alfanuméricos y 9 símbolos: ' ( ) , - . / : ?. Los caracteres directos se pueden incluir de forma segura de forma literal. El otro grupo principal, conocido como "caracteres directos opcionales", contiene todos los demás caracteres imprimibles en el rango U+ 0020 –U+007E excepto ~ \ +y espacio (los caracteres \y ~se excluyen debido a que se han redefinido en "variantes de ASCII" como JIS-Roman ). El uso de caracteres directos opcionales reduce el tamaño y mejora la legibilidad humana, pero también aumenta la posibilidad de que se rompan por cosas como puertas de enlace de correo mal diseñadas y pueden requerir un escape adicional cuando se usan en palabras codificadas para campos de encabezado.

El espacio, la tabulación, el retorno de carro y el avance de línea también se pueden representar directamente como bytes ASCII individuales. Sin embargo, si el texto codificado se va a utilizar en un correo electrónico, se debe tener cuidado para garantizar que estos caracteres se utilicen de manera que no requieran una codificación adicional de transferencia de contenido para que sean adecuados para el correo electrónico. El signo más ( +) se puede codificar como +-.

Los demás caracteres deben codificarse en UTF-16 (por lo tanto, U+10000 y superiores se codificarían en dos sustitutos) y luego en Base64 modificado . El comienzo de estos bloques de UTF-16 codificado en Base64 modificado se indica con un +signo. El final se indica con cualquier carácter que no esté en el conjunto Base64 modificado. Si el carácter después del Base64 modificado es un -(guión ASCII -menos ), el decodificador lo consume y la decodificación se reanuda con el siguiente carácter. De lo contrario, la decodificación se reanuda con el carácter después del Base64.

• " Hello, World!" está codificado como " Hello, World+ACE-"
• " 1 + 1 = 2" está codificado como " 1 +- 1 +AD0- 2"
• " £1" se codifica como " +AKM-1". El punto de código Unicode para el signo de almohadilla es U+00A3, que se convierte en Base64 modificado, como se muestra en la tabla siguiente. Quedan dos bits, que se rellenan hasta 0.

En primer lugar, un codificador debe decidir qué caracteres representar directamente en formato ASCII, cuáles +deben escaparse como +-, y cuáles colocar en bloques de caracteres Unicode. El costo de expansión de UTF-7 puede ser alto: por ejemplo, la secuencia de caracteres U+10FFFF U+0077 U+10FFFF tiene 9 bytes en UTF-8, pero 17 bytes en UTF-7. (En el peor de los casos, tratar cada punto de código como una secuencia en sí misma produce la expansión máxima de 5x, por ejemplo, cuando se codifica @@como +AEA-+AEA-.) Cada secuencia Unicode debe codificarse utilizando el siguiente procedimiento, y luego rodearse con los delimitadores apropiados.

Usando la secuencia de caracteres £† (U+00A3 U+2020) como ejemplo:

Primero, los datos codificados deben separarse en fragmentos de texto ASCII simples (incluidos + es seguidos de un guión) y bloques Unicode no vacíos, como se menciona en la sección de descripción. Una vez hecho esto, cada bloque Unicode debe decodificarse con el siguiente procedimiento (usando el resultado del ejemplo de codificación anterior como nuestro ejemplo)

1. Exprese cada código Base64 como la secuencia de bits que representa:
   AKMgIA → 000000 001010 001100 100000 001000 000000
2. Reagrupa el binario en grupos de dieciséis bits, comenzando desde la izquierda:
   000000 001010 001100 100000 001000 000000 → 0000000010100011 0010000000100000 0000
3. Si hay un grupo incompleto al final que contiene solo ceros, deséchelo (si el grupo incompleto contiene algunos unos, el código no es válido):
   0000000010100011 0010000000100000
4. Cada grupo de 16 bits es un número Unicode (UTF-16) de un carácter y puede expresarse de otras formas:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 ₁₀

Una marca de orden de bytes (BOM) es una secuencia de bytes especial opcional que se encuentra al comienzo de un flujo o archivo y que, sin ser datos en sí, indica la codificación utilizada para los datos que siguen; se puede utilizar en ausencia de metadatos que indiquen la codificación. Para un esquema de codificación determinado, es la representación de ese esquema del punto de código Unicode U+FEFF. ^[8]

Aunque normalmente se trata de una secuencia de bytes fija y única, en UTF-7 pueden aparecer cuatro variaciones, porque los dos últimos bits del cuarto byte de la codificación UTF-7 U+FEFFpertenecen al carácter siguiente , lo que da como resultado cuatro posibles patrones de bits y, por lo tanto, cuatro posibles bytes diferentes en la cuarta posición. Consulte la entrada UTF-7 en la tabla de marcas de orden de bytes Unicode . ^[9]

UTF-7 permite múltiples representaciones de la misma cadena de origen. En particular, los caracteres ASCII se pueden representar como parte de bloques Unicode. Por lo tanto, si se utilizan procesos de escape o validación basados ​​en ASCII estándar en cadenas que luego se pueden interpretar como UTF-7, se pueden utilizar bloques Unicode para pasar cadenas maliciosas por encima de ellos. Para mitigar este problema, los sistemas deben realizar la decodificación antes de la validación y deben evitar intentar detectar automáticamente UTF-7.

Las versiones anteriores de Internet Explorer pueden ser engañadas para que interpreten la página como UTF-7. Esto puede usarse para un ataque de secuencias de comandos entre sitios , ya que las marcas <y >pueden codificarse como +ADw-y +AD4-en UTF-7, que la mayoría de los validadores permiten como texto simple. ^[10]

UTF-7 se considera obsoleto, al menos para el software de Microsoft (.NET), y las rutas de código que lo admitían anteriormente se rompieron intencionalmente (para evitar problemas de seguridad) en .NET 5, en 2020. ^[1]

• Comparación de codificaciones Unicode