UTF-7 (del formato de transformación Unicode de 7 bits en inglés - " Formato de transformación Unicode, 7 bits") Formato de codificación de texto Unicode con una longitud variable de palabras de caracteres en una secuencia de caracteres ASCII. Originalmente destinado a codificar texto Unicode en mensajes de correo electrónico de Internet, que era más eficiente que combinar UTF-8 con cotización imprimible.
El estándar de formato de correo electrónico MIME actual prohíbe la codificación de encabezados utilizando valores de byte por encima del rango ASCII. Aunque MIME permite codificar el cuerpo del mensaje en diferentes juegos de caracteres (más anchos que ASCII), la infraestructura de transmisión subyacente (SMTP, el principal estándar de transmisión de correo electrónico) aún no garantiza la pureza de 8 bits. Por tanto, en caso de duda, es necesario utilizar una codificación no trivial del contenido transmitido. Desafortunadamente, Base64 tiene la desventaja de que ni siquiera los clientes que no son MIME pueden leer los caracteres US-ASCII. Por otro lado, UTF-8 combinado con quoted-printable es un formato muy ineficiente, que requiere de 6 a 9 bytes para caracteres que no sean ASCII de BMP (Basic Multilingual Plane) y 12 bytes para caracteres que no sean BMP.
Si se siguen ciertas reglas durante la codificación, el texto codificado en UTF-7 se puede enviar por correo electrónico sin utilizar la codificación de transferencia MIME subyacente, pero se debe marcar explícitamente como un conjunto de caracteres de texto. Además, si se usan en encabezados de correo electrónico como "Asunto: ", UTF-7 debe estar contenido en las palabras codificadas con MIME que identifican el juego de caracteres. Dado que las palabras codificadas usan conjuntos imprimibles entre comillas o Base64, UTF-7 se diseñó con la opción de no usar el signo igual = como carácter de escape para evitar saltos dobles cuando se combina con imprimible entre comillas (o su variante, en RFC 2047/1522 encabezados de codificación ?Q?).
UTF-7, por regla general, no se usa en su forma nativa en las aplicaciones, ya que es muy inconveniente para el procesamiento. Aunque UTF-7 tiene prioridad sobre las combinaciones de UTF-8 con quoted-printable o Base64, el ahora desaparecido Internet Mail Consortium ha recomendado no usar la codificación UTF-7. [una]
8BITMIME también se introdujo para reducir la necesidad de codificar los cuerpos de los mensajes en formato de 7 bits.
El protocolo de correo electrónico IMAP utiliza actualmente una forma modificada de UTF-7 (mUTF-7, UTF-7 IMAP) para buscar nombres de buzones [2] .
UTF-7 se propuso originalmente como un protocolo experimental en RFC 1642 "Un formato de transformación seguro para correo de Unicode". Este RFC está obsoleto desde el RFC 2152 , un RFC informativo que nunca fue un estándar. Como se establece en RFC 2152 , "El RFC no define un estándar de Internet de ningún tipo". Independientemente, RFC 2152 se cita como la definición de UTF-7 en la lista de codificación de IANA. Además, UTF-7 no es un estándar Unicode. Unicode Standard 5.0 solo enumera UTF-8, UTF-16 y UTF-32. También existe 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. Forman un grupo de los llamados "caracteres directos" de 52 letras latinas, 10 números y 9 signos de puntuación: ' ( ) , - . / : ?. Los caracteres directos son seguros cuando se muestran literalmente. El otro grupo principal, conocido como "caracteres directos opcionales", contiene todos los demás caracteres imprimibles del rango U+0020—U+007Eexcepto el ~ \ +espacio. El uso de caracteres de reenvío opcionales reduce el tamaño y mejora la legibilidad, pero también aumenta la posibilidad de que la información se corrompa por factores tales como puertas de enlace de correo mal diseñadas y puede requerir un escape adicional cuando se usan caracteres de reenvío opcionales en palabras codificadas para campos de encabezado.
El espacio, el tabulador, el retorno de carro y el salto de línea también se pueden representar directamente como bytes ASCII individuales. Sin embargo, si se va a utilizar texto codificado en el correo electrónico, se debe tener cuidado para asegurarse de que estos caracteres no requieran una codificación adicional del contenido transmitido adecuado para el correo electrónico. El signo más +se puede codificar como +-.
Otros caracteres deben codificarse primero en UTF-16 (los caracteres con códigos de U+10000y superiores se codificarán en sustitutos) big-endian (bits altos al final) y luego modificarse a códigos Base64. El comienzo de dichos bloques de caracteres codificados en UTF-16 y modificados en Base64 se indica con +. El final de los bloques se indica mediante cualquier carácter que no forme parte del conjunto de modificadores de Base64. Si el carácter después de ser modificado a Base64 es -(guion-menos ASCII), el decodificador lo omite y la decodificación se reanuda en el siguiente carácter. De lo contrario, la decodificación se reanuda con un carácter después de Base64.
8BITMIME también se introdujo para reducir la necesidad de codificar los cuerpos de los mensajes en formato de 7 bits.
| hexadecimal
el código |
0 | 0 | A | 3 | ||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| código binario | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | una | 0 | una | 0 | 0 | 0 | una | una | 0 | 0 |
| Índices | 0 | diez | 12 | |||||||||||||||
| Código Base64 | A | k | METRO | |||||||||||||||
En primer lugar, el codificador debe determinar qué caracteres se pueden representar directamente en formato ASCII, además del signo más +, que se codifica como +-, y qué caracteres se deben marcar como bloques de caracteres Unicode. Un codificador simple puede codificar directamente todos los caracteres que considere seguros para la codificación directa. Sin embargo, es una buena idea finalizar una secuencia Unicode con un carácter directamente en ASCII y luego comenzar otra secuencia Unicode que contenga de 3 a 3⅔ bytes. Esto es más que los 2⅔ bytes necesarios para representar un carácter como parte de una secuencia Unicode.
Cada secuencia de caracteres Unicode debe codificarse mediante el siguiente procedimiento y luego rodearse de los delimitadores apropiados. Por ejemplo, usamos la secuencia de símbolos £† ( U+00A3 U+2020):
0x00A3 → 0000 0000 1010 0011
En primer lugar, los datos codificados deben separarse en fragmentos de texto ASCII sin formato (incluidos los signos más seguidos de un guión +-) y bloques Unicode no vacíos, como se especifica en la sección de descripción. Una vez hecho esto, cada bloque Unicode debe decodificarse con el siguiente procedimiento (utilizando el resultado del ejemplo de codificación anterior):
Un marcador Unicode (a menudo denominado "BOM" - marca de orden de bytes) es una secuencia especial opcional de bytes al comienzo de una secuencia o archivo que, aunque no son datos en sí mismos, especifica la codificación utilizada para los datos posteriores; el marcador se usa cuando no hay metadatos que indiquen la codificación. Para un esquema de codificación dado, la firma es la representación del esquema en un punto de código Unicode U+FEFF, el llamado carácter BOM.
Mientras que un marcador Unicode es generalmente una única secuencia fija de bytes, la especificidad de UTF-7 presenta 5 variaciones: los últimos 2 bits del 4.º byte de la codificación UTF-7 U+FEFFse refieren al siguiente carácter, lo que da como resultado 4 posibles patrones de bits y, por lo tanto, , 4 bytes posibles diferentes en la 4ª posición. La quinta variación es necesaria para desambiguar el caso en el que ningún personaje sigue al marcador. Consulte Determinación de la codificación por marcador de secuencia de bytes .
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 algoritmos de autenticación o escape estándar basados en ASCII para cadenas que luego pueden interpretarse como UTF-7, entonces los bloques Unicode pueden usarse para inyectar cadenas maliciosas que pasan libremente a través de la validación. Para solucionar este problema, los sistemas de validación deben realizar la decodificación antes de la validación y no deben 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 usar para atacar secuencias de comandos entre sitios, ya que los caracteres de servicio <se >pueden codificar como +ADw-en +AD4-UTF-7, que la mayoría de los validadores pasan como texto sin formato.