ASCII

ASCII (American Standard Code for Information Interchange, pronunciado “as-ki”) é uma codificação de caracteres que mapeia 128 símbolos para os inteiros 0-127. Definido em 1963 e padronizado internacionalmente como ISO/IEC 646 em 1972.

Cobertura:

• 0-31: caracteres de controle (NUL, nova linha, retorno de carro, tab, escape, sino)
• 32-47: pontuação e símbolos (espaço, !, ", #, $, %, etc.)
• 48-57: dígitos 0-9
• 58-64: mais pontuação (:, ;, <, =, >, ?, @)
• 65-90: maiúsculas A-Z
• 97-122: minúsculas a-z
• 127: DEL

ASCII cabe em 7 bits, razão pela qual os antigos protocolos seriais e sistemas de telégrafo usavam transmissão de 7 bits. O 8º bit tornou-se o bit de paridade. Sistemas modernos usam 8 bits por caractere; os 128 valores superiores (128-255) são interpretados de forma diferente dependendo da codificação escolhida (Latin-1, Windows-1252, etc.).

UTF-8 é compatível com ASCII para baixo — qualquer texto ASCII é um arquivo UTF-8 válido com bytes idênticos. Essa compatibilidade é uma das principais razões pelas quais o UTF-8 venceu as guerras de codificação Unicode.

Exemplo prático

A string “Hi!” codificada em ASCII é três bytes: H = 72 (0x48), i = 105 (0x69), ! = 33 (0x21). Escrito em binário: 01001000 01101001 00100001. Observe que o bit mais alto de cada byte é zero — essa é a garantia de 7 bits. Compare com a mesma string em UTF-16: 0048 0069 0021 — seis bytes para o mesmo conteúdo, com ordenação de bytes little-endian adicionando um BOM no início. Compare novamente com UTF-8: idêntico ao ASCII porque cada caractere está no intervalo 0-127. Agora tente “café”: ASCII não consegue codificar o é (Unicode U+00E9); o codificador gera um erro ou substitui por um ponto de interrogação. UTF-8 codifica é como dois bytes 0xC3 0xA9; Latin-1 codifica como o byte único 0xE9. O mesmo caractere visível, três sequências de bytes diferentes dependendo da escolha de codificação.

O complemento do ASCII para textos não ingleses é o Unicode, que atribui a cada caractere um ponto de código e usa codificações (UTF-8, UTF-16, UTF-32) para serializá-los como bytes. UTF-8 foi especificamente projetado por Ken Thompson e Rob Pike em 1992 para ser compatível com ASCII: qualquer arquivo contendo apenas caracteres ASCII é idêntico em ASCII e UTF-8, razão pela qual quase todos os protocolos de comunicação e formatos de configuração em inglês foram atualizáveis para Unicode sem quebras de compatibilidade.

Quando e por que isso importa

ASCII importa ao depurar bugs de codificação, projetar protocolos de comunicação ou trabalhar com qualquer sistema que processa texto byte a byte. O bug que envia um é como “cé” ou “cé” ou “c?” é sempre uma incompatibilidade ASCII/UTF-8/Latin-1 — em algum ponto do pipeline, os bytes foram decodificados com a suposição errada. Algoritmos de ordenação que tratam strings como bytes colocarão maiúsculas antes de minúsculas por causa da ordenação ASCII — “Zebra” vem antes de “apple” se você ordenar bytes brutos, surpreendendo usuários que esperam ordem lexicográfica sem distinção de maiúsculas/minúsculas. Regras de identificador em linguagens de programação (nomes de variáveis, chaves JSON) geralmente são restritas a ASCII para portabilidade entre sistemas cuja codificação padrão não pode ser assumida. Qualquer pessoa projetando um formato CSV, formato de arquivo de log ou protocolo de comunicação baseado em texto se beneficia de saber o que sobrevive intacto pelo pipeline ASCII versus o que é distorcido. Referência: RFC 20 — Formato ASCII para intercâmbio de rede.

Por que a ordenação do alfabeto importa: ASCII intencionalmente colocou letras maiúsculas (65-90) antes das minúsculas (97-122) com um deslocamento fixo de 32 entre elas. Definir ou limpar o bit 5 de qualquer byte de letra (o bit 0x20) inverte sua capitalização — maiúscula para minúscula e vice-versa. Esse truque de bit é a razão pela qual cada biblioteca de strings C antiga podia fazer tolower() com uma única operação aritmética, e está incorporado em inúmeros protocolos (nomes de cabeçalho HTTP, rótulos DNS) que são nominalmente insensíveis a maiúsculas/minúsculas, mas dependem dessa equivalência de inversão de bit. O truque falha no momento em que o Unicode chega — o I turco com/sem ponto são o contra-exemplo canônico.

O legado dos caracteres de controle que ninguém consegue descartar: o intervalo 0-31 carrega resíduos de hardware de teletipo que nenhum sistema moderno usa, mas todo analisador precisa reconhecer. NUL (0) termina strings C; LF (10) e CR (13) dividem linhas (Unix usa LF, Windows usa CRLF, o antigo Mac OS usava CR sozinho); HT (9) é o tab; ESC (27) inicia sequências de escape de terminal ANSI. O caractere de sino (7) costumava tocar um sino físico nos terminais Teletype Modelo 33; hoje aciona a API de bipe do sistema na maioria dos sistemas operacionais. Nenhum desses é projetável hoje — sobrevivem porque meio século de formatos de arquivo e protocolos de comunicação os esperam. Referência: ISO/IEC 646 — Tecnologia da informação — Conjunto de caracteres codificados ISO de 7 bits.