Texto y herramientas cotidianas · Text Toolkit
CR, LF y CRLF: de dónde vienen los finales de línea y por qué se rompe el texto pegado
· Antecedentes
finales de línea limpieza de texto exportaciones de datos
Explica los orígenes del teletipo del retorno de carro y el avance de línea, por qué los sistemas operativos eligieron convenciones diferentes y cómo esas opciones aparecen como líneas en blanco duplicadas y caracteres perdidos en el texto pegado.
La exportación con una línea en blanco después de cada fila: por qué un archivo de otro sistema se pega con el doble de líneas
Pegas una exportación de tres filas y ves una línea en blanco después de cada registro. Es tentador culpar inmediatamente a Windows CRLF, pero un área de texto que cumple con los estándares normalmente presenta saltos de línea en forma normalizada. Las filas duplicadas suelen significar que una conversión anterior trató el retorno de carro y el avance de línea como dos separadores independientes, o insertó una nueva línea adicional entre registros.
Conserve el original hasta que sepa en qué etapa lo cambió. Compare la fuente en un editor que pueda revelar caracteres de control y luego compare el recuento de líneas pegadas. ToolAcre acepta deliberadamente CRLF, LF y CR solitario como un límite cada uno, por lo que un archivo de tres registros intacto debería producir tres líneas en lugar de seis simplemente porque proviene de Windows.
Una fila en blanco adicional es un síntoma, no una prueba de que CRLF por sí solo lo haya causado
Los nombres describen acciones físicas en terminales de impresión. Un retorno de carro movía el carro al inicio de la línea actual, mientras que un avance de línea hacía avanzar el papel a la siguiente línea. Eran controles separados porque cualquiera de las mociones podía solicitarse de forma independiente. ASCII los retuvo como caracteres de control CR en el decimal 13 y LF en el decimal 10.
Las pantallas modernas ya no mueven papel, pero los valores de bytes sobrevivieron en archivos, protocolos e interfaces de programación. La historia explica por qué CR y LF no son signos de puntuación intercambiables y por qué CRLF es una secuencia de dos caracteres. Esto no significa que cada aplicación moderna los procese por separado; Los analizadores comúnmente reconocen el par como un final de línea lógica.
Tres convenciones: LF en Unix y macOS moderno, CRLF en Windows, CR en Mac OS clásico y por qué cada una parecía razonable
Los sistemas Unix y similares usan convencionalmente LF para el final de una línea, y macOS moderno sigue esa convención. Los archivos de texto de Windows utilizan convencionalmente CRLF. El Mac OS clásico usaba CR solo, pero Mac OS X adoptó la base Unix y LF. Esas opciones siguen siendo visibles cuando las herramientas intercambian texto sin formato sin llegar a un acuerdo sobre la normalización.
Ninguna convención hace que las palabras en sí sean diferentes. El problema aparece en un límite cuyo lector espera sólo una representación o se divide ingenuamente en cada carácter de control. Un analizador de líneas robusto verifica CRLF como un par antes de verificar CR o LF solitarios. ToolAcre hace exactamente eso con el patrón ordenado ` | | `, luego une la salida transformada con LF.
Qué sucede en un cuadro de texto del navegador: cómo se normalizan generalmente los saltos de línea al pegar y dónde siguen apareciendo caracteres perdidos
HTML define un manejo especial para saltos de línea en controles de texto. En un valor de área de texto, los navegadores normalizan CRLF y CR solitario a LF en el valor expuesto, mientras que el envío de formularios puede aplicar las reglas de datos de formulario para saltos de línea. En consecuencia, una pasta que parece correcta en la caja aún puede serializarse de manera diferente en otra capa o copiarse en un software con otra convención.
CR perdidos todavía pueden aparecer cuando el texto pasa por alto un área de texto normal, cuando se muestran bytes escapados como los caracteres literales `\r`, o cuando un analizador divide solo en LF y deja CR adjunto a cada campo. El navegador es una etapa en el camino, no un servicio universal de reparación de archivos, productores de portapapeles, API y consumidores de línea de comandos.
Los navegadores normalizan los saltos de línea del área de texto, pero los formatos del portapapeles y descendentes aún difieren
Las filas en blanco y los retornos de carro finales requieren diagnósticos diferentes. Eliminar líneas vacías elimina filas cuyo contenido está vacío o con espacios en blanco después de que ToolAcre haya reconocido los tres estilos de final de línea. Trim Lines elimina los espacios en blanco iniciales y finales de cada fila. Debido a que el divisor de ToolAcre consume un separador CR real, normalmente no es necesario recortarlo simplemente para borrar ese separador.
Utilice el recorte solo cuando queden espacios, tabulaciones o un carácter literal no consumido, e inspeccione la sangría significativa antes de cambiarla. Si el texto contiene `^M` visible, determine si el visor está representando un CR real o esos dos caracteres imprimibles. Un reemplazo general puede dañar el contenido previsto, mientras que verificar los recuentos antes y después proporciona un resultado revisable.
Eliminar líneas vacías corrige filas vacías; El recorte suele ser innecesario después de que ToolAcre divide CR correctamente
Para obtener un ejemplo reproducible, comience con tres nombres cuya representación intermedia dañada contenga una fila vacía entre cada nombre: `Ada`, en blanco, `Grace`, en blanco, `Linus`. El contador de palabras y caracteres informa cinco líneas. Esta es una entrada deliberadamente duplicada; una secuencia CRLF genuina por sí sola sería reconocida como un límite y no crearía esas filas vacías en ToolAcre.
Elija Eliminar líneas vacías y la salida se convierte en tres líneas unidas con LF. El contador ahora debería informar tres. Si los valores importados también llevan relleno, ejecute Recortar líneas por separado y revise el resultado. Separar esas operaciones demuestra qué defecto solucionó cada acción en lugar de atribuir cada limpieza a una vaga conversión del texto de Windows.
Ejemplo resuelto: limpiar una exportación duplicada deliberadamente y verificar el recuento de líneas
La limpieza del final de línea no repara el ajuste estricto, donde una oración lógica se rompió deliberadamente en un ancho de columna. Eliminar cada nueva línea de ese material también uniría párrafos reales y elementos de lista. Decida si el límite representa un registro, un párrafo o un ajuste visual antes de aplicar una operación de línea en todo el bloque.
Tampoco diagnostica la codificación de caracteres. Una marca de orden de bytes UTF-8, diamantes de reemplazo, mojibake y fallas de decodificación se refieren a cómo los bytes se convierten en caracteres, no a si CR o LF separa esos caracteres en filas. Conserve el archivo original e identifique su codificación con una herramienta de reconocimiento de archivos adecuada antes de tratar los símbolos visibles impares como finales de línea.
La conclusión: los finales de línea son una historia que puedes ver; Las herramientas de línea y el contador de Text Toolkit le permiten solucionar los síntomas en segundos
CR, LF y CRLF son controles históricos con consecuencias de compatibilidad actuales. El modelo mental más seguro es el de una línea lógica con varias representaciones físicas. Cuente registros, inspeccione la convención de origen e identifique la etapa que introdujo filas vacías o retuvo caracteres de control antes de eliminar algo.
Para material pegado, abra el kit de herramientas de texto en `/tools/text/`, observe el recuento de líneas inicial, aplique Eliminar líneas vacías solo cuando las filas vacías realmente no se deseen y use Recortar líneas solo para los espacios en blanco circundantes. Vuelva a verificar los registros de recuento y muestra después. Esa breve auditoría convierte un problema de formato invisible en una transformación de texto controlada y reversible.