Resumen

  • RFC 2152 usó + para abrir Modified Base64 sin relleno =, sobre cantidades Unicode de 16 bits en orden de byte más significativo primero; la secuencia terminaba ante un carácter externo al alfabeto y nunca podía cruzar un salto de línea.
  • La gramática permitía rutas diferentes al mismo texto. Los signos del Set O podían ir directos pese al riesgo de pasarela y cualquier secuencia Unicode podía desplazarse, de modo que decodificar no reconstruía necesariamente los bytes originales.

Una auditoría de migración puede empezar por el final equivocado. El buscador encuentra los asuntos antiguos, el lector muestra palabras reconocibles y el decodificador no informa errores. Si nadie retuvo los objetos fuente, esos resultados ya no revelan si una pasarela cambió finales de línea, volvió a codificar un signo opcional o sustituyó una representación legal por otra.

David Goldsmith y Mark Davis publicaron RFC 2152 en mayo de 1997 como documento Informational y reemplazo de RFC 1642. No era un Internet Standard. Su blanco era el correo US-ASCII de siete bits. Combinar UTF-8 con otra codificación de transporte MIME podía imponer dos transformaciones y ampliar mucho el texto no ASCII. UTF-7 produjo únicamente octetos ASCII y dejó a la vista los tramos que ya pertenecían a ese repertorio.

La propia RFC acotó la solución: debía usarse normalmente sólo en transportes de siete bits, como el correo; en otros contextos se preferían Unicode directo o UTF-8.

La puntuación abrió una decisión

El Set D reunió letras, dígitos y nueve signos para codificación directa, dejando fuera + y =. El Set O añadió otros signos que podían enviarse directamente, pero con una advertencia: varios eran ilegales en cabeceras o no atravesaban correctamente ciertas pasarelas. La barra inversa y la virgulilla quedaron fuera porque variantes de ASCII solían redefinirlas.

El apéndice A convirtió esa cautela en evidencia. Presentó dos versiones del mismo texto chino: una con signos opcionales del Set O que podía fallar en algunas pasarelas y otra sin ellos. La forma más legible no era necesariamente la más preservable.

Un signo más cambió el estado

El carácter + iniciaba una zona cuyos caracteres pertenecían al alfabeto Base64 de RFC 2045, sin el relleno =. Un carácter ajeno al Set B la cerraba. Si ese terminador era , se absorbía; +- representaba un más literal. Un más seguido de algo que no fuera Set B ni guion era una secuencia mal formada.

Antes de esa transformación, las cantidades Unicode de 16 bits se serializaban con el octeto más significativo primero. Las dos mitades de un par sustituto UTF-16 se trataban como cantidades separadas. Un número impar de octetos era inválido; los bits de cierre incompletos se descartaban sólo si eran cero.

Estas condiciones hacían verificable la sintaxis. No atestiguaban la procedencia. El ejemplo Hi Mom +Jjo-! devuelve una cara sonriente cuando la entrada está íntegra, pero no dice si el emisor original escogió esa representación, qué intermediario la tocó o qué diseño visual vio el autor.

La línea cerraba el canal

Una secuencia desplazada terminaba siempre al final de una línea y no podía cruzarlo. La RFC exigía, por tanto, cortar líneas antes de codificar o hacer ambas tareas conjuntamente; si la línea resultante era demasiado larga, debía utilizarse otro content-transfer encoding MIME.

También aconsejaba líneas cortas con CRLF SMTP y convertir los separadores Unicode de línea y párrafo para que sistemas antiguos pudieran leer mejor el mensaje. Esa adaptación podía ser correcta y cambiar, a la vez, la secuencia original. Una normalización operativa no equivale a custodia byte a byte.

Un resultado Unicode no conserva todas las causas

La regla 2 permitía desplazar cualquier secuencia Unicode, mientras que las reglas 1 y 3 dejaban ciertos caracteres en directo. Por ello, flujos distintos podían decodificarse como la misma secuencia. El decodificador cumplía su función aunque eliminara la historia de esa elección.

La aceptación debe separar cuatro pruebas: hash y finales de línea del objeto bruto; validez estricta de la gramática UTF-7; unidades Unicode obtenidas; y representación en el cliente. Si interesan firmas, litigios o reconstrucción de incidentes, el objeto original debe sobrevivir al texto derivado.

IANA registra aún UTF-7, MIBenum 1012 y csUTF7, con RFC 2152 como referencia. Es una prueba registral, no de adopción o seguridad. UTF-7-IMAP es otra codificación, reservada a nombres de buzones IMAP y desaconsejada fuera de ese uso; no puede mezclarse con el contrato MIME.

RFC 2152 no discutió cuestiones de seguridad. Orientación Unicode posterior explicó riesgos cuando componentes comparan o transforman texto de forma desigual, aunque hoy advierte que UTR 36 está estabilizado y algunas recomendaciones fueron superadas. Esto limita lo que puede afirmarse, sin convertir una historia de formato en encuesta de productos.

Dos erratas están verificadas: el valor 96 corresponde al acento grave y faltaba una palabra en la frase sobre el fin de línea. Otra propuesta fue rechazada. La condición de cada registro importa más que el total.

El principio de especificación mínima de Heng Lu permite leer UTF-7 sin exagerarlo: una gramática común resuelve sólo la coordinación que necesita. La primacía del código exige medir la pasarela ejecutada; las capas de realidad impiden confundir una etiqueta o una superficie legible con el resultado conservado.

Fuentes