CRLF ya no debería usarse y debe quedar obsoleto

Definición de retorno de carro y salto de línea

• Retorno de carro (CR): mueve el cursor al margen izquierdo de la misma línea
• Salto de línea (LF): mueve el cursor una línea hacia abajo y desplaza las líneas anteriores hacia arriba
• Nueva línea (NL): mueve el cursor una línea hacia abajo y lo lleva al margen izquierdo

Observaciones

• CR y NL son caracteres de control útiles. NL representa la operación más común: comenzar una nueva línea de texto desde el margen izquierdo
• LF es, en la práctica, inútil. Nadie quiere bajar a la siguiente línea desde la mitad de una línea y seguir escribiendo en la misma columna
• LF se originó hace unos 70 años, en la era de los teleimpresores mecánicos

Contexto histórico

• Los teleimpresores imprimían alrededor de 5 caracteres por segundo
• La tradición de CRLF proviene de las limitaciones mecánicas de los teleimpresores de los años 50
• En la era de Multix y Unix, se fue extendiendo la idea de que usar CRLF como NL era ineficiente

Situación moderna

• Hoy, CR se representa como U+000d, y LF y NL como U+000a
• La mayoría de las máquinas modernas usan U+000a únicamente como NL
• Algunos protocolos todavía exigen CRLF, pero la mayor parte del software acepta un solo NL

Llamado a la acción

• Cambiar el nombre del punto de código U+000a de "salto de línea" a "nueva línea"
• Dejar de transmitir CR innecesarios
• Enviar solo NL a los protocolos que requieren CRLF
• Corregir el software que genera errores al recibir NL sin CR

Resumen y autor

• El fin de CRLF debió llegar hace mucho. Debemos esforzarnos juntos para eliminar esta reliquia obsoleta
• Autor: D. Richard Hipp, creador de SQLite

# Resumen de GN⁺

• Este artículo explica el contexto histórico de CRLF y su ineficiencia en la actualidad, y pide su eliminación
• CRLF es una convención nacida de limitaciones mecánicas que hoy genera complejidad innecesaria
• Este tema puede ser especialmente útil para programadores y desarrolladores de software, y es importante para una transmisión de datos más eficiente
• Incluso al usar otros protocolos o sistemas con funciones similares, conviene replantear la necesidad de CRLF

[cosine20]

A veces uso line feed....

[doolayer]

Qué radical, wow.

[savvykang]

Según una corrección del 14 de octubre, se dice que retirarán la propuesta de cambio.

No se trata simplemente de cambiar un solo sistema, sino de modificar gradualmente el protocolo y todos los sistemas afectados, y a mí me parece que el autor no fue lo suficientemente prudente.

[constexprif]

¿Habrá pensado que el beneficio de eliminarlo era mayor que el costo de hacerlo?

[alstjr7375]

CR+LF tiene una larga historia...

• https://www.revk.uk/2022/02/crlf-has-long-history.html

Oh... con razón era por esto...

[bakyeono]

CRLF no es una especificación mal definida; más bien reflejaba el entorno de hardware de su época...
Parece que se olvidan de la compatibilidad hacia atrás y solo piensan en este momento.
¿Deberíamos rehacer los protocolos cada vez que cambian las especificaciones del hardware?

[halfenif]

No estoy ni a favor ni en contra de eliminarlo.

¿Por qué será que me hizo pensar en el error del milenio?

[GN⁺]

Opiniones de Hacker News

• Actualizar protocolos existentes para usar NL puede introducir errores potenciales, y HTTP/1.1 ya fue reemplazado por HTTP/2
  • Se argumenta que es razonable no exigir CRLF en protocolos nuevos, pero que no hace falta actualizar los protocolos existentes
• No cumplir con CRLF equivale a introducir errores de forma intencional
  • El servidor HTTP de SQLite fue actualizado para usar \r\n en lugar de \n, pero esto rompió la compatibilidad con el cliente HTTP de Zig
• Hay quienes opinan que deberíamos evitar que nuestros descendientes tengan que preocuparse por CRLF
  • Sostienen que hay que enseñar a usar archivos .gitattributes y educar a la gente para que deteste la marca de orden de bytes (Byte Order Mark)
• La elección no estándar de Unix para el fin de línea fue un error, y esto ha causado problemas de compatibilidad durante décadas
  • CRLF son dos partes distintas de la API de terminal, y muchos programas dependen del funcionamiento correcto de CR y LF
• CRLF es uno de los elementos menos importantes del estándar
  • Romper el estándar es un intento novedoso y, en lo personal, una actitud extraña
• SMTP deja claro que la secuencia de fin de mensaje es CR LF . CR LF, y también existen implementaciones que reconocen LF . LF
  • Puede que las reglas originales de SMTP ya no sean importantes
• CRLF puede representar un riesgo para muchos dispositivos, y habría que reducir las excepciones
• No se menciona el problema que ocurre cuando se mezclan finales de línea
  • No existe un carácter llamado NL, y la tecla "ENTER" de todos los teclados envía CR
  • La forma actual está funcionando bien