Lição de história: O que é um arquivo .txt? Por que textos antigos mostram caracteres estranhos

O que é um arquivo .txt?

Abra um .txt em qualquer editor e você vê apenas caracteres: letras, números, pontuação, espaços e quebras de linha. Esse é o formato inteiro. Não há cabeçalho, fonte, negrito ou itálico, tamanho de página nem registro do idioma do texto. O que o arquivo realmente contém é uma sequência de bytes, números de 0 a 255, e o programa que o abre precisa decidir a que caractere cada número corresponde. A extensão “.txt” só diz ao Windows qual programa oferecer; não diz nada sobre como os bytes devem ser lidos. Por isso o texto simples é um dos formatos mais portáteis já criados e também um dos mais fáceis de ler errado.

Por que meu arquivo .txt mostra caracteres estranhos?

Porque o programa que lê o arquivo usa uma codificação de caracteres diferente da do programa que o escreveu. A mesma letra pode ser guardada como bytes diferentes: é é o byte único E9 no Windows-1252, a página de código que a Microsoft descreve como a usual para inglês e outros idiomas da Europa Ocidental, mas os dois bytes C3 A9 no UTF-8. Abra um arquivo UTF-8 como Windows-1252 e cada é vira é. O apóstrofo tipográfico ’ (E2 80 99 em UTF-8) vira ’. Um arquivo UTF-8 que começa com uma marca de ordem de bytes (BOM, explicada abaixo) começa com . No sentido contrário, ao abrir como UTF-8 um arquivo Windows-1252, o byte E9 isolado não é UTF-8 válido, e o programa mostra o caractere de substituição �.

Arquivos da era DOS falham de outro jeito. No IBM PC original, o mesmo byte podia ser ainda outro caractere: na página de código 437, o conjunto de caracteres do DOS, o byte 82 é é e os cinco bytes C9 CD CD CD BB desenham a borda superior de uma caixa (╔═══╗). O Windows os lê como página de código 1252 e mostra ‚ e ÉÍÍÍ», de modo que a palavra café vira caf‚ e a moldura do banner de um README vira letras.

Nenhum programa acerta sempre sozinho. Em 2007, Raymond Chen, da Microsoft, mostrou o dilema do Bloco de Notas com um arquivo de dois bytes, D0 AE. Lido como Windows-1252, são os caracteres Ю; lido como UTF-8, é a letra cirílica Ю; lido como UTF-16 (dois bytes por caractere), é uma única sílaba do hangul coreano, diferente para cada ordem de bytes. Ele observou que as quatro leituras são plausíveis. Sem rótulo dentro do arquivo, “estranho” é simplesmente a aparência de um palpite errado.

1963: o ASCII dá um número a 128 caracteres

Para que o texto simples pudesse ser um arquivo, os caracteres precisavam de números com os quais máquinas diferentes concordassem. A American Standards Association criou em agosto de 1960 um subcomitê para conjuntos de caracteres codificados e, em 17 de junho de 1963, aprovou a norma X3.4-1963, o American Standard Code for Information Interchange: o ASCII. Era um código de 7 bits com 128 valores para caracteres de controle, números, pontuação e o alfabeto inglês. A edição de 1963 era sabidamente incompleta, com boa parte da tabela ainda sem atribuição. Um aviso de 1967 sobre a revisão aprovada em 7 de julho de 1967, X3.4-1967, dizia que a maioria dos envolvidos no projeto ASCII a considerava a primeira conclusão real do código básico de 7 bits.

Sete bits não cabem direito em um byte. Um dos primeiros documentos a dizer o que fazer é a RFC 20, escrita por Vint Cerf em outubro de 1969 para a ARPANET inicial, a rede de pesquisa que precedeu a Internet. Ela propunha “ASCII padrão de 7 bits embutido em um byte de 8 bits cujo bit de ordem mais alta é sempre 0”. Esse oitavo bit sem uso é onde os problemas começam depois: quando um byte comporta 256 valores, os outros 128 ficam livres para qualquer um atribuir.

CR, LF ou os dois: como uma linha termina

O ASCII também codificou a mecânica do teletipo. Como Chen explica, o retorno de carro (CR) levava o cabeçote de impressão de volta à coluna 0 sem avançar o papel, e o avanço de linha (LF) avançava o papel uma linha sem mover o cabeçote, então começar uma nova linha exigia os dois. A edição de 1968 do ASCII, reproduzida na RFC 20, permite que LF signifique “Nova linha”, mas acrescenta que usá-lo “exige acordo entre remetente e destinatário dos dados”. Esse acordo nunca veio por completo. A própria RFC 20 registra que os primeiros locais da ARPANET discordavam: o SRI usava um ponto como caractere de fim de linha, enquanto a UCLA usava o retorno de carro.

CP/M, MS-DOS e Windows mantiveram os dois caracteres, CRLF (os bytes 0D 0A). O Unix se contentou com um único LF (0A). O anúncio da Microsoft de 2018 sobre o novo comportamento do Bloco de Notas lista as três convenções que ele passa a tratar: fins de linha do Unix/Linux (LF), do Macintosh (CR) e do Windows (CRLF). Até então, dizia, o Bloco de Notas só exibia corretamente fins de linha do Windows, de modo que um arquivo de texto criado no Unix ou Linux parecia embaralhado. A correção chegou às compilações Insider do Windows 10 em maio de 2018.

1981: os outros 128 valores seguem cada um seu caminho

O IBM PC chegou em 1981 com bytes de 8 bits e um padrão de 7 bits. David Bradley, um de seus engenheiros, lembrou depois que o PC “usava o conjunto de caracteres ASCII, uma mudança radical para um produto da IBM” (os produtos anteriores da IBM usavam EBCDIC) e que, com 128 novas posições para preencher, a equipe as preencheu com letras de idiomas estrangeiros, gráficos de blocos e símbolos matemáticos e gregos. Ele disse que gostava de descrever o conjunto de caracteres como desenvolvido em “uma reunião de três pessoas de quatro horas”. O resultado é a página de código 437, que a Microsoft chama de página OEM (DOS) usual para inglês: sua metade superior contém letras acentuadas, caracteres para traçar linhas e símbolos.

Depois o Windows criou suas próprias páginas de código. A documentação da Microsoft diz que a página de código 1252 do Windows foi originalmente baseada em um rascunho do American National Standards Institute (ANSI) que acabou virando a ISO 8859-1, mas foi implementada antes de o padrão ser final e não é exatamente igual. As páginas de código do Windows ainda são comumente chamadas de “páginas de código ANSI”, embora sejam da própria Microsoft. Todas concordam com o ASCII nos valores 0 a 127 e discordam acima disso: o byte E9 é é na página 1252, й na página cirílica 1251 e ι na grega 1253. Japonês e chinês usavam páginas de código de byte duplo, em que alguns bytes só significam algo junto com o byte seguinte. A Microsoft observa que nenhuma página de código isolada cobre tudo o que o Unicode cobre.

1992: o Unicode e um jogo americano de papel numa lanchonete de Nova Jersey

O Unicode adotou a abordagem oposta: um número para cada caractere, sem mais malabarismo com páginas de código. Em sua primeira versão, de 1991 a 1995, era uma codificação de 16 bits; desde o Unicode 2.0, em julho de 1996, cobre a faixa de U+0000 a U+10FFFF. Mas um número não é um arquivo. Guardar valores de 16 bits diretamente em arquivos colidia com o software Unix da época, que dependia de bytes ASCII como o byte nulo e a barra, e em 1992 um comitê do X/Open estudava uma forma de guardar Unicode compatível com o Unix.

Rob Pike, então nos Bell Labs, escreveu em 2003 que o UTF-8 “foi projetado, diante dos meus olhos, num jogo americano de papel de uma lanchonete de Nova Jersey numa noite de setembro ou por aí de 1992”. Membros do comitê haviam pedido a ele e a Ken Thompson que revisassem a proposta. Os dois foram jantar, Thompson bolou o empacotamento de bits e depois ligaram para o comitê. Pike diz que Thompson escreveu naquela noite o código de empacotar e desempacotar, e que na sexta-feira o sistema operacional deles, o Plan 9, já rodava apenas com o que seria chamado de UTF-8. Arquivos de e-mail que seu colega Russ Cox desenterrou datam a proposta do início de setembro de 1992.

O UTF-8 guarda cada caractere em um a quatro bytes. Os 128 caracteres ASCII mantêm seu valor de um byte, e nenhum byte de outro caractere se parece com ASCII, de modo que um arquivo ASCII puro já é UTF-8 válido. Todo o resto ocupa de dois a quatro bytes, com bits iniciais que dizem ao leitor o tamanho da sequência: é vira C3 A9. A RFC 3629 de François Yergeau (novembro de 2003) o tornou um padrão da Internet, e o FAQ do Unicode o chama de “a forma preferida para arquivos de texto Unicode”.

O BOM e por que o Bloco de Notas tinha de adivinhar

O UTF-16 guarda caracteres em unidades de 16 bits, então o leitor também precisa saber a ordem dos bytes. A resposta do Unicode é um caractere, U+FEFF, colocado bem no início do arquivo como assinatura: a marca de ordem de bytes. Em UTF-8 ela aparece como os bytes EF BB BF, e o FAQ do Unicode é explícito: ali ela não tem a ver com a ordem dos bytes, apenas marca o arquivo como UTF-8. O FAQ acrescenta que alguns programas não a esperam (a primeira linha de um script de shell do Unix, que começa com #!, é um exemplo) e que um protocolo como as “convenções da Microsoft para arquivos .txt” pode exigi-la. Assim, um .txt pode começar com BOM ou não, e quando não começa, o programa precisa adivinhar.

A postagem de Chen em 2007 sobre “o problema da codificação de arquivos do Bloco de Notas” explica por que adivinhar nunca termina bem. Arquivos com BOM são fáceis. Sem BOM, a maioria dos arquivos de texto por aí era ANSI de 8 bits, alguns arquivos UTF-8 e UTF-16 também não tinham BOM, e toda regra que ele testou favorecia um grupo e quebrava outro. O exemplo dele: o comando cmd /u /c dir >results.txt grava um arquivo UTF-16 sem BOM.

A Microsoft mudou o Bloco de Notas em duas etapas. Em 2018, ele aprendeu os fins de linha do Unix e do Mac. Depois, na compilação Insider 18298 do Windows 10, de 10 de dezembro de 2018, a Microsoft adicionou a opção de salvar em UTF-8 sem BOM, tornou-a padrão para novos arquivos e pôs a codificação na barra de status, explicando que UTF-8 sem BOM é retrocompatível com o ASCII e funciona melhor com a web, “onde o UTF-8 se tornou a codificação padrão”. A mudança chegou a todos com o Windows 10 versão 1903, a Atualização de Maio de 2019. Antes, um novo arquivo do Bloco de Notas usava ANSI por padrão.

2007 em diante: o UTF-8 assume a web

O Google informou que, em dezembro de 2007, o Unicode se tornou pela primeira vez a codificação mais frequente nas páginas da web que indexava, ultrapassando o ASCII e as codificações da Europa Ocidental com dez dias de diferença entre uma e outra. O W3Techs informa hoje UTF-8 em 99,1% dos sites cuja codificação consegue identificar (novembro de 2026). É uma estatística sobre sites. Os arquivos de texto em discos antigos nunca fizeram parte dessa mudança, e ninguém voltou para recodificá-los.

Por que os .txt de discos antigos ainda parecem ilegíveis em 2026

O software de hoje presume UTF-8, mas muito texto foi escrito antes: README do DOS, primeiras anotações do Windows, exportações de programas que não rodam mais, e e-mails ou logs salvos como texto. Estão na página de código do PC que os criou, que dependia do idioma e da versão do Windows dele, e não trazem rótulo algum. Some fins de linha de outro sistema e um ou outro arquivo UTF-16 sem BOM, e a mesma extensão .txt esconde vários formatos sem relação entre si. Muitos são arquivos legacy cujo programa original ninguém pode mais consultar.

O Legacy File Converter lista o texto simples (.txt) entre os documentos na página Tipos de arquivo compatíveis e os converte no seu próprio PC com Windows para formatos modernos como DOCX, PDF, Markdown ou HTML; nada é enviado. Depois, compare letras acentuadas, aspas e símbolos com o original e guarde o arquivo original. Para outros formatos que por baixo são sobretudo texto, veja a Lição de história: O que é um arquivo .csv?, em que um BOM ausente faz o Excel tropeçar, e a Lição de história: O que é um arquivo .rtf?.