Resumen

  • RFC 1468 documentó un perfil de conmutación de siete bits: el texto empezaba en ASCII, cuatro secuencias permitidas seleccionaban estados de uno o dos bytes, y una línea con JIS X 0208 debía abandonar ese estado antes de CRLF.
  • El nombre ISO-2022-JP elegía una regla común de decodificación; no demostraba que el emisor la hubiera cumplido, que los relés conservaran los escapes, que dos programas reconstruyeran iguales caracteres ni que el lector viera los mismos glifos.

El signo > que un programa añadía al citar un mensaje parecía un detalle editorial. Para un flujo con estado podía convertirse en una prueba de arquitectura.

En RFC 1468, publicado en junio de 1993, las líneas que contenían caracteres japoneses de dos bytes debían volver a ASCII o al conjunto romano JIS X 0201 antes de CRLF. Así, un cliente podía insertar el marcador de cita al comienzo de la línea siguiente sin depositarlo dentro de un carácter incompleto. La regla también acotaba el daño de perder el estado: la interpretación de una línea no tenía que depender indefinidamente de una señal enviada muchas líneas atrás.

Ese pequeño requisito resume el logro de ISO-2022-JP. No creó un correo capaz de transportar cualquier repertorio japonés. Definió una máquina limitada que cabía en los caminos de siete bits y podía reiniciarse donde las herramientas de correo ya reconocían una frontera.

Los caracteres no estaban escritos en cada byte

El flujo comenzaba en ASCII. ESC $ B cambiaba a JIS X 0208-1983 y ESC $ @ a la edición de 1978. En ambos casos, cada carácter posterior ocupaba dos bytes dentro del rango permitido. ESC ( B devolvía la lectura a ASCII; ESC ( J activaba JIS X 0201 Roman.

El decodificador necesitaba conservar el último designador. Un valor no se explicaba por sí mismo: la misma sucesión sólo era una pareja japonesa si una transición anterior había creado ese contexto. Por eso hablar de una simple «tabla» empobrece el mecanismo. La tabla determina correspondencias dentro de un estado; las secuencias de escape determinan qué tabla gobierna ahora.

JIS X 0201 Roman tampoco era un alias perfecto de ASCII. Dos posiciones cambiaban: barra inversa por yen y tilde por macrón. Un terminal podía hacer invisible la diferencia mediante su fuente, pero el flujo seguía declarando estados distintos. El conjunto Kana de JIS X 0201 quedaba fuera del perfil. La palabra «JP» no autorizaba al emisor a escoger cualquier codificación local que contuviera japonés.

La sintaxis formal protegía esa lógica al excluir ESC, SI y SO de los caracteres ordinarios de un byte. Eran instrumentos de control, no texto disponible para una interpretación oportunista. La legibilidad dependía de que los participantes conservaran esa separación.

Volver antes del salto de línea

Una línea que entraba en JIS X 0208 debía salir antes de CRLF. La línea siguiente heredaba sólo el estado de un byte elegido al final de la anterior, y todo el mensaje debía concluir en ASCII.

No era un borrado universal. El retorno podía hacerse a JIS X 0201 Roman y mantener su diferencia respecto de ASCII. Tampoco decía qué debía hacer un programa ante un escape incompleto. Sin embargo, impedía que el estado de dos bytes atravesara una frontera de línea de manera silenciosa. Un lector aleatorio, un paginador o una herramienta de citas disponían de un punto próximo desde el cual reconstruir.

El coste era repetición. Un mensaje con japonés en muchas líneas insertaba más secuencias que uno con un único bloque continuo. El beneficio era localización del contexto. En lugar de exigir que toda pieza intermedia comprendiera el repertorio, el perfil hacía que la representación fuera transportable y que el endpoint pudiera recuperar el estado con una historia corta.

El diseño no centralizó la decisión futura. Un sistema podía aceptar el perfil, rechazarlo o transformarlo bajo sus propias reglas. Pero no podía afirmar compatibilidad mientras ignoraba las transiciones que le daban significado.

Una ruta de siete bits todavía podía romperlo

El encabezado propuesto era Content-Type: text/plain; charset=iso-2022-jp. Como todos los valores estaban dentro de siete bits, no hacía falta una codificación de transferencia adicional sólo para cruzar el SMTP de la época.

El límite resuelto era físico y sintáctico: no aparecía el bit alto. Nada de eso impedía que una pasarela eliminara ESC, partiera una pareja, cambiara un final de línea o sustituyera un designador. El archivo resultante seguiría compuesto por siete bits y sería otro texto, o ninguno.

El RFC advertía que Base64 o quoted-printable harían el mensaje ilegible para el software JUNET contemporáneo. La advertencia describe el despliegue de 1993. Una capa reversible no destruye necesariamente el contenido; fracasa si el programa que realmente recibe no sabe retirarla antes de aplicar el charset. La especificación disponible y la combinación de código cargada en los equipos eran hechos distintos.

Más adelante, RFC 2046 consolidó el sentido general del parámetro charset en texto MIME: el cuerpo se compone de caracteres del conjunto nombrado y continúa sujeto a reglas de línea. El encabezado permite escoger el contrato correcto. No ofrece recibo de que cada etapa lo haya ejecutado.

El relé debía preservar incluso lo que no veía

RFC 1468 señaló que algunos sistemas mostraban como equivalentes ESC ( B y ESC ( J, o las designaciones de 1978 y 1983. Aun así, prohibió a los relés alterar esas secuencias.

La pantalla local no podía hablar por el siguiente destinatario. Una fuente distinta podía revelar yen donde antes aparecía barra inversa. Una herramienta de conversión podía tratar de forma diferente las revisiones de JIS X 0208. Un archivo futuro podía necesitar distinguir el objeto recibido de una representación normalizada. La falta de diferencia visible en un punto no confería autoridad para eliminarla del camino.

Al conservar los bytes se conservaba también la atribución de errores. Si el render final discrepaba, el original permitía preguntar si falló el emisor, la custodia, el decodificador o la fuente. Cuando un relé reescribía «para ayudar», esas capas quedaban mezcladas. Podía producir una vista más limpia y una prueba peor.

La custodia exacta no garantizaba verdad ni autenticidad. Un mensaje perfectamente preservado podía estar mal formado o mentir. El deber del relé era más estrecho: no convertir su lectura local en una edición irreversible del objeto ajeno.

La longitud tenía tres medidas

El documento aconsejaba unas 75 u 80 columnas de pantalla. Un carácter JIS X 0208 ocupaba dos bytes y dos columnas en su modelo; un escape consumía bytes y ninguna columna. El software no debía cortar una pareja para ajustar la presentación.

Offset, carácter y columna eran coordenadas diferentes. En ASCII podían avanzar juntas. Después del primer designador dejaban de hacerlo. Un envoltorio que contara bytes podía separar un carácter. Otro que eliminara controles invisibles podía borrar el estado. Uno que conservara caracteres pero sustituyera la fuente podía cambiar el aspecto sin tocar la decodificación.

Por eso el hash del cuerpo y la captura de pantalla responden preguntas distintas. El primero fija una representación. La segunda fija un resultado gráfico en un entorno. Entre ambos hay decisiones ejecutables que deben poder auditarse.

Un registro no es un decodificador

RFC 2978 definió un charset como el método que convierte una secuencia de octetos en caracteres. Incluyó expresamente técnicas de conmutación ISO 2022 y exigió que la definición asociada al nombre especificara por completo el mapeo. El término ya no podía entenderse como una mera bolsa de símbolos.

El registro de juegos de caracteres de IANA identifica ISO-2022-JP con el número 39 y enlaza RFC 1468 y RFC 2237. También guarda ISO-2022-JP-2 por separado. Esa coordinación evita colisiones nominales. No examina cada cuerpo, no certifica bibliotecas y no mide adopción.

El registro editorial de RFC 1468 dice Informational. Es una descripción de estatus, no una encuesta de uso. Del mismo modo, aparecer en IANA prueba que existe un nombre definido, no que una instancia concreta lo merezca. Publicación, registro y ejecución deben conservar sus propios verbos.

Los cambios grandes recibieron nombres nuevos

En diciembre de 1993, RFC 1554 presentó el ISO-2022-JP-2 experimental y multilingüe. Añadió designaciones para repertorios chino, coreano, japonés suplementario, latino y griego, además de un segundo ámbito de designación que se limpiaba al comenzar una línea. No fingió que el decodificador más amplio fuera idéntico al anterior.

RFC 2237 creó en 1997 ISO-2022-JP-1 para añadir JIS X 0212 mediante ESC $ ( D. Conservó el final ASCII y exigió usar ISO-2022-JP cuando no aparecieran caracteres del repertorio suplementario.

El nombre nuevo hacía visible una nueva obligación. El emisor podía pedir más capacidad; el receptor antiguo podía negarse sin adivinar. La innovación no necesitaba borrar el significado estable de los mensajes ya archivados.

El documento no llegó hasta los ojos del lector

Las fuentes prueban la gramática esperada, no el resultado de un caso individual. Una reconstrucción necesita conservar por separado encabezado MIME, bytes originales, transiciones, transformaciones de relés, versión y política del decodificador, secuencia de caracteres, fuente y render.

La doctrina publicada por Heng Lu ayuda a mantener el límite. Minimum Initial Specification explica la utilidad de un núcleo común pequeño frente a decisiones locales. Running-Code Primacy impide confundir el texto publicado con su adopción efectiva. On Reality Layers obliga a no fundir etiqueta, representación, render y conducta humana.

ISO-2022-JP no eliminó esas capas. Las ordenó lo suficiente para que un mensaje pudiera atravesarlas sin pedir a la red que entendiera su contenido. El nombre indicaba qué máquina usar; los escapes demostraban qué estado había en cada punto; sólo la ejecución producía los caracteres.