CRLF n’est plus nécessaire et devrait être abandonné

Définition de carriage return et line feed

• Carriage return (CR) : déplace le curseur vers la marge gauche de la même ligne
• Line feed (LF) : déplace le curseur d’une ligne vers le bas et fait défiler les lignes précédentes vers le haut
• Nouvelle ligne (NL) : déplace le curseur d’une ligne vers le bas puis vers la marge gauche

Observations

• CR et NL sont des caractères de contrôle utiles. NL correspond à l’opération la plus courante : commencer une nouvelle ligne de texte à la marge gauche
• LF est en pratique inutile. Personne ne veut descendre à la ligne suivante depuis le milieu d’une ligne pour continuer à écrire dans la même colonne
• LF remonte à l’époque des téléscripteurs mécaniques, il y a environ 70 ans

Contexte historique

• Les téléscripteurs imprimaient environ 5 caractères par seconde
• La tradition du CRLF provient des limites mécaniques des téléscripteurs des années 1950
• À l’époque de Multix et Unix, l’idée que l’utilisation de CRLF comme NL était inefficace s’est répandue

Situation actuelle

• Aujourd’hui, CR est représenté par U+000d, tandis que LF et NL sont représentés par U+000a
• La plupart des machines modernes utilisent uniquement U+000a comme NL
• Certains protocoles exigent encore CRLF, mais la plupart des logiciels acceptent un simple NL

Appel à l’action

• Renommer le point de code U+000a en « nouvelle ligne » au lieu de « line feed »
• Cesser d’envoyer des CR inutiles
• Pour les protocoles qui exigent CRLF, n’envoyer que NL
• Corriger les logiciels qui génèrent une erreur lorsqu’ils reçoivent un NL sans CR

Résumé et auteur

• La fin de CRLF aurait dû arriver depuis longtemps. Nous devons agir ensemble pour éliminer cette relique d’un autre âge
• Auteur : D. Richard Hipp, créateur de SQLite

# Résumé GN⁺

• Cet article explique le contexte historique de CRLF et son inefficacité actuelle, et appelle à son abandon
• CRLF est une convention issue de contraintes mécaniques qui introduit aujourd’hui une complexité inutile
• Ce sujet peut être particulièrement utile aux programmeurs et aux développeurs logiciels, car il est important pour des transferts de données efficaces
• Même lors de l’utilisation d’autres protocoles ou systèmes aux fonctionnalités similaires, il vaut la peine de reconsidérer la nécessité de CRLF

[cosine20]

J’utilise parfois le saut de ligne...

[doolayer]

C’est vraiment radical, dis donc.

[savvykang]

Selon une correction du 14 octobre, la proposition de modification serait retirée.

Il ne s’agit pas simplement de changer un seul système, mais de modifier progressivement le protocole et tous les systèmes concernés ; à mes yeux, l’auteur a manqué de prudence.

[constexprif]

Ont-ils pensé que les bénéfices de sa suppression seraient supérieurs au coût de sa disparition ?

[alstjr7375]

CR+LF a une une longue histoire...

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

Oh... donc c’est pour cette raison...

[bakyeono]

Ce n’est pas que CRLF soit une spécification mal définie ; cela reflétait simplement l’environnement matériel de l’époque...
J’ai l’impression qu’on oublie la rétrocompatibilité pour ne penser qu’à l’instant présent.
Faudra-t-il revoir de fond en comble les protocoles chaque fois que les spécifications matérielles changent ?

[halfenif]

Je ne suis ni pour ni contre sa suppression.

Pourquoi est-ce que ça m’a fait penser au bug de l’an 2000 ?

[GN⁺]

Commentaire Hacker News

• Mettre à jour des protocoles existants vers NL peut introduire des bugs potentiels, et HTTP/1.1 a déjà été remplacé par HTTP/2
  • Il est soutenu qu’il est raisonnable de ne pas exiger CRLF dans les nouveaux protocoles, mais qu’il n’est pas nécessaire de mettre à jour les protocoles existants
• Ne pas respecter CRLF revient à introduire délibérément un bug
  • Le serveur HTTP de SQLite a été mis à jour pour utiliser \n au lieu de \r\n, mais cela a cassé la compatibilité avec le client HTTP de Zig
• Certains estiment qu’il faut faire en sorte que les générations futures n’aient plus à se soucier de CRLF
  • Ils affirment qu’il faut enseigner l’usage du fichier .gitattributes et apprendre à détester le Byte Order Mark
• Le choix non standard de terminaison de ligne par Unix était une erreur, et il a entraîné des problèmes de compatibilité pendant des décennies
  • CRLF correspond à deux parties différentes de l’API terminal, et de nombreux programmes dépendent du bon fonctionnement de CR et LF
• CRLF est l’un des éléments les moins importants des standards
  • Briser un standard est une approche nouvelle et, personnellement, cela semble inhabituel
• SMTP précise clairement que la séquence de fin de message est CR LF . CR LF, et il existe aussi des implémentations qui reconnaissent LF . LF
  • Il se peut que les règles d’origine de SMTP n’aient plus vraiment d’importance aujourd’hui
• CRLF peut présenter des risques pour de nombreux appareils, et il faudrait réduire les exceptions
• Aucune mention n’est faite des problèmes qui surviennent quand on mélange les terminaisons de ligne
  • Le caractère NL n’existe pas, et la touche "ENTER" de tous les claviers envoie CR
  • La manière actuelle fonctionne bien