UTF-7 - UTF-7

UTF-7

Idioma (s)	Internacional
Estándar	RFC  2152
Clasificación	Formato de transformación Unicode , armadura ASCII , codificación de ancho variable , codificación con estado
Transforma / Codifica	Unicode
Precedido por	HZ-GB-2312
Sucesor	UTF-8 sobre 8BITMIME
v t mi

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 una secuencia de caracteres ASCII . Originalmente, estaba destinado a 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 es hacia / desde UTF-16, entonces puede (y probablemente lo hace) 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) lo admiten.

UTF-7 nunca ha sido un estándar oficial del Consorcio Unicode . Se sabe que tiene problemas de seguridad, por lo que se ha cambiado el software para deshabilitar su uso. Está prohibido en HTML 5 .

Motivación

MIME , el estándar moderno de formato 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), todavía no se garantiza que la infraestructura de transmisión subyacente ( SMTP , el principal estándar de transferencia de correo electrónico) sea limpia 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 US-ASCII sean ilegibles en clientes que no sean MIME. Por otro lado, UTF-8 combinado con quoted-printable produce un formato de tamaño muy ineficiente que requiere de 6 a 9 bytes para caracteres no ASCII del BMP y 12 bytes para caracteres fuera del BMP.

Siempre que se sigan 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 dentro de encabezados de correo electrónico como "Asunto:", UTF-7 debe estar contenido en palabras codificadas MIME que identifiquen el juego de caracteres. Dado que las palabras codificadas fuerzan el 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, el RFC 2047/1522 ? Q ?, codificación de encabezados).

UTF-7 generalmente no se usa como una representación nativa dentro de 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 desaparecido Internet Mail Consortium recomendó no usarlo.

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

Actualmente se utiliza una forma modificada de UTF-7 (a veces denominada 'mUTF-7') en el protocolo de recuperación de correo electrónico IMAP para los nombres de los buzones de correo.

Descripción

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

Algunos caracteres se pueden representar directamente como bytes ASCII individuales. El primer grupo es conocido como "caracteres directos" y contiene 62 caracteres alfanuméricos y 9 símbolos: ' ( ) , - . / : ?. Los personajes directos son seguros para incluirlos literalmente. 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 el espacio (los caracteres \y ~se excluyen debido a que se redefinieron 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 rotura por cosas como puertas de enlace de correo mal diseñadas y puede requerir un escape adicional cuando se usa 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 el correo electrónico, se debe tener cuidado para asegurarse de que estos caracteres se utilicen de manera que no requieran más codificación de transferencia de contenido para ser adecuados para el correo electrónico. El signo más ( +) se puede codificar como +-.

Otros caracteres deben codificarse en UTF-16 (por lo tanto, U + 10000 y superior se codificarían en dos sustitutos) y luego en Base64 modificada . El inicio de estos bloques de UTF-16 codificado en Base64 modificado se indica mediante un +signo. El final está indicado por cualquier carácter que no esté en el conjunto Base64 modificado. Si el carácter después de la Base64 modificada es un -(ASCII guión 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 de base64.

Ejemplos de

• " Hello, World!" está codificado como " Hello, World+ACE-"
• " 1 + 1 = 2" está codificado como " 1 +- 1 +AD0- 2"
• " £1" está codificado 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 siguiente tabla. Quedan dos bits, que se rellenan a 0.

Dígito hexadecimal	0				0				A				3
Patrón de bits	0	0	0	0	0	0	0	0	1	0	1	0	0	0	1	1	0	0
Índice	0						10						12
Codificado en Base64	A						K						METRO

Algoritmo para codificar y decodificar

Codificación

En primer lugar, un codificador debe decidir qué caracteres representar directamente en forma ASCII, cuáles +deben ser escapados +-y cuáles colocar en bloques de caracteres Unicode. Un codificador simple puede codificar todos los caracteres que considere seguros para la codificación directa directamente. Sin embargo, el costo de finalizar una secuencia Unicode, generar un solo carácter directamente en ASCII y luego comenzar otra secuencia Unicode es de 3 a 3+2 ⁄ 3 bytes. Esto es más que el 2+Se necesitan 2 ⁄ 3 bytes para representar el carácter como parte de una secuencia Unicode. Cada secuencia Unicode debe codificarse mediante el siguiente procedimiento, luego rodeada por los delimitadores apropiados.

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

Descodificación

Primero, los datos codificados deben separarse en fragmentos de texto ASCII sin formato (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. Reagrupe el binario en grupos de dieciséis bits, comenzando por 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 alguno, 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 se puede expresar de otras formas:
   0000 0000 1010 0011 ≡ 0x00A3 ≡ 163 ₁₀

Marca de orden de bytes

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

Si bien es típicamente una secuencia de un solo byte fijo, en UTF-7 pueden aparecer cuatro variaciones, porque los últimos 2 bits del cuarto byte de la codificación UTF-7 U+FEFFpertenecen al siguiente carácter, lo que da como resultado 4 patrones de bits posibles y, por lo tanto, 4 diferentes bytes posibles en la 4ª posición. Consulte la entrada UTF-7 en la tabla de marcas de orden de bytes Unicode .

Seguridad

UTF-7 permite múltiples representaciones de la misma cadena fuente. En particular, los caracteres ASCII se pueden representar como parte de bloques Unicode. Como tal, si se utilizan procesos de validación o escape basados ​​en ASCII estándar en cadenas que luego se pueden interpretar como UTF-7, entonces se pueden usar bloques Unicode para deslizar cadenas maliciosas más allá de ellas. 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.

Se puede engañar a las versiones anteriores de Internet Explorer para que interpreten la página como UTF-7. Esto se puede utilizar para un ataque de secuencias de comandos entre sitios , ya que las marcas <y >se pueden codificar como +ADw-y +AD4-en UTF-7, que la mayoría de los validadores dejan pasar como texto simple.

UTF-7 se considera obsoleto, al menos para el software de Microsoft (.NET), con rutas de código que antes lo admitían intencionalmente roto (para evitar problemas de seguridad) en .NET 5, en 2020.

Referencias

Ver también

• Comparación de codificaciones Unicode