Descrição Overview Descripción
A quebra de linha parece o conceito mais simples do mundo até que você tenta entender como funciona em detalhes. No Unix, uma quebra de linha é o caractere LF (Line Feed, código ASCII 10). No Windows, é a sequência CR+LF (Carriage Return mais Line Feed). No antigo Mac OS clássico, era apenas CR. O LF venceu como padrão universal da internet: HTTP, SMTP, JSON e a maioria dos protocolos de rede usam LF ou CR+LF como separador de linha, independentemente do sistema operacional do servidor. Essa diferença entre sistemas é uma fonte constante de frustração para desenvolvedores em ambientes mistos — o famoso arquivo que parece correto no Mac mas abre como uma linha só no Notepad do Windows.
A história de dois caracteres para representar fim de linha vem das máquinas de escrever. O Carriage Return era o mecanismo físico que empurrava o carro de volta para o início da linha. O Line Feed era o rolo que avançava o papel para a linha seguinte. As primeiras impressoras e terminais de computador imitaram esse comportamento mecânico. Quando Ken Thompson e Dennis Ritchie criaram o Unix, decidiram que um único caractere seria suficiente para marcar o fim de linha, simplificando o padrão. A Microsoft manteve os dois caracteres no DOS e depois no Windows por compatibilidade, e mantém essa tradição até hoje.
Unir linhas em uma só é uma necessidade prática em várias situações de desenvolvimento. Queries SQL formatadas em múltiplas linhas para legibilidade precisam ser condensadas em uma linha para ser passadas como string em um script de shell ou variável de ambiente. Chaves privadas SSH e certificados TLS armazenados em variáveis de ambiente precisam ter as quebras removidas porque muitos sistemas não suportam valores multilinhas. Payloads JSON que precisam ser incluídos como argumento de curl ou como valor em um arquivo .env também dependem de uma linha única e contínua para funcionar corretamente.
The line break seems like the simplest concept in the world until you try to understand how it actually works in detail. On Unix, a line break is the LF character (Line Feed, ASCII code 10). On Windows, it is the CR+LF sequence (Carriage Return plus Line Feed). On the old classic Mac OS, it was just CR. LF won as the universal internet standard: HTTP, SMTP, JSON, and most network protocols use LF or CR+LF as the line separator regardless of the server's operating system. This difference across systems is a constant source of frustration for developers in mixed environments — the classic case of a file that looks correct on macOS but opens as a single line in Windows Notepad.
The story of two characters to represent end-of-line comes from typewriters. The Carriage Return was the physical mechanism that pushed the carriage back to the start of the line. The Line Feed was the roller that advanced the paper to the next line. Early computer printers and terminals mimicked this mechanical behavior. When Ken Thompson and Dennis Ritchie created Unix, they decided a single character would be enough to mark end-of-line, simplifying the standard. Microsoft kept two characters in DOS and later Windows for compatibility, and maintains that tradition to this day.
Joining multiple lines into one is a practical necessity in several development situations. SQL queries formatted across multiple lines for readability need to be condensed into one line to be passed as a string in a shell script or environment variable. SSH private keys and TLS certificates stored in environment variables need their line breaks removed because many systems do not support multi-line values. JSON payloads that need to be included as a curl argument or as a value in a .env file also depend on a single continuous line to work correctly.
El salto de línea parece el concepto más sencillo del mundo hasta que intentas entender cómo funciona en detalle. En Unix, un salto de línea es el carácter LF (Line Feed, código ASCII 10). En Windows, es la secuencia CR+LF (Carriage Return más Line Feed). En el antiguo Mac OS clásico, era solo CR. El LF se impuso como estándar universal de internet: HTTP, SMTP, JSON y la mayoría de los protocolos de red usan LF o CR+LF como separador de línea, independientemente del sistema operativo del servidor. Esta diferencia entre sistemas es una fuente constante de frustración para los desarrolladores en entornos mixtos — el clásico caso del archivo que parece correcto en macOS pero que se abre como una sola línea en el Bloc de notas de Windows.
La historia de dos caracteres para representar el fin de línea viene de las máquinas de escribir. El Carriage Return era el mecanismo físico que empujaba el carro de vuelta al inicio de la línea. El Line Feed era el rodillo que avanzaba el papel a la siguiente línea. Las primeras impresoras y terminales de ordenador imitaron ese comportamiento mecánico. Cuando Ken Thompson y Dennis Ritchie crearon Unix, decidieron que un único carácter sería suficiente para marcar el fin de línea, simplificando el estándar. Microsoft mantuvo los dos caracteres en DOS y posteriormente en Windows por compatibilidad, y conserva esa tradición hasta hoy.
Unir varias líneas en una sola es una necesidad práctica en varias situaciones de desarrollo. Las consultas SQL formateadas en varias líneas para facilitar la lectura deben condensarse en una línea para pasarse como cadena en un script de shell o variable de entorno. Las claves privadas SSH y los certificados TLS almacenados en variables de entorno necesitan tener eliminados sus saltos de línea porque muchos sistemas no admiten valores multilínea. Los payloads JSON que deben incluirse como argumento de curl o como valor en un archivo .env también dependen de una única línea continua para funcionar correctamente.
Detalhamento técnico
LF, CR e CRLF: a guerra dos fins de linha
- LF (\n, U+000A): padrão Unix e Linux. Git, JSON, HTTP e praticamente todos os protocolos da internet usam LF como terminador de linha.
- CRLF (\r\n, U+000D U+000A): padrão do Windows e do DOS desde o CP/M nos anos 70. Muitos protocolos de rede como SMTP e HTTP/1.1 especificam CRLF nos cabeçalhos — o que cria confusão ao misturar corpo de mensagem com cabeçalhos.
- CR (\r, U+000D): padrão do Mac OS clássico até a versão 9. A Apple migrou para LF no OS X (2001). Ainda aparece em alguns arquivos legados e exportações de Excel em sistemas antigos.
- Git e a configuração autocrlf: o Git pode converter automaticamente CRLF para LF no commit (core.autocrlf=true no Windows) para manter o repositório com LF. Isso é essencial em projetos com colaboradores em diferentes sistemas.
- Arquivos de texto 'mistos': arquivos que misturam LF e CRLF na mesma file são um problema real em pipelines de CI/CD — algumas ferramentas de linting falham silenciosamente nesses casos.
Quando você precisa de uma linha contínua
- Variáveis de ambiente: a maioria dos sistemas operacionais e frameworks não suporta quebras de linha em valores de variáveis de ambiente. Chaves privadas SSH e tokens JWT armazenados em .env precisam estar em uma única linha.
- Argumentos de curl: ao passar um payload JSON como argumento -d, o shell interpreta quebras de linha literais. A string precisa ser uma linha contínua ou escapada corretamente.
- Arquivos .env: o formato padrão do dotenv não suporta valores multilinhas sem aspas especiais. Certificados e chaves inline em .env precisam ter quebras removidas.
- Consultas SQL em scripts shell: ao construir queries dinamicamente em bash, quebras de linha em strings SQL podem ser mal interpretadas pelo shell ou pelo cliente de banco.
- Cabeçalhos HTTP via linha de comando: cabeçalhos HTTP não podem conter quebras de linha. Um valor de cabeçalho Authorization com um token JWT multilinhas falharia silenciosamente ou causaria erro de parse.
Technical deep dive
LF, CR and CRLF: the line ending wars
- LF (\n, U+000A): Unix and Linux standard. Git, JSON, HTTP, and virtually all internet protocols use LF as the line terminator.
- CRLF (\r\n, U+000D U+000A): Windows and DOS standard since CP/M in the 1970s. Many network protocols like SMTP and HTTP/1.1 specify CRLF in headers — which creates confusion when mixing message body and headers.
- CR (\r, U+000D): classic Mac OS standard through version 9. Apple migrated to LF in OS X (2001). Still appears in some legacy files and Excel exports from older systems.
- Git and the autocrlf setting: Git can automatically convert CRLF to LF on commit (core.autocrlf=true on Windows) to keep the repository using LF. This is essential in projects with collaborators on different systems.
- Mixed line ending files: files that mix LF and CRLF in the same file are a real problem in CI/CD pipelines — some linting tools fail silently in these cases.
When you need a continuous single line
- Environment variables: most operating systems and frameworks do not support line breaks in environment variable values. SSH private keys and JWT tokens stored in .env must be on a single line.
- curl arguments: when passing a JSON payload as a -d argument, the shell interprets literal line breaks. The string must be a continuous line or properly escaped.
- .env files: the standard dotenv format does not support multi-line values without special quoting. Certificates and keys inline in .env need their breaks removed.
- SQL queries in shell scripts: when building queries dynamically in bash, line breaks in SQL strings can be misinterpreted by the shell or the database client.
- HTTP headers via command line: HTTP headers cannot contain line breaks. An Authorization header value with a multi-line JWT token would fail silently or cause a parse error.
Detalle técnico
LF, CR y CRLF: la guerra de los finales de línea
- LF (\n, U+000A): estándar de Unix y Linux. Git, JSON, HTTP y prácticamente todos los protocolos de internet usan LF como terminador de línea.
- CRLF (\r\n, U+000D U+000A): estándar de Windows y DOS desde el CP/M de los años 70. Muchos protocolos de red como SMTP y HTTP/1.1 especifican CRLF en las cabeceras, lo que genera confusión al mezclar el cuerpo del mensaje con las cabeceras.
- CR (\r, U+000D): estándar del Mac OS clásico hasta la versión 9. Apple migró a LF en OS X (2001). Todavía aparece en algunos archivos legados y exportaciones de Excel de sistemas más antiguos.
- Git y la configuración autocrlf: Git puede convertir automáticamente CRLF a LF en el commit (core.autocrlf=true en Windows) para mantener el repositorio con LF. Esto es esencial en proyectos con colaboradores en diferentes sistemas.
- Archivos con finales de línea mixtos: los archivos que mezclan LF y CRLF en el mismo fichero son un problema real en los pipelines de CI/CD; algunas herramientas de linting fallan silenciosamente en esos casos.
Cuándo necesitas una línea continua
- Variables de entorno: la mayoría de los sistemas operativos y frameworks no admiten saltos de línea en los valores de las variables de entorno. Las claves privadas SSH y los tokens JWT almacenados en .env deben estar en una sola línea.
- Argumentos de curl: al pasar un payload JSON como argumento -d, el shell interpreta los saltos de línea literales. La cadena debe ser una línea continua o estar correctamente escapada.
- Archivos .env: el formato estándar de dotenv no admite valores multilínea sin comillas especiales. Los certificados y claves en línea en .env necesitan tener eliminados sus saltos.
- Consultas SQL en scripts de shell: al construir consultas dinámicamente en bash, los saltos de línea en las cadenas SQL pueden ser mal interpretados por el shell o el cliente de base de datos.
- Cabeceras HTTP por línea de comandos: las cabeceras HTTP no pueden contener saltos de línea. Un valor de cabecera Authorization con un token JWT multilínea fallaría en silencio o causaría un error de análisis.
Guia da ferramenta Tool guide Guía de la herramienta
-
O que são quebras de linha Delimitadores (
\n/\r\n) que separam linhas em textos e logs. -
O que a ferramenta faz Substitui quebras por espaço e normaliza excesso de espaços, deixando o conteúdo em uma linha.
-
Por que usar Preparar payloads, variáveis de ambiente e campos que não aceitam multilinha.
-
What line breaks are Delimiters (
\n/\r\n) that split lines in text and logs. -
What the tool does Replaces line breaks with spaces and normalizes extra spaces into one line.
-
Why use it Prepare payloads, environment variables, and fields that do not accept multi-line input.
-
Qué son los saltos de línea Delimitadores (
\n/\r\n) que separan líneas en texto y logs. -
Qué hace la herramienta Reemplaza saltos por espacios y normaliza espacios extra para dejar una sola línea.
-
Por qué usarla Preparar payloads, variables de entorno y campos que no aceptan multilínea.
Exemplo de Código Code Snippets Fragmentos de Código
// Remove CRLF e LF, preservando palavras com espaços
const umaLinha = texto
.replace(/\r\n/g, ' ') // CRLF primeiro
.replace(/[\r\n]/g, ' ') // depois CR e LF isolados
.replace(/ +/g, ' ') // colapsa espaços duplos
.trim();// Une as linhas sem separador — útil para tokens, base64, hashes
const compacto = texto
.replace(/\r\n|\r|\n/g, '') // remove qualquer estilo de quebra
.trim();// Removes CRLF and LF, preserving words with spaces
const oneLine = text
.replace(/\r\n/g, ' ') // CRLF first
.replace(/[\r\n]/g, ' ') // then standalone CR and LF
.replace(/ +/g, ' ') // collapse double spaces
.trim();// Joins lines with no separator — useful for tokens, base64, hashes
const compact = text
.replace(/\r\n|\r|\n/g, '') // remove any line ending style
.trim();// Elimina CRLF y LF preservando las palabras con espacios
const unaLinea = texto
.replace(/\r\n/g, ' ') // CRLF primero
.replace(/[\r\n]/g, ' ') // luego CR y LF independientes
.replace(/ +/g, ' ') // colapsa espacios dobles
.trim();// Une las líneas sin separador — útil para tokens, base64, hashes
const compacto = texto
.replace(/\r\n|\r|\n/g, '') // elimina cualquier estilo de salto
.trim();Exemplo Example Ejemplo
linha 1
linha 2 -> linha 1 linha 2Perguntas frequentes FAQ Preguntas frecuentes
Para que serve esta ferramenta?
What is this tool for?
¿Para qué sirve esta herramienta?
Ela roda 100% no seu navegador: útil para validar, formatar ou converter dados no dia a dia de desenvolvimento.
It runs fully in your browser: useful to validate, format, or convert data in everyday development.
Funciona por completo en tu navegador: sirve para validar, formatear o convertir datos en el día a día.
Meus dados são enviados a algum servidor?
Are my inputs sent to a server?
¿Se envían mis datos a algún servidor?
O processamento é feito localmente via JavaScript. Não armazenamos o conteúdo que você cola nas caixas de texto.
Processing happens locally with JavaScript. We do not store what you paste into the text areas.
El procesamiento es local con JavaScript. No almacenamos lo que pegas en los campos de texto.
Posso usar em produção ou para dados reais?
Can I use this for real production data?
¿Puedo usarlo con datos reales en producción?
Use por sua conta e risco. Para segredos (senhas, tokens), prefira ambientes controlados e políticas da sua empresa. E lembre sempre de revisar os conteúdos gerados. Nunca confie cegamente nas coisas que vê na internet.
Use at your own risk. For secrets (passwords, tokens), prefer controlled environments and your company policies. And always review the generated contents. Never trust blindly things you see on the internet.
Úsalo bajo tu responsabilidad. Para secretos (contraseñas, tokens), prefiere entornos controlados y políticas internas. Recuerda de revisar los contenidos generados. Nunca confies ciegamente en cosas que ves en internet.