2.3: Extensión de Códigos

Muchos códigos son diseñados por humanos. A veces, los códigos son increíblemente robustos, simples, fáciles de trabajar y extensibles. A veces son frágiles, arcanos, complejos, y desafían hasta la generalización más simple. A menudo se desarrolla un código simple y práctico para representar un pequeño número de elementos, y su éxito llama la atención y la gente comienza a usarlo fuera de su contexto original, para representar una clase más grande de objetos, para fines no previstos originalmente.

Los códigos generalizados a menudo llevan consigo sesgos involuntarios de su contexto original. A veces los resultados son simplemente divertidos, pero en otros casos tales sesgos hacen que sea difícil trabajar con los códigos.

Un ejemplo de un sesgo razonablemente benigno es el hecho de que ASCII tiene dos caracteres que originalmente estaban destinados a ser ignorados. ASCII comenzó como el patrón de 7 bits de agujeros en cinta de papel, utilizado para transferir información hacia y desde máquinas de teletipo. La cinta originalmente no tenía agujeros (excepto una serie de pequeños agujeros, siempre presentes, para alinear y alimentar la cinta), y viajó a través de un punzón. La cinta podría ser punzonada ya sea desde una transmisión recibida, o bien por un humano escribiendo en un teclado. Los escombros de esta operación de perforación se conocían como “chad”. El líder (la primera parte de la cinta) estaba sin perforar, y por lo tanto representó, en efecto, una serie del carácter 0000000 de longitud indeterminada (0 se representa como sin agujero). Por supuesto, cuando se leyó la cinta se debía ignorar al líder, por lo que por convención el personaje 0000000 se llamaba NUL y fue ignorado. Posteriormente, cuando se utilizó ASCII en computadoras, diferentes sistemas trataron NUL de manera diferente. Unix trata a NUL como el final de una palabra en algunas circunstancias, y este uso interfiere con aplicaciones en las que a los caracteres se les da una interpretación numérica. El otro código ASCII que originalmente se pretendía ignorar es DEL, 1111111. Esta convención fue útil para los mecanógrafos que podían “borrar” un error haciendo una copia de seguridad de la cinta y perforando cada agujero. En contextos modernos, EL suele tratarse como un retroceso destructivo, pero algunos editores de texto en el pasado han usado DEL como un carácter de eliminación hacia adelante, y a veces simplemente se ignora.

Un sesgo mucho más serio que lleva ASCII es el uso de dos caracteres, CR (retorno de carro) y LF (avance de línea), para pasar a una nueva línea de impresión. El mecanismo físico en las máquinas de teletipo tenía hardware separado para mover el papel (en rollo continuo) hacia arriba y reposicionar el elemento de impresión al margen izquierdo. Los ingenieros que diseñaron el código que evolucionó a ASCII seguramente sintieron que estaban haciendo algo bueno al permitir que estas operaciones se llamaran por separado. No podrían haber imaginado el dolor que han dado a generaciones posteriores ya que ASCII se adaptó a situaciones con diferentes herrajes y sin necesidad de mover el punto de impresión como lo piden CR o LF por separado. Diferentes sistemas informáticos hacen las cosas de manera diferente: UNIX usa LF para una nueva línea e ignora CR, Macintoshes (al menos antes de OS X) usa CR e ignora LF, y DOS/Windows requiere ambos. Esta incompatibilidad es una fuente continua, grave de frustración y errores. Por ejemplo, en la transferencia de archivos usando FTP (File Transfer Protocol) CR y LF deben convertirse para que se adapten a la plataforma de destino para archivos de texto, pero no para archivos binarios. Algunos programas FTP defieren el tipo de archivo (texto o binario) de la extensión de archivo (la parte del nombre del archivo siguiente al último período). Otros miran dentro del archivo y cuentan el número de “personajes divertidos”. Otros dependen del aporte humano. Estas técnicas suelen funcionar pero no siempre. Las convenciones de extensión de archivos no se siguen universalmente. Los humanos cometen errores. ¿Y si parte de un archivo es texto y parte binaria?