Resumen

  • El RFC 1843, de agosto de 1995, presentó HZ como formato de siete bits para mezclar ASCII y chino GB2312. ~{ entraba en modo GB, ~} regresaba a ASCII y ~~ imprimía una virgulilla corriente.
  • El decodificador básico recorría un flujo de bytes sin límite de línea. El documento recomendaba por separado que el codificador produjera líneas físicas de menos de 80 caracteres para herramientas como more, cerrando el modo GB antes de continuar el texto tras el salto.

Un signo pequeño vigilaba el cambio de idioma

En un entorno pensado para ASCII, un byte imprimible ya tenía un aspecto familiar. El chino necesitaba dos bytes por carácter en los códigos de la época, y los ordenadores no siempre utilizaban el mismo código interno. Fung Fung Lee propuso en HZ llevar texto chino y ASCII mezclado por vías de siete bits, como el correo electrónico, tomando GB2312 como repertorio común. El RFC apareció en 1995. Su resumen, sin embargo, dice que el contenido coincidía con un artículo de Lee escrito en septiembre de 1989. La idea había hecho parte del viaje antes de recibir número de RFC.

El funcionamiento tenía dos modos. El punto de partida era ASCII, donde casi todo carácter seguía leyéndose tal cual. La virgulilla abría una pequeña gramática: ~~ significaba la virgulilla visible; ~{ cambiaba a GB; una virgulilla seguida inmediatamente de salto de línea se consumía como continuación. En modo GB se leían parejas de bytes hasta que ~} devolvía al decodificador al ASCII. Un byte impreso en la cinta podía pertenecer a una letra corriente o a medio carácter chino; el modo activo decidía qué lectura correspondía.

El valor de la virgulilla estaba cuidadosamente elegido. En el RFC, el primer byte de un código GB ocupa el intervalo hexadecimal $21–$77 y el segundo $21–$7E. El ASCII gráfico se superpone a esos valores. La virgulilla es $7E, fuera del intervalo permitido para el primer byte GB. Por eso podía avisar del cambio con una señal reconocible, sin confundirse con el comienzo de un carácter chino válido. Una tecla del teclado hacía de guardagujas ferroviario.

Esa solución conservaba a la vista la parte inglesa. Salvo las virgulillas que debían escribirse dos veces, el ASCII viajaba como ASCII. Un archivo que contuviera solo texto ASCII y ninguna virgulilla tendría precisamente el aspecto de un archivo corriente. En un mismo párrafo podía aparecer una frase en inglés, una secuencia en chino y otra vez inglés. HZ estaba pensado para esa mezcla libre. El lector recordaba el modo actual y aplicaba la gramática del siguiente byte.

La línea física era otro asunto. ~ seguido de un salto de línea desaparecía del resultado decodificado y permitía dividir una línea larga sin añadir un salto al texto final. El RFC 1843 explicaba que el decodificador básico ni siquiera necesitaba pensar en líneas: un archivo completo podía ser una sola línea, o carecer de saltos. Le bastaba el modo presente y mirar como máximo un carácter por delante. Esa era la regla común para reconstruir el contenido.

Los usuarios, en cambio, leían con paginadores y terminales de anchura limitada. Lee recomendaba que un codificador mantuviera las líneas físicas por debajo de 80 caracteres para facilitar el uso de herramientas Unix como more. Si el tramo chino llegaba al borde, se cerraba GB con ~}, se añadía la continuación formada por virgulilla y salto de línea, y se abría GB de nuevo con ~{ al empezar la siguiente línea física. El archivo gastaba unos bytes más; el texto recuperado seguía seguido. Los ejemplos del RFC presentaban varias disposiciones de bytes que daban el mismo resultado tras decodificar.

El documento llamaba a esa elección un estilo de codificación encima del formato. Una persona podía preferir líneas cortas para un paginador; otra podía conservar una línea larga para otra herramienta. Sus archivos obedecían la misma gramática HZ y los leía el mismo decodificador. Lee también señalaba que, con el modo actual conocido, era fácil recorrer el flujo hacia atrás, algo útil para un emulador de terminal que debiera atender la tecla de retroceso. El formato buscaba servir tanto al intercambio como a la edición en vivo.

El RFC 1922 de 1996 abordó los mensajes chinos con las reglas distintas de ISO-2022-CN, entre ellas designaciones y retornos asociados a la línea. La aportación concreta de HZ estaba en su cambio de dos modos mediante virgulilla y en la libertad de escoger cómo doblar las líneas sin rehacer el lector común. Era una puerta estrecha, sí. Precisamente por eso convenía que el portero pidiera pocas instrucciones.