Convertir EBCDIC a ASCII: siete páginas de códigos

Qué es EBCDIC

EBCDIC es la codificación de caracteres que IBM creó para sus mainframes a principios de los sesenta, y sigue siendo donde vive muchísima información bancaria, de seguros y de administraciones públicas. Si alguna vez has abierto un archivo salido de un mainframe y te has encontrado con un galimatías de aspecto casi legible, EBCDIC suele ser la explicación: los bytes están bien, lo que pasa es que no significan lo que tu editor da por hecho.

Lo primero que hay que saber es que EBCDIC no es una codificación, sino una familia, y sus miembros no se ponen de acuerdo. Esta herramienta trae siete de ellos —los que implementa de verdad una biblioteca estándar de propósito general— y te deja convertir en los dos sentidos mientras te enseña qué bytes de los tuyos leerían distinto los otros seis.

Lo segundo es más raro, y es la razón de que comprobar un rango de letras sea un error de portabilidad y no una cuestión de estilo.

Cómo se usa

1. Elige sentido y página de códigos. El selector de página está siempre a la vista y nunca adivina, porque un conversor que elige por su cuenta es justo el error que esta herramienta enseña. Si no sabes qué página usa un archivo, la tabla de discrepancias de más abajo es la manera de averiguarlo.
2. Pega tus bytes o tu texto. El hexadecimal admite espacios, comas y el prefijo 0x, y lee una tirada larga de dos en dos dígitos. Lo que no sea hexadecimal se enumera en vez de omitirse en silencio.
3. Lee los paneles de abajo. Uno enseña cada byte de tu entrada sobre el que las siete páginas discrepan. Otro recorre el rango de las letras y cuenta lo que hay dentro que no es una letra. Otro te dice si esta página aguanta la ida y vuelta.

Las letras no son consecutivas

En ASCII las minúsculas van del 97 al 122 sin nada en medio, y por eso todo el mundo escribe una comprobación de rango para saber si un carácter es una letra. En EBCDIC esa comprobación está mal, y no por poco.

En la página estadounidense, la a es 0x81 y la z es 0xA9. Eso son cuarenta y un valores de byte para veintiséis letras, así que el rango se lleva por delante quince valores que no son letras. La tirada se rompe dos veces: entre la i y la j el valor salta ocho, y entre la r y la s, nueve. La herramienta dibuja el rango entero de la página que tengas elegida y resalta a los intrusos, para que los cuentes tú.

El motivo es la tarjeta perforada. EBCDIC se diseñó para que el byte de un carácter se leyera directamente de las perforaciones de zona y de dígito de la tarjeta, y una zona nunca daba más de nueve posiciones antes de empezar la siguiente. Las letras se repartieron en grupos de nueve, nueve y ocho, y los huecos son donde acababa cada zona. Una disposición con todo el sentido del mundo para un lector de tarjetas se convirtió, sesenta años después, en una trampa para una comprobación de una línea.

Los dígitos, dicho sea de paso, sí son consecutivos: del 0 al 9 van de 0xF0 a 0xF9 sin cortes. Solo las letras están interrumpidas, y precisamente por eso sobrevive el error: la mitad de lo que recuerdas de la disposición es correcto.

Las páginas discrepan sobre los corchetes, no sobre las letras

Coge las dos páginas latinas más habituales, la estadounidense y la internacional. Difieren en exactamente siete valores de byte de 256, y los siete caracteres implicados son los corchetes, la barra vertical, el signo de exclamación, el circunflejo, el símbolo de centavo y el de negación.

No es una sustitución sino una baraja: los mismos siete caracteres ocupan las mismas siete posiciones de byte en ambas páginas, en otro orden. Todas las letras y todos los dígitos son idénticos. Así que un archivo de prosa viaja entre los dos sistemas sin un rasguño, y uno de código fuente llega con los corchetes convertidos en símbolos de moneda. Por eso el problema se recuerda como un problema de corchetes y no de codificación: el destrozo se concentra justo en los caracteres de los que depende un lenguaje de programación y no toca nada más.

Entre las siete páginas de aquí, solo 150 de los 256 valores de byte significan lo mismo en todas. El panel de discrepancias se limita a propósito a los bytes de tu entrada y no a la tabla entera, porque la pregunta que vale la pena responder es si tu archivo se leería distinto en otro sitio.

Limitaciones honestas

Siete páginas no son todas. IBM ha definido muchísimas más, y las siete de aquí son las que implementa una biblioteca estándar de propósito general, que es lo que permitió generar las tablas desde una fuente en vez de teclearlas. Si tu archivo usa una página que no está en la lista, esta herramienta no puede ayudarte y probar las otras no lo va a arreglar.

La ida y vuelta no es universal, y la herramienta lo dice por página en lugar de prometerlo en bloque. Cinco de las siete aguantan descodificar y volver a codificar los 256 valores. La página hebrea deja treinta y ocho posiciones de byte sin asignar, así que esas no pueden volver desde el texto: nunca hubo nada ahí. La griega es distinta y más sutil: asigna las 256, pero siete de sus valores de byte comparten un mismo carácter de relleno, de modo que solo uno del grupo puede volver a codificarse y los otros seis se pierden. Dos defectos distintos que en un resumen parecen el mismo, y por eso se informan por separado.

Por último, tu navegador no puede hacer nada de esto por su cuenta. La norma de codificaciones de la web enumera las que un navegador debe admitir y dice que no debe admitir ninguna otra; EBCDIC no está en esa lista y no lo va a estar. Por eso las tablas viajan con la página en vez de dejárselas a un descodificador integrado, y es la misma norma de la que trata la lista de codificaciones de caracteres de este sitio, vista desde el otro lado.

¿Por qué es gratis?

Siete tablas de 256 entradas ocupan unos cinco kilobytes una vez comprimidas, y tu navegador hace la conversión mientras escribes. Ningún servidor ve tus datos, así que no hay nada que medir ni ninguna cuenta que crear.

No se sube nada. Lo que pegues se queda en esta pestaña.