Texto e bytes

Conversor de quebras de linhaConfira o que muda de verdade

Padronize texto ou vários arquivos e examine os bytes sem trocar a codificação sem confirmação.

Conversor de quebras de linha

Entrada

UTF-8; BOM: nenhum; 0 bytes. CRLF 0, LF 0, CR 0; NUL 0; quebra final: não.

Resultado

Ainda não há resultado.

Texto e arquivos são processados neste navegador; nenhum dado de entrada é enviado.

Até 20 arquivos: 2 MiB cada, 16 MiB de entrada e 32 MiB de saída no total.

Opções de conversão

O BOM reconhecido tem prioridade. Texto digitado usa UTF-8. Bytes NUL não servem para adivinhar a codificação.

Digite texto ou escolha arquivos.

Copiar transfere texto, não a codificação nem um BOM adicionado. O download mantém os bytes mostrados.

BOM mostra o prefixo real. Se havia duas marcas, remover uma pode deixar um prefixo pertencente ao texto restante.

Um script pode parecer igual em dois editores e falhar por um CR a mais. O Conversor de quebras de linha conta pares CRLF, LF isolados e CR isolados separadamente, mostrando quebras de linha misturadas antes da conversão.

O texto colado não comprova a codificação do arquivo original. Escolha arquivos para conferir a assinatura e a ordem dos bytes. A entrada de texto usa UTF-8; os arquivos mantêm a codificação detectada ou escolhida explicitamente.

Por que usar o Conversor de quebras de linha

Mantenha o conteúdo das linhas

O Conversor de quebras de linha troca apenas separadores existentes. Espaços, tabulações, linhas vazias e a presença de uma quebra final ficam como estavam. Preserve os finais para alterar somente o BOM.

Três linhas mantêm seu conteúdo enquanto marcas diferentes nas terminações se tornam iguais

Separe assinatura de caractere

O Conversor de quebras de linha considera apenas a primeira assinatura como BOM. Um segundo U+FEFF ou um caractere igual no meio continua sendo conteúdo. A comparação hexadecimal revela quais bytes foram removidos.

A primeira marca de uma sequência de bytes é removida, mas outra igual no conteúdo permanece

Escolha a origem antes do destino

01

Leia os arquivos originais

Selecione até 20 arquivos e confira a substituição antes de aplicar. O BOM determina UTF-8 ou a ordem de UTF-16. Sem BOM, o padrão é UTF-8; escolha UTF-16LE/BE ou Windows-1252 se souber a codificação de origem.

02

Decida formato, BOM e codificação

O padrão é LF, mantendo BOM e codificação. Mudar CRLF para LF não acrescenta uma quebra final. Para recodificar em UTF-8, escolha essa saída e marque a confirmação. Alterar dados ou opções de conversão desmarca a confirmação.

03

Confira os bytes antes de baixar

A prévia cresce de 10.000 em 10.000 caracteres ou de 256 em 256 bytes. O download contém tudo. O modo automático aguarda 350 ms; desligue-o para usar Converter ou Ctrl/Cmd+Enter. Editar bloqueia imediatamente a exportação antiga.

Veja o que o editor não mostra

Contagens sem duplicar pares

CRLF conta como um único separador. As estatísticas também mostram NUL e a presença da quebra final. U+0085, U+2028 e U+2029 são mantidos como conteúdo, sem virar finais de linha.

Assinatura correta para cada formato

BOM UTF-8 e as assinaturas UTF-16LE/BE são tratados conforme a codificação. Remover afeta só uma assinatura inicial. Windows-1252 não tem BOM; para adicionar um, é necessário confirmar a mudança para UTF-8.

Sem substituição silenciosa

UTF-8 inválido, UTF-16 com quantidade ímpar de bytes e substitutos isolados geram erro. Windows-1252 segue o mapeamento WHATWG, inclusive valores C1 reversíveis. Não há limpeza de espaços, normalização Unicode ou execução de fórmulas.

Lote completo e nomes distintos

O BOM é detectado por arquivo, com opções comuns ao lote. Nomes seguros e numerados evitam colisões no ZIP. Se um arquivo falhar, todo o lote fica sem exportação; nenhum item é omitido como se tudo tivesse dado certo.

Limites da operação com texto

Orçamento de memória
Cada entrada aceita até 2 MiB; o lote, 20 arquivos e 16 MiB; a saída total, 32 MiB. Ultrapassar o limite interrompe a operação sem cortar conteúdo. Arquivos vazios ou contendo somente BOM são válidos.
Codificações bem definidas
Há suporte a UTF-8 e UTF-16LE/BE, além de Windows-1252 escolhido para arquivos sem BOM. UTF-32 é detectado e recusado. Não há GBK, Shift_JIS, detecção universal, reparo binário, leitura de Office nem importação de arquivos compactados.
Quebras entre aspas também mudam
A estrutura de CSV ou de código não é interpretada. Quebras reais dentro dessas estruturas entram na conversão. Não se adiciona nem remove a quebra final. Linhas vazias, espaços, tabs, NUL e U+FEFF internos permanecem.
Copiar não exporta a codificação
O aplicativo de origem pode alterar as quebras antes da colagem. O editor mantém o que recebe, mas não recupera bytes perdidos. Copiar leva o texto sem uma assinatura de arquivo adicionada. Baixe para obter os bytes exatos.
Revise antes de substituir
Exemplo, limpeza e troca de arquivos mostram as quantidades afetadas antes de aplicar. Desfazer restaura as duas entradas, opções, modo automático, confirmação e resultado. Trocar entre texto e arquivos preserva as entradas. Os originais nunca são sobrescritos.

Dúvidas sobre o Conversor de quebras de linha

Por que as terminações variam entre sistemas?

São convenções históricas: CRLF é frequente em fluxos Windows, LF em sistemas Unix e CR em formatos antigos. O Conversor de quebras de linha começa com LF, mas a exigência do programa que receberá o arquivo vem primeiro.

Por que usar o arquivo em vez de colar o texto?

A área de transferência pode remover CR antes da chegada ao editor. Os CRLF e CR entregues pelo evento de colagem são mantidos, mas não se recupera o que já foi alterado. O arquivo permite conferir os bytes originais.

Quando as terminações geram problemas?

Quando o Git mostra diferenças em quase todas as linhas ou um script shell recebe CR inesperado. Confira as contagens e os bytes e escolha o formato exigido pelo destino.

Como tratar CRLF e LF no mesmo arquivo?

Escolha um formato para todos os separadores. A conversão não fica restrita às linhas que parecem suspeitas. As quebras reais em campos CSV entre aspas também mudam, então confira a exigência do formato.

Dá para automatizar isso no Git?

Os atributos text/eol e core.autocrlf controlam o tratamento no índice e na cópia de trabalho. Um arquivo baixado pode voltar a mudar durante o checkout. Esta página não altera configurações do repositório.

Encontrou bytes inesperados?

Teste o Conversor de quebras de linha

Compare as contagens e os primeiros bytes com os requisitos do programa de destino antes de baixar os arquivos.