Converter Windows-1252 em UTF-8 preservando as quebras de linha

Um exemplo byte a byte para preservar acentos, o euro e CRLF ao converter um ficheiro local em UTF-8.

Um exemplo reproduzível

Clique em Carregar exemplo Windows-1252. O ficheiro fictício contém exatamente oito bytes: 43 61 66 E9 20 80 0D 0A. Windows-1252 é escolhido explicitamente. O texto Unicode esperado é Café €\r\n: a notação final representa um CR real seguido de LF, não quatro caracteres literais.

Os pontos de código são U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. A origem não é UTF-8 estrito: E9 não é seguido dos bytes de continuação necessários. Isso exige verificar a codificação da origem; não prova que todo ficheiro semelhante seja Windows-1252.

1. Mantenha Windows-1252 e clique em Pré-visualizar conversão.
2. Verifique Café € na pré-visualização, um CRLF nos detalhes e a presença da quebra de linha final.
3. Deixe o BOM de saída desmarcado, salvo se a aplicação de destino o exigir explicitamente.
4. Descarregue o resultado. Os seus onze bytes exatos são 43 61 66 C3 A9 20 E2 82 AC 0D 0A.
5. Se marcar BOM, pré-visualize novamente: a saída tem catorze bytes, com EF BB BF antes dos onze anteriores.

Por que “ANSI” não é uma resposta suficiente

O rótulo “ANSI” de uma aplicação é ambíguo. Windows-1252 associa o byte 80 ao euro; ISO-8859-1 o associa a U+0080, um controlo C1 recusado aqui. Os bytes 81, 8D, 8F, 90 e 9D são indefinidos no mapeamento estrito Windows-1252 desta ferramenta e interrompem a conversão. Peça a codificação real ao responsável pela exportação, em vez de escolher só porque a pré-visualização parece legível.

BOM, UTF-16 e finais incompletos

FF FE 41 00 0D 00 0A 00 é um exemplo UTF-16LE com BOM. Em UTF-8 sem BOM, vira 41 0D 0A: A seguido de CRLF. Sem BOM, escolha UTF-16 explicitamente. Um último byte isolado ou um substituto sem par interrompe a conversão, mesmo fora da pré-visualização visível. O BOM UTF-32 é reconhecido, mas o formato não é aceite.

O que é preservado e o que não pode ser recuperado

Espaços, tabulações, quebras CRLF/LF/CR misturadas, presença ou ausência de quebra final e caracteres Unicode compostos ou combinados permanecem iguais. Apenas o BOM inicial da origem é removido; o BOM de saída depende da sua escolha. Um U+FFFD já presente é mantido. Converter “Café” já corrompido não recupera os bytes originais.

O limite é de 5 MiB (5.242.880 bytes). A pré-visualização mostra até 16.000 unidades de código UTF-16, mas a validação e a exportação abrangem o ficheiro inteiro. Assinaturas binárias conhecidas e controlos NUL/C0/C1, exceto tabulação, CR e LF, são recusados. Essa precaução pode recusar texto legítimo incomum. O download é um ficheiro de texto simples .utf8.txt; o original não é sobrescrito.

Para CSV, converta primeiro a codificação e depois use CSV para JSON para alterar a estrutura. O inspetor não interpreta campos CSV nem muda separadores. O processamento usa memória do navegador, sem solicitações de rede ou armazenamento da ferramenta; o site continua a carregar seus recursos. Volte ao inspetor de codificação para testar o exemplo.