Detector de Codificação de Caracteres

Texto distorcido — pontos de interrogação onde deveriam estar letras acentuadas, ou strings como é no lugar de é — quase sempre significa que um arquivo foi gravado em uma codificação de caracteres e relido em outra. O Detector de Codificação de Caracteres inspeciona os bytes brutos do texto colado ou arquivo enviado e relata sua codificação mais provável, com a evidência em nível de byte por trás dessa suposição.

Como usar

Cole o texto em Texto de Entrada, ou solte um arquivo no uploader para inspecionar seus bytes originais. O resultado é atualizado automaticamente e mostra a Codificação Detectada, uma porcentagem de Confiança, qualquer BOM encontrado, a contagem de bytes e uma linha de Raciocínio em linguagem comum. Uma tabela Todos os candidatos considerados abaixo lista todas as codificações que o detector considerou, cada uma com sua própria confiança e raciocínio, para que você possa ver as suposições do segundo lugar e por que pontuaram mais baixo.

Como funciona a detecção

A detecção passa por uma sequência fixa de verificações, da mais para a menos certa:

1. Marca de ordem de byte (BOM). Algumas codificações adicionam uma sequência de byte fixa a um arquivo — EF BB BF para UTF-8, FF FE/FE FF para UTF-16, e variantes de 4 bytes para UTF-32. Encontrar uma é quase definitivo: 99% de confiança.
2. ASCII puro. Se cada byte está no intervalo 0x00–0x7F, é ASCII válido — e, como ASCII é um subconjunto rigoroso de UTF-8, é simultaneamente UTF-8 válido. Relatado com 100% de confiança.
3. UTF-8 válido. Sem um BOM, um validador UTF-8 real percorre o fluxo de byte: verifica se os bytes de continuação têm os bits altos corretos, rejeita codificações "alongadas demais" (mais bytes do que o codepoint precisa), e rejeita codepoints fora do intervalo ou meios de substituto UTF-16 solitários. Esta é uma verificação de gramática genuína, não apenas "a decodificação gerou erro" — então captura sequências malformadas que um decodificador lenient silenciosamente aceitaria. O texto que passa limpo é relatado como UTF-8 com 97% de confiança.
4. Suposição de conjunto de caracteres herdado de um byte único. Se os bytes falharem na validação UTF-8, o detector volta para uma heurística de frequência de byte entre Windows-1252 e ISO-8859-1 (Latin-1), as duas codificações de um byte mais comuns do Ocidente. Os bytes no intervalo 0x80–0x9F são códigos de controle indefinidos em Latin-1, mas pontuação imprimível (aspas onduladas, travessões) em Windows-1252, então sua presença aponta para Windows-1252. Este ramo é mantido bem abaixo de 70% de confiança, porque é uma suposição estatística, não uma certeza — os mesmos bytes são frequentemente válidos em mais de um conjunto de caracteres.

Meus dados são enviados para algum lugar?

Não. A detecção é executada inteiramente no seu navegador (ou, pela API, no manipulador de solicitações) — nada é enviado para um serviço de terceiros.

Por que meu arquivo não é detectado como Shift_JIS, Big5 ou outra codificação CJK?

Essas codificações asiáticas multi-byte herdadas não são cobertas — adivinhar delas apenas a partir de intervalos de byte produz muitos falsos positivos, diferentemente da verificação de BOM ou verificação de gramática UTF-8. Se você sabe que um arquivo é Shift_JIS ou GBK, decodifique-o diretamente com esse rótulo em vez de contar com detecção.