Verificação prévia de portabilidade de arquivos de texto
Cole texto ou selecione um arquivo de texto simples para detectar diferenças de codificação, finais de linha e espaços que podem afetar Git, ferramentas diff, CI, Bloco de Notas do Windows ou ferramentas Unix antigas, mesmo quando o arquivo parece normal no editor.
O processamento é feito localmente no seu navegador. Seu arquivo nunca é enviado.
Como usar esta ferramenta ferramenta
- Cole texto ou selecione arquivo .txt/.csv/.log/de texto simples. O navegador o lê localmente; ele não é enviado.
- Selecione ‘Verificar portabilidade’.
- Confira cada problema sinalizado, por que pode afetar a portabilidade e quais ferramentas pode afetar.
- Quando disponível, use a reescrita segura combinada: normaliza finais de linha, remove BOM inicial, corta espaços finais, acrescenta nova linha final e corrige espaços visualmente parecidos.
Premissas
- A entrada já é uma string JavaScript decodificada pelo navegador pelo método .text() do seletor de arquivos ou por texto colado. A ferramenta analisa o texto decodificado, não os bytes originais; não detecta diretamente a codificação original do arquivo.
- Reconhece oito problemas específicos: mistura de finais CRLF/LF, final CR sem LF, BOM inicial, caracteres de substituição Unicode, espaços finais, ausência de nova linha final, indentação mista de tabs/espaços e caracteres Unicode de espaço visualmente parecidos. Outros aspectos de codificação estão fora do escopo.
- Um caractere de substituição Unicode (U+FFFD) indica falha de decodificação já ocorrida antes da análise. Não é possível recuperar os bytes originais do texto e não se oferece reescrita para esse caso.
Fontes e dados de referência
Metodologia
O texto é dividido em linhas registrando o terminador original de cada uma (CRLF, LF, CR sem LF ou nenhum), permitindo detectar misturas sem perder informação ao normalizar. Depois são aplicadas oito verificações específicas por linha e caractere. A reescrita combinada é oferecida somente para correções mecânicas inequívocas: normalizar finais de linha, remover BOM, cortar espaços finais, acrescentar nova linha final e substituir/remover espaços visualmente parecidos. Caracteres de substituição e indentação mista são sinalizados sem alteração automática: o primeiro indica perda prévia de dados; a indentação correta depende de uma convenção de tabulação desconhecida.
Exemplo resolvido
Arquivo editado no Windows e Unix, misturando finais CRLF e LF
Dados de entrada: linha um\r\nlinha dois\n
Resultado: Git e outras ferramentas diff por linha comparam terminadores, então todas as linhas podem parecer alteradas mesmo que só o conteúdo de uma tenha mudado. É sinalizado como erro e oferece normalização segura para LF.
BOM UTF-8 antes de uma linha shebang
Dados de entrada: \uFEFF#!/bin/sh\necho "Olá"
Resultado: Um BOM antes de `#!/bin/sh` impede muitas shells Unix de reconhecerem a linha shebang. É sinalizado como aviso e oferece remover o BOM inicial.
Espaço não separável (U+00A0) colado no lugar de espaço normal
Dados de entrada: const total = preço + imposto;
Resultado: Parece espaço normal na maioria dos editores/fontes, mas comparação e análise exatas tratam-no como outro caractere. É sinalizado como aviso e reescrito para espaço ASCII normal.
Orientações práticas
- Configure o editor e `core.autocrlf` do Git (ou `.gitattributes`) para manter uma convenção de finais de linha por repositório, em vez de corrigir misturas manualmente depois.
- Trate caractere de substituição Unicode como incidente de perda de dados, não peculiaridade de formatação: exporte novamente ou reabra a origem com a codificação correta, em vez de tentar corrigir texto já corrompido.
- Ative ‘mostrar espaços’ ou ‘mostrar invisíveis’ no editor ao trabalhar com texto copiado de processador de texto, PDF ou página web; essa é a origem comum de espaços não separáveis e de largura zero.
- Prefira indentação somente por espaços ou somente por tabs conforme a convenção do projeto e aplique-a com formatador.
Erros comuns
- Presumir que o arquivo não tem problemas porque parece correto no editor: muitos editores normalizam CRLF/LF e ocultam espaços finais na exibição, justamente por isso os problemas passam despercebidos até Git, CI ou outra ferramenta divergir.
- Redigitar manualmente o texto após corrupção com caractere de substituição em vez de recuperar a origem: os bytes corrompidos não podem ser recuperados do texto decodificado.
Perguntas frequentes
Por que finais mistos e CR sem LF são erros, mas espaços finais são apenas informativos?
Finais mistos ou CR sem LF podem fazer ferramentas por linha (Git, diff, muitos parsers) interpretar incorretamente a estrutura do arquivo; é problema funcional, não preferência de estilo. Espaços finais são invisíveis e não impedem leitura; podem gerar ruído em formatador ou linter, efeito menor e informativo.
Por que a ferramenta não corrige automaticamente indentação mista de tabs e espaços?
Para converter corretamente seria preciso conhecer a largura pretendida da tabulação, por exemplo 2, 4 ou 8 colunas. A ferramenta não pode inferir a convenção sem risco de alterar a estrutura visual; por isso sinaliza as linhas exatas.
A ferramenta detecta a codificação original do arquivo?
Não. Quando a ferramenta recebe o texto, o navegador já converteu os bytes em string JavaScript usando sua própria estimativa ou a codificação escolhida. A ferramenta só detecta uma falha posterior pelo caractere de substituição Unicode U+FFFD; não inspeciona bytes originais.
Por que CRLF e LF misturados geram diffs ruidosos e o que esta ferramenta detecta?
Ferramentas por linha podem tratar terminadores diferentes como alterações mesmo quando o texto é igual, fazendo uma pequena edição parecer mudança no arquivo inteiro. Esta verificação prévia detecta mistura CRLF/LF, finais CR sem LF e os outros problemas listados. Analisa texto já decodificado pelo navegador, não bytes originais nem todos os problemas possíveis de texto.
Última revisão:
Scanner restrito por linha/caractere, não detector de codificação em nível de bytes: trabalha com texto já decodificado pelo navegador, portanto não identifica codificação original nem recupera dados perdidos em falha anterior. Reconhece oito problemas específicos e nada mais; outros casos extremos (pares substitutos, normalização de caracteres combinantes, marcas de direção da direita para a esquerda) estão fora do escopo.
Esta ferramenta fornece uma estimativa indicativa com base nas premissas informadas acima.
As preferências de tema e de ferramentas, além das listas de itens salvos e usados recentemente, são armazenadas somente neste navegador.