Converter EBCDIC para ASCII: sete páginas de código

O que é EBCDIC

EBCDIC é a codificação de caracteres que a IBM criou para seus mainframes no começo dos anos sessenta, e continua sendo onde vive muitíssima informação bancária, de seguros e de órgãos públicos. Se você já abriu um arquivo vindo de um mainframe e encontrou uma sopa de letrinhas quase legível, EBCDIC costuma ser a explicação: os bytes estão certos, só não significam o que o seu editor supõe.

A primeira coisa a saber é que EBCDIC não é uma codificação, e sim uma família — e seus membros não concordam entre si. Esta ferramenta traz sete deles, os que uma biblioteca padrão de propósito geral realmente implementa, e deixa você converter nos dois sentidos enquanto mostra quais dos seus bytes as outras seis leriam diferente.

A segunda é mais estranha, e é o motivo de testar um intervalo de letras ser um bug de portabilidade e não questão de estilo.

Como usar

1. Escolha o sentido e a página de código. O seletor de página fica sempre visível e nunca adivinha, porque um conversor que escolhe sozinho é justamente o erro que esta ferramenta mostra. Se você não sabe qual página um arquivo usa, a tabela de divergências abaixo é como descobrir.
2. Cole seus bytes ou seu texto. O hexadecimal aceita espaços, vírgulas e o prefixo 0x, e lê uma sequência longa de dois em dois dígitos. O que não for hexadecimal é listado em vez de ignorado em silêncio.
3. Leia os painéis de baixo. Um mostra cada byte da sua entrada sobre o qual as sete páginas divergem. Outro percorre o intervalo das letras e conta o que há ali dentro que não é letra. Outro diz se esta página aguenta a ida e volta.

As letras não são consecutivas

No ASCII as minúsculas vão de 97 a 122 sem nada no meio, e é por isso que todo mundo escreve um teste de intervalo para saber se um caractere é letra. No EBCDIC esse teste está errado, e não por pouco.

Na página americana, o a é 0x81 e o z é 0xA9. Isso são quarenta e um valores de byte para vinte e seis letras, então o intervalo abocanha quinze valores que não são letras. A sequência se quebra duas vezes: entre i e j o valor pula oito, e entre r e s, nove. A ferramenta desenha o intervalo inteiro da página que você escolheu e destaca os intrusos, para você contar sozinho.

O motivo é o cartão perfurado. O EBCDIC foi desenhado para que o byte de um caractere fosse lido direto das perfurações de zona e de dígito do cartão, e uma zona nunca dava mais de nove posições antes de começar a seguinte. As letras foram distribuídas em grupos de nove, nove e oito, e os buracos são onde cada zona terminava. Um arranjo perfeitamente sensato para uma leitora de cartões virou, sessenta anos depois, uma armadilha para um teste de uma linha.

Os dígitos, diga-se, são consecutivos: de 0 a 9 vão de 0xF0 a 0xF9 sem cortes. Só as letras estão interrompidas, e é exatamente por isso que o erro sobrevive — metade do que você lembra do arranjo está certa.

As páginas divergem sobre os colchetes, não sobre as letras

Pegue as duas páginas latinas mais comuns, a americana e a internacional. Elas diferem em exatamente sete valores de byte dos 256, e os sete caracteres envolvidos são os colchetes, a barra vertical, o ponto de exclamação, o circunflexo, o símbolo de centavo e o de negação.

Não é uma substituição e sim um embaralhamento: os mesmos sete caracteres ocupam as mesmas sete posições de byte nas duas páginas, em outra ordem. Todas as letras e todos os dígitos são idênticos. Então um arquivo de prosa viaja entre os dois sistemas sem um arranhão, e um de código-fonte chega com os colchetes virados em símbolos de moeda. É por isso que o problema é lembrado como um problema de colchetes e não de codificação: o estrago se concentra justamente nos caracteres de que uma linguagem de programação depende, e não toca em mais nada.

Entre as sete páginas daqui, só 150 dos 256 valores de byte significam a mesma coisa em todas. O painel de divergências se limita de propósito aos bytes da sua entrada e não à tabela inteira, porque a pergunta que vale responder é se o seu arquivo seria lido de outro jeito em outro lugar.

Limitações honestas

Sete páginas não são todas. A IBM definiu muitas outras, e as sete daqui são as que uma biblioteca padrão de propósito geral implementa, o que foi o que permitiu gerar as tabelas a partir de uma fonte em vez de digitá-las. Se o seu arquivo usa uma página que não está na lista, esta ferramenta não ajuda e testar as outras não vai consertar.

A ida e volta não é universal, e a ferramenta diz isso por página em vez de prometer em bloco. Cinco das sete aguentam decodificar e codificar de volta os 256 valores. A página hebraica deixa trinta e oito posições de byte sem atribuição, então essas não podem voltar a partir do texto: nunca houve nada ali. A grega é diferente e mais sutil: atribui as 256, mas sete dos seus valores de byte compartilham um mesmo caractere de preenchimento, de modo que só um do grupo pode ser codificado de volta e os outros seis se perdem. Dois defeitos diferentes que num resumo parecem o mesmo, e por isso são relatados separadamente.

Por fim, o seu navegador não consegue fazer nada disso sozinho. A norma de codificações da web enumera as que um navegador precisa aceitar e diz que ele não deve aceitar nenhuma outra; EBCDIC não está nessa lista e não vai estar. É por isso que as tabelas viajam com a página em vez de serem entregues a um decodificador embutido, e é a mesma norma de que trata a lista de codificações de caracteres deste site, vista do outro lado.

Por que é grátis?

Sete tabelas de 256 entradas dão uns cinco quilobytes depois de comprimidas, e o seu navegador faz a conversão enquanto você digita. Nenhum servidor vê os seus dados, então não há nada a medir nem conta a criar.

Nada é enviado. O que você colar fica nesta aba.