Les concepts de retour chariot (CR) et de saut de ligne (LF) sont étroitement associés et peuvent être considérés séparément ou ensemble. Dans le support physique des machines à écrire et des imprimantes, deux axes de mouvement, «vers le bas» et «à travers», sont nécessaires pour créer une nouvelle ligne sur la page. Bien que la conception d’une machine (machine à écrire ou imprimante) doive les considérer séparément, la logique abstraite du logiciel peut les combiner en un seul événement. C’est pourquoi une nouvelle ligne dans le codage des caractères peut être définie comme CR et LF combinés en un seul (communément appelé CR + LF ou CRLF ).

Certains les jeux de caractères fournissent un code de caractère de nouvelle ligne distinct. EBCDIC, par exemple, fournit un code de caractère NL en plus des codes CR et LF. Unicode, en plus de fournir les codes de contrôle ASCII CR et LF, fournit également un code de contrôle « ligne suivante » (NEL), ainsi que des codes de contrôle pour les marqueurs « séparateur de ligne » et « séparateur de paragraphe ».

• Systèmes EBCDIC – principalement les systèmes mainframe IBM, y compris z / OS (OS / 390) et i5 / OS (OS / 400) – utilisent NL (Nouvelle ligne, 0x15) comme caractère combinant les fonctions de saut de ligne et de chariot revenir. Le caractère Unicode équivalent ( 0x85 ) est appelé NEL (Next Line). EBCDIC a également des caractères de contrôle appelés CR et LF, mais la valeur numérique de LF (0x25) diffère de celle utilisée par ASCII (0x0A). De plus, certaines variantes EBCDIC utilisent également NL mais attribuent un code numérique différent au caractère. Cependant, ces systèmes d’exploitation utilisent un système de fichiers basé sur les enregistrements, qui stocke les fichiers texte comme un enregistrement par ligne. Dans la plupart des formats de fichiers, aucune terminaison de ligne n’est réellement stockée.
• Les systèmes d’exploitation de la série CDC 6000 définissaient une nouvelle ligne comme deux caractères de six bits de valeur zéro ou plus à la fin d’un mot de 60 bits. Certaines configurations définissaient également un caractère de valeur zéro comme un caractère deux-points, avec le résultat que plusieurs deux-points pouvaient être interprétés comme une nouvelle ligne en fonction de la position.
• RSX-11 et OpenVMS utilisent également un système de fichiers basé sur les enregistrements , qui stocke les fichiers texte sous la forme d’un enregistrement par ligne. Dans la plupart des formats de fichier, aucune terminaison de ligne n’est réellement stockée, mais la fonction Record Management Services peut ajouter de manière transparente une terminaison à chaque ligne lorsqu’elle est récupérée par une application. Les enregistrements eux-mêmes peuvent contenir les mêmes caractères de fin de ligne, ce qui peut être considéré comme une fonctionnalité ou une nuisance selon l’application. RMS stockait non seulement les enregistrements, mais également les métadonnées stockées sur les séparateurs d’enregistrements dans différents bits pour que le fichier complique encore plus les choses (car les fichiers pouvaient avoir des enregistrements de longueur fixe, des enregistrements précédés d’un décompte ou des enregistrements terminés par un caractère spécifique ). Les bits n’étaient pas génériques, donc alors qu’ils pouvaient spécifier que CRLF ou LF ou même CR était le terminateur de ligne, il ne pouvait pas remplacer un autre code.
• Une longueur de ligne fixe a été utilisée par certains premiers gros systèmes d’exploitation systèmes. Dans un tel système, une fin de ligne implicite était supposée tous les 72 ou 80 caractères, par exemple. Aucun caractère de nouvelle ligne n’a été stocké. Si un fichier était importé du monde extérieur, les lignes plus courtes que la longueur de la ligne devaient être remplies d’espaces, tandis que les lignes plus longues que la longueur de la ligne devaient être tronquées. Cela imitait l’utilisation de cartes perforées, sur lesquelles chaque ligne était stockée sur une carte séparée, généralement avec 80 colonnes sur chaque carte, souvent avec des numéros de séquence dans les colonnes 73–80. Beaucoup de ces systèmes ont ajouté un caractère de contrôle de chariot au début de l’enregistrement suivant; cela pourrait indiquer si l’enregistrement suivant était une continuation de la ligne commencée par l’enregistrement précédent, ou une nouvelle ligne, ou devrait surimprimer la ligne précédente (similaire à un CR). Il s’agissait souvent d’un caractère d’impression normal tel que # qui ne pouvait donc pas être utilisé comme premier caractère d’une ligne. Certaines imprimantes de première ligne interprétaient ces caractères directement dans les enregistrements qui leur étaient envoyés.

UnicodeEdit

La norme Unicode définit un certain nombre de caractères que les applications conformes doivent reconnaître comme des terminateurs de ligne:

LF: Line Feed, U + 000A VT: Onglet vertical, U + 000B FF: Saut de page, U + 000C CR: Retour chariot, U + 000D CR + LF: CR (U + 000D) suivi de LF (U + 000A) NEL: Ligne suivante, U + 0085 LS: Séparateur de ligne, U + 2028 PS: Séparateur de paragraphe, U + 2029

Cela peut sembler trop compliqué par rapport à une approche telle que la conversion de tous les terminateurs de ligne en un seul caractère, par exemple LF. Cependant, Unicode a été conçu pour conserver toutes les informations lors de la conversion d’un fichier texte de tout encodage existant en Unicode et inversement. Par conséquent, Unicode doit contenir des caractères inclus dans les encodages existants.NL est inclus dans EBCDIC avec le code 0x15, et souvent mappé à NEL, qui est un caractère de contrôle dans le jeu de contrôle C1. En tant que tel, il est défini par ECMA 48, et reconnu par des codages conformes à la norme ISO / IEC 2022 (qui équivaut à ECMA 35). L’ensemble de contrôle C1 est également compatible avec ISO-8859-1. L’approche adoptée dans la norme Unicode permet à la transformation aller-retour de préserver les informations tout en permettant aux applications de reconnaître tous les types possibles de terminateurs de ligne.

Reconnaître et utiliser les codes de nouvelle ligne supérieurs à 0x7F (NEL, LS et PS) n’est pas souvent fait. Il s’agit de plusieurs octets en UTF-8, et le code pour NEL a été utilisé comme points de suspension (… ) dans Windows-1252. Par exemple:

• ECMAScript accepte LS et PS comme sauts de ligne, mais considère les espaces U + 0085 (NEL) au lieu d’un saut de ligne.
• Windows 10 ne traite aucun élément NEL, LS ou PS comme des sauts de ligne dans son éditeur de texte par défaut, le Bloc-notes.
• gedit, l’éditeur de texte par défaut de l’environnement de bureau GNOME , traite LS et PS comme des retours à la ligne, mais pas pour NEL.
• JSON autorise les caractères LS et PS dans les chaînes, alors qu’ECMAScript avant ES2019 les traitait comme des retours à la ligne, et donc une syntaxe illégale.
• YAML ne les reconnaît plus comme spéciaux à partir de la version 1.2, afin d’être compatible avec JSON.

Les caractères Unicode U + 2424 (SYMBOLE POUR NEWLINE, ␤ ), U + 23CE (SYMBOLE DE RETOUR, ⏎ ), U + 240D (SYMBOLE POUR CARRIAGE RETURN, ␍ ) et U + 240A (SYMBOL FOR LINE FEED, ␊ ) sont destinés à présenter un caractère visible par l’utilisateur au lecteur du document, et ne sont donc pas eux-mêmes reconnus comme une nouvelle ligne.

Séquences d’échappementModifier

Une séquence d’échappement est une combinaison de caractères qui ne représente aucun texte; au lieu d’être affiché (sous forme de texte), il est censé être intercepté par le programme et une fonction spéciale est censée être exécutée. Les séquences d’échappement sont également utilisées pour gérer (définir, rechercher, remplacer, etc.) les caractères spéciaux.

Dans les langages de programmation, éditez

Pour faciliter la création de programmes portables, les langages de programmation fournissent des abstractions pour gérer les différents types de séquences de saut de ligne utilisés dans différents environnements.

Le langage de programmation C fournit les séquences d’échappement « \ n » (nouvelle ligne) et « \ r » (retour chariot). Cependant, il n’est pas nécessaire que ceux-ci soient équivalents aux caractères de contrôle ASCII LF et CR. Le standard C ne garantit que deux choses:

1. Chacune de ces séquences d’échappement correspond à un numéro unique défini par l’implémentation qui peut être stocké dans une seule valeur de caractère.
2. Lors de l’écriture vers un fichier, un nœud de périphérique ou une socket / fifo en mode texte, « \ n » est traduit de manière transparente en la séquence de retour à la ligne native utilisée par le système, qui peut contenir plus d’un caractère. Lors de la lecture en mode texte, la séquence de retour à la ligne native est traduite en « \ n ». En mode binaire, aucune traduction n’est effectuée et la représentation interne produite par « \ n » est sortie directement.

Sur les plates-formes Unix, d’où C est originaire, la séquence de retour à la ligne native est ASCII LF ( 0x0A), donc « \ n » a été simplement défini comme étant cette valeur. La représentation interne et externe étant identique, la traduction effectuée en mode texte est un no-op, et Unix n’a aucune notion de mode texte ou de mode binaire. Cela a amené de nombreux programmeurs qui ont développé leur logiciel sur des systèmes Unix à ignorer complètement la distinction, ce qui a pour résultat un code qui n’est pas portable sur différentes plates-formes.

La fonction de bibliothèque C fgets () est mieux évitée en mode binaire car tout fichier non écrit avec la convention de nouvelle ligne Unix sera mal lu. De plus, en mode texte, tout fichier non écrit avec la séquence de nouvelle ligne native du système (tel qu’un fichier créé sur un système Unix, puis copié sur un système Windows) sera également mal lu.

Autre Le problème courant est l’utilisation de «\ n» lors de la communication à l’aide d’un protocole Internet qui impose l’utilisation d’ASCII CR + LF pour les lignes de fin. L’écriture de «\ n» dans un flux en mode texte fonctionne correctement sur les systèmes Windows, mais ne produit que LF sur Unix, et quelque chose de complètement différent sur les systèmes plus exotiques. L’utilisation de « \ r \ n » en mode binaire est légèrement meilleure.

Les bibliothèques d’E / S Java ne les traduisent pas de manière transparente en séquences de saut de ligne dépendant de la plate-forme sur à la place, ils fournissent des fonctions d’écriture d’une ligne complète qui ajoutent automatiquement la séquence de retour à la ligne native et des fonctions de lecture de lignes qui acceptent l’un des CR, LF ou CR + LF comme terminateur de ligne (voir BufferedReader.readLine () La méthode System.lineSeparator () peut être utilisée pour récupérer le séparateur de ligne sous-jacent.

Exemple:

 String eol = System.lineSeparator(); String lineColor = "Color: Red" + eol;

Python autorise « Universal Newline Support » lors de l’ouverture d’un fichier en lecture, lorsque lors de l’importation de modules et lors de l’exécution d’un fichier.

Certains langages ont créé des variables spéciales, des constantes et des sous-programmes pour faciliter les nouvelles lignes pendant l’exécution du programme. Dans certains langages tels que PHP et Perl, des guillemets doubles sont nécessaires pour effectuer une substitution d’échappement pour toutes les séquences d’échappement, y compris « \ n » et « \ r ». En PHP, pour éviter les problèmes de portabilité, les séquences de retour à la ligne doivent être émises en utilisant la constante PHP_EOL.

Exemple en C #:

 string eol = Environment.NewLine; string lineColor = "Color: Red" + eol; string eol2 = "\n"; string lineColor2 = "Color: Blue" + eol2;

Problèmes avec différents formats de nouvelle ligne Modifier

Même si les caractères de contrôle sont définis sans ambiguïté dans la table de codage de caractères correspondante utilisée par un fichier texte , il y a toujours un problème: il existe différentes conventions pour définir et afficher un saut de ligne.

Pour désigner un seul saut de ligne, les programmes Unix utilisent saut de ligne , dont la valeur hexadécimale en ASCII est 0a , alors que la plupart des programmes communs à MS-DOS et Microsoft Windows utilisent retour chariot + saut de ligne , dont la valeur hexadécimale en ASCII est 0d 0a . En ASCII, le retour chariot est un caractère de contrôle distinct.

Les différentes conventions de saut de ligne entraînent un affichage incorrect des fichiers texte qui ont été transférés entre des systèmes de différents types.

Texte dans les fichiers créés avec des programmes communs sur un système d’exploitation Unix ou Mac OS classique, apparaissent comme une seule longue ligne sur la plupart des programmes communs à MS-DOS et Microsoft Windows car ils n’affiche pas un seul saut de ligne ou un seul retour chariot comme saut de ligne.

À l’inverse, lors de la visualisation d’un fichier provenant d’un ordinateur Windows sur un système de type Unix, le CR supplémentaire peut être affiché comme deuxième saut de ligne, sous la forme ^ M, ou sous la forme < cr > à la fin de chaque ligne.

De plus, les programmes autres que les éditeurs de texte peuvent ne pas accepter un fichier, par exemple un fichier de configuration, encodé en utilisant la convention de nouvelle ligne étrangère, comme un fichier valide.

Le problème peut être difficile à repérer car certains programmes gèrent correctement les nouvelles lignes étrangères alors que d’autres ne le font pas. Par exemple, un compilateur peut échouer avec des erreurs de syntaxe obscures même si le fichier source semble correct lorsqu’il est affiché sur la console ou dans un éditeur. Sur un système de type Unix, la commande cat -v myfile.txt enverra le fichier à stdout (normalement le terminal) et rendra le ^ M visible, ce qui peut être utile pour le débogage. Les éditeurs de texte modernes reconnaissent généralement tous les types de sauts de ligne CR + LF et permettent aux utilisateurs de convertir entre les différentes normes. Les navigateurs Web sont généralement également capables d’afficher des fichiers texte et des sites Web qui utilisent différents types de sauts de ligne.

Même si un programme prend en charge différentes conventions de saut de ligne, ces fonctionnalités ne sont souvent pas suffisamment étiquetées, décrites ou documentées. En général, un menu ou une zone de liste déroulante énumérant différentes conventions de nouvelle ligne sera affiché aux utilisateurs sans indication si la sélection réinterprétera, convertira temporairement ou convertira définitivement les nouvelles lignes. Certains programmes convertiront implicitement lors de l’ouverture, du copier-coller ou de l’enregistrement – souvent de manière incohérente.

La plupart des protocoles Internet textuels (y compris HTTP, SMTP, FTP, IRC et bien d’autres) exigent l’utilisation d’ASCII CR + LF (« \ r \ n », 0x0D 0x0A) au niveau du protocole, mais recommande que les applications tolérantes reconnaissent également le LF isolé (« \ n », 0x0A). Malgré la norme dictée, de nombreuses applications utilisent à tort la séquence d’échappement de retour à la ligne C « \ n » (LF) au lieu de la combinaison correcte d’échappement de retour chariot et de séquences d’échappement de nouvelle ligne « \ r \ n » (CR + LF) (voir la section Nouvelle ligne dans langages de programmation ci-dessus). Cette utilisation accidentelle de mauvaises séquences d’échappement conduit à des problèmes lors de la tentative de communication avec des systèmes adhérant à l’interprétation plus stricte des normes au lieu de l’interprétation tolérante suggérée. Un de ces systèmes intolérants est l’agent de transfert de courrier qmail qui refuse activement d’accepter les messages provenant de systèmes qui envoient du LF nu au lieu du CR + LF requis.

Le format de message Internet standard pour les e-mails déclare: CR et LF DOIVENT se produisent uniquement ensemble en tant que CRLF; ils NE DOIVENT PAS apparaître indépendamment dans le corps.

Le protocole de transfert de fichiers peut convertir automatiquement les retours à la ligne dans les fichiers transférés entre des systèmes avec des représentations de nouvelle ligne différentes lorsque le transfert est effectué en « mode ASCII ».Cependant, le transfert de fichiers binaires dans ce mode a généralement des résultats désastreux: toute occurrence de la séquence d’octets de retour à la ligne – qui n’a pas de sémantique de terminaison de ligne dans ce contexte, mais fait simplement partie d’une séquence normale d’octets – sera traduite en n’importe quelle représentation de nouvelle ligne l’autre système utilise, corrompant effectivement le fichier. Les clients FTP utilisent souvent des heuristiques (par exemple, l’inspection des extensions de nom de fichier) pour sélectionner automatiquement le mode binaire ou ASCII, mais en fin de compte, il appartient aux utilisateurs de s’assurer que leurs fichiers sont transférés dans le bon mode. En cas de doute sur le mode correct, le mode binaire doit être utilisé, car aucun fichier ne sera modifié par FTP, bien qu’ils puissent s’afficher de manière incorrecte.

Conversion entre les formats de nouvelle ligne Modifier

Les éditeurs de texte sont souvent utilisés pour convertir un fichier texte entre différents formats de nouvelle ligne; la plupart des éditeurs modernes peuvent lire et écrire des fichiers en utilisant au moins les différentes conventions ASCII CR / LF. Par exemple, l’éditeur Vim peut rendre un fichier compatible avec l’éditeur de texte Windows Notepad. Dans vim

 :set fileformat=dos :wq

Les éditeurs peuvent ne pas convenir à la conversion de fichiers plus volumineux ou à la conversion en masse de nombreux fichiers. Pour les fichiers plus volumineux (sous Windows NT / 2000 / XP), la commande suivante est souvent utilisée:

D:\>TYPE unix_file | FIND /V "" > dos_file

Programmes spéciaux à convertir les fichiers entre les différentes conventions de nouvelle ligne incluent unix2dos et dos2unix, mac2unix et unix2mac, mac2dos et dos2mac, et flip.La commande tr est disponible sur pratiquement tous les systèmes de type Unix et peut être utilisée pour effectuer des opérations de remplacement arbitraires sur des caractères uniques. Un fichier texte DOS / Windows peut être converti au format Unix en supprimant simplement tous les caractères ASCII CR avec

$ tr -d "\r" < inputfile > outputfile

ou, si le texte n’a que des retours à la ligne CR, en conversion de toutes les nouvelles lignes CR en LF avec

$ tr "\r" "\n" < inputfile > outputfile

Les mêmes tâches sont parfois effectuées avec awk, sed ou en Perl si la plate-forme a un interpréteur Perl:

La commande file peut identifier le type de fin de ligne:

 $ file myfile.txt myfile.txt: ASCII English text, with CRLF line terminators

La commande Unix egrep (grep étendu) peut être utilisé pour imprimer les noms de fichiers de fichiers Unix ou DOS (en supposant uniquement des fichiers de style Unix et DOS, pas de Mac OS):

$ egrep -L "\r\n" myfile.txt # show UNIX style file (LF terminated)$ egrep -l "\r\n" myfile.txt # show DOS style file (CRLF terminated)

D’autres outils permettent à l’utilisateur de visualiser les caractères EOL:

$ od -a myfile.txt$ cat -e myfile.txt$ hexdump -c myfile.txt