Nouvelle ligne - Newline

Nouvelle ligne insérée entre les mots "Hello" et "world"

Saut de ligne (souvent appelée ligne se terminant , en fin de ligne ( EOL ), la ligne suivante ( NEL ) ou saut de ligne ) est un caractère de contrôle ou d'une séquence de caractères de contrôle en une codage de caractères spécification (par exemple, ASCII , EBCDIC ) qui est utilisé pour signifier le fin d'une ligne de texte et le début d'une nouvelle, par exemple, Line Feed ( LF ) sous Unix . Certains éditeurs de texte définissent ce caractère spécial lorsque vous appuyez sur la touche. Enter

Lors de l'affichage (ou de l'impression) d'un fichier texte , ce caractère de contrôle ou cette séquence de caractères amène l'éditeur de texte à afficher les caractères qui le suivent dans une nouvelle ligne.

Histoire

Au milieu des années 1800, bien avant l'avènement des téléimprimeurs et des téléscripteurs, les opérateurs de code Morse ou les télégraphistes ont inventé et utilisé des prosignes de code Morse pour coder le formatage de texte d'espace blanc dans des messages texte écrits formels. En particulier , le Morse Prosign BT (mnémonique b Reak t ext) représenté par la concaténation de littéral codes Morse textuel « B » et les caractères « T » envoyés sans l'espacement inter-caractères normaux sont utilisés dans le code Morse pour coder et indiquer une nouvelle ligne ou une nouvelle section dans un message texte formel.

Plus tard, à l'ère des téléimprimeurs modernes , des codes de contrôle de jeu de caractères standardisés ont été développés pour faciliter le formatage des espaces blancs. L'ASCII a été développé simultanément par l' Organisation internationale de normalisation (ISO) et l'American Standards Association (ASA), cette dernière étant l'organisation qui a précédé l' American National Standards Institute (ANSI). Au cours de la période de 1963 à 1968, les projets de normes ISO soutenaient l'utilisation de CR + LF ou LF seul comme nouvelle ligne, tandis que les projets ASA ne prenaient en charge que CR + LF .

La séquence CR + LF était couramment utilisée sur de nombreux premiers systèmes informatiques qui avaient adopté des machines Teletype - généralement un Teletype modèle 33 ASR - en tant que périphérique de console, car cette séquence était nécessaire pour positionner ces imprimantes au début d'une nouvelle ligne. La séparation du saut de ligne en deux fonctions masquait le fait que la tête d'impression ne pouvait pas revenir de l'extrême droite au début de la ligne suivante à temps pour imprimer le caractère suivant. Tout caractère imprimé après un CR s'imprimait souvent comme une tache au milieu de la page alors que la tête d'impression ramenait encore le chariot à la première position. "La solution consistait à créer deux caractères de nouvelle ligne : CR pour déplacer le chariot vers la première colonne et LF pour déplacer le papier vers le haut." En fait, il était souvent nécessaire d'envoyer des caractères supplémentaires (CR ou NUL superflus) qui sont ignorés mais laissent à la tête d'impression le temps de se déplacer vers la marge de gauche. De nombreux premiers affichages vidéo nécessitaient également plusieurs caractères pour faire défiler l'affichage.

Sur de tels systèmes, les applications devaient parler directement à la machine Teletype et suivre ses conventions car le concept de pilotes de périphériques cachant ces détails matériels à l'application n'était pas encore bien développé. Par conséquent, le texte a été systématiquement composé pour satisfaire les besoins des machines de télétype. La plupart des systèmes de mini-ordinateurs de DEC utilisaient cette convention. CP/M l' utilisait également pour imprimer sur les mêmes terminaux que les mini-ordinateurs. De là , MS-DOS (1981) a adopté CP / M « s CR + LF pour être compatibles, et cette convention a été hérité par la suite de Microsoft de Windows système d' exploitation.

Le système d' exploitation Multics a commencé son développement en 1964 et utilisait LF seul comme nouvelle ligne. Multics utilisait un pilote de périphérique pour traduire ce caractère en n'importe quelle séquence dont une imprimante avait besoin (y compris des caractères de remplissage supplémentaires), et le seul octet était plus pratique pour la programmation. Ce qui semble être un choix plus évident - CR - n'a pas été utilisé, car CR offrait la fonction utile de surimprimer une ligne avec une autre pour créer des effets en gras et barrés . Peut-être plus important encore, l'utilisation de la LF seule comme terminaison de ligne avait déjà été incorporée dans les projets de l'éventuelle norme ISO/IEC 646 . Unix a suivi la pratique Multics, et plus tard les systèmes de type Unix ont suivi Unix. Cela a créé des conflits entre Windows et les systèmes d'exploitation de type Unix , dans lesquels les fichiers composés sur un système d'exploitation ne peuvent pas être correctement formatés ou interprétés par un autre système d'exploitation (par exemple, un script shell UNIX écrit dans un éditeur de texte Windows comme le Bloc-notes ).

Représentation

Les concepts de retour chariot (CR) et de saut de ligne (LF) sont étroitement associés et peuvent être considérés soit séparément, soit ensemble. Dans les supports physiques des machines à écrire et des imprimantes , deux axes de mouvement, « vers le bas » et « en 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 de caractères peut être définie comme CRet LFcombinée en une seule (communément appelée CR+LFou CRLF).

Certains 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 ».

Applications logicielles et représentation du système d'exploitation d'une nouvelle ligne avec un ou deux caractères de contrôle
Système opérateur Encodage de caractère Abréviation valeur hexadécimale valeur déc Séquence d'échappement
Systèmes Unix et de type Unix ( Linux , macOS , FreeBSD , AIX , Xenix , etc.), Multics , BeOS , Amiga , RISC OS et autres ASCII LF 0A dix \n
Microsoft Windows , DOS ( MS-DOS , PC DOS , etc.), Atari TOS , DEC TOPS-10 , RT-11 , CP/M , MP/M , OS/2 , Symbian OS , Palm OS , Amstrad CPC et la plupart des autres premiers systèmes d'exploitation non-Unix et non-IBM CR LF 0D 0A 13 10 \r\n
Machines Commodore 8 bits ( C64 , C128 ) , Acorn BBC , ZX Spectrum , TRS-80 , série Apple II , Oberon , le Mac OS classique , MIT Lisp Machine et OS-9 RC 0D 13 \r
Implémentation QNX pré-POSIX (version < 4) RS 1E 30 \036
Sortie de texte spoulée Acorn BBC et RISC OS LF CR 0A 0D 10 13 \n\r
Machines Atari 8 bits ATASCII 9B 155
Systèmes mainframe IBM , y compris z/OS ( OS/390 ) et IBM i ( OS/400 ) EBCDIC Pays-Bas 15 21 \025
ZX80 et ZX81 (ordinateurs domestiques de Sinclair Research Ltd ) utilisé un jeu de caractères non ASCII spécifique NOUVELLE LIGNE 76 118
  • Les systèmes EBCDIC —principalement les systèmes mainframe IBM , y compris z/OS ( OS/390 ) et IBM i ( OS/400 )—utilisent NL (New Line, 0x15 ) comme caractère combinant les fonctions de saut de ligne et de retour chariot. 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 sous la forme d'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 ou plusieurs caractères de six bits de valeur zéro à la fin d'un mot de 60 bits. Certaines configurations ont également défini un caractère de valeur zéro en tant que caractère deux - points , avec pour résultat que plusieurs deux-points pourraient ê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 des enregistrements, qui stocke les fichiers texte sous la forme d'un enregistrement par ligne. Dans la plupart des formats de fichiers, 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 pourraient contenir les mêmes caractères de fin de ligne, ce qui pourrait être considéré comme une caractéristique ou une nuisance selon l'application. RMS a non seulement stocké des enregistrements, mais a également stocké des métadonnées sur les séparateurs d'enregistrements dans différents bits pour que le fichier complique encore plus les choses (puisque les fichiers peuvent avoir des enregistrements de longueur fixe, des enregistrements préfixés par un nombre 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 CR LF ou LF ou même CR était le terminateur de ligne, il ne pouvait pas substituer un autre code.
  • La longueur de ligne fixe était utilisée par certains des premiers systèmes d' exploitation mainframe . 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é enregistré. Si un fichier était importé du monde extérieur, les lignes plus courtes que la longueur de ligne devaient être remplies d'espaces, tandis que les lignes plus longues que la longueur de ligne devaient être tronquées. Cela imitait l'utilisation de cartes perforées , sur lesquelles chaque ligne était stockée sur une carte distincte, 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 (semblable à un CR ). Il s'agissait souvent d'un caractère d'impression normal tel que #celui qui ne pouvait donc pas être utilisé comme premier caractère d'une ligne. Certaines des premières imprimantes en ligne interprétaient ces caractères directement dans les enregistrements qui leur étaient envoyés.

Unicode

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

  LF :   Alimentation de ligne, 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 paragraphes, U+2029

Cela peut sembler trop compliqué par rapport à une approche telle que la conversion de toutes les fins de ligne en un seul caractère, par exemple LF . Cependant, Unicode a été conçu pour préserver toutes les informations lors de la conversion d'un fichier texte à partir de n'importe quel encodage existant vers Unicode et inversement. Par conséquent, Unicode doit contenir des caractères inclus dans les encodages existants.

Par exemple : NL fait partie de EBCDIC , qui utilise le code 0x15 ; il est normalement mappé sur Unicode NEL , 0x85 , qui est un caractère de contrôle dans le jeu de contrôle C1. A ce titre, il est défini par l'ECMA 48, et reconnu par des encodages conformes à la norme ISO/IEC 2022 (qui équivaut à l'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 terminaisons de ligne.

Reconnaître et utiliser les codes de saut de ligne supérieurs à 0x7F ( NEL , LS et PS ) n'est pas souvent fait. Ce sont plusieurs octets en UTF-8 , et le code pour NEL a été utilisé comme caractère de suspension ( ) dans Windows-1252 . Par exemple:

  • ECMAScript accepte LS et PS comme sauts de ligne, mais prend en compte les espaces blancs U+0085 ( NEL ) au lieu d'un saut de ligne.
  • Windows 10 ne traite aucun des 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 nouvelles lignes mais pas pour NEL .
  • JSON autorise les caractères LS et PS dans les chaînes, tandis qu'ECMAScript avant ES2019 les traitait comme des nouvelles lignes, et donc une syntaxe illégale.
  • YAML ne les reconnaît plus comme spéciales à partir de la version 1.2, afin d'être compatible avec JSON .

Notez bien que les caractères spéciaux Unicode U+2424 ( SYMBOL FOR NEWLINE , ), U+23CE ( RETURN SYMBOL , ), U+240D ( SYMBOL FOR CARRIAGE RETURN , ) et U+240A ( SYMBOL FOR LINE FEED , ) sont des glyphes destinés pour présenter un caractère visible par l'utilisateur au lecteur du document, et ne sont donc pas eux-mêmes reconnus comme un saut de ligne.

Séquences d'échappement

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.

Séquences d'échappement
Caractère spécial Séquence d'échappement Utilisé par ... Exemples
line feed \n Perl , Vim , ... Vim : :%s/}/}\r\t/g= remplacer chaque caractère '}' par '} tabulateur de nouvelle ligne' dans l'ensemble du fichier
carriage return \r
tabulator \t

Dans les langages de programmation

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

Le langage de programmation C fournit les séquences d'échappement '\n' (nouvelle ligne) et '\r' (retour chariot). Cependant, ceux-ci ne doivent pas nécessairement être équivalents aux caractères de contrôle ASCII LF et CR . La norme 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 char .
  2. Lors de l'écriture dans 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 saut de ligne native utilisée par le système, qui peut être plus longue qu'un caractère. Lors de la lecture en mode texte, la séquence de saut de ligne native est retranscrite 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 nouvelle ligne native est ASCII LF ( 0x0A ), donc '\n' a simplement été 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 poussé de nombreux programmeurs qui ont développé leur logiciel sur des systèmes Unix à ignorer complètement la distinction, résultant en un code qui n'est pas portable sur différentes plates-formes.

Il est préférable d'éviter la fonction de bibliothèque C fgets () en mode binaire car tout fichier non écrit avec la convention de retour à la ligne Unix sera mal lu. De plus, en mode texte, tout fichier non écrit avec la séquence de retour à la ligne native du système (comme un fichier créé sur un système Unix, puis copié sur un système Windows) sera également mal lu.

Un autre problème courant est l'utilisation de '\n' lors de la communication à l'aide d'un protocole Internet qui impose l'utilisation de 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 des systèmes plus exotiques. L'utilisation de "\r\n" en mode binaire est légèrement meilleure.

De nombreux langages, tels que C++ , Perl et Haskell fournissent la même interprétation de '\n' que C. C++ a un modèle d'E/S alternatif où le manipulateur std::endl peut être utilisé pour afficher une nouvelle ligne (et vide le flux amortir).

Java , PHP et Python fournissent la séquence '\r\n' (pour ASCII CR + LF ). Contrairement à C, ceux-ci sont garantis pour représenter les valeurs U+000D et U+000A , respectivement.

Les bibliothèques d'E/S Java ne les traduisent pas de manière transparente en séquences de saut de ligne dépendantes de la plate-forme en entrée ou en sortie. Au lieu de cela, ils fournissent des fonctions pour écrire une ligne complète qui ajoutent automatiquement la séquence de retour à la ligne native, et des fonctions pour lire des lignes qui acceptent n'importe lequel de 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, 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 retours à la ligne lors de 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 saut de ligne doivent être émises à l'aide de 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 les différents formats de saut de ligne

Un fichier texte créé avec gedit et visualisé avec un éditeur hexadécimal . Outre les objets texte, il n'y a que des marqueurs EOL avec la valeur hexadécimale 0A.

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 line feed, dont la valeur hexadécimale en ASCII est 0a, tandis que la plupart des programmes communs à MS-DOS et Microsoft Windows utilisent carriage return+ line feed, 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 types différents.

Le texte dans les fichiers créés avec des programmes communs à Unix ou à un Mac OS classique apparaît sous la forme d'une seule longue ligne sur la plupart des programmes communs à MS-DOS et Microsoft Windows car ceux-ci n'affichent pas un seul line feedou un seul carriage returnsaut de ligne.

Inversement, 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 un deuxième saut de ligne, comme ^M ou comme <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 saut de ligne étrangère, comme 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 toutes les variantes des nouvelles lignes 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 nouvelles lignes.

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. Généralement, un menu ou une liste déroulante énumérant différentes conventions de saut de ligne sera affiché aux utilisateurs sans indiquer si la sélection réinterprétera, convertira temporairement ou convertira définitivement les sauts de ligne. Certains programmes seront implicitement convertis lors de l'ouverture, de la copie, du collage 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) imposent l'utilisation de ASCII CR + LF ( '\r\n' , 0x0D 0x0A ) au niveau du protocole, mais recommandent que les applications tolérantes reconnaissent LF solitaire ( '\n' , 0x0A ) également. Malgré la norme dictée, de nombreuses applications utilisent à tort la séquence d'échappement de nouvelle ligne C '\n' ( LF ) au lieu de la combinaison correcte de séquences d'échappement de retour chariot et d'échappement de nouvelle ligne '\r\n' ( CR + LF ) (voir la section Nouvelle ligne dans langages de programmation ci-dessus). Cette utilisation accidentelle de séquences d'échappement erronées entraîne des problèmes lorsque l'on essaie de communiquer avec des systèmes adhérant à l'interprétation plus stricte des normes au lieu de l'interprétation tolérante suggérée. L'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 indique : « CR et LF DOIVENT seulement apparaître 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 les systèmes avec différentes représentations de retour à la ligne 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 nouvelle ligne - qui n'a pas de sémantique de fin 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 efficacement 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, c'est 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

Les éditeurs de texte sont souvent utilisés pour convertir un fichier texte entre différents formats de saut de 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 être adaptés à 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

Les programmes spéciaux pour convertir des fichiers entre 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 convertissant tous les retours à la ligne 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 plateforme dispose d'un interpréteur Perl :

$ awk '{sub("$","\r\n"); printf("%s",$0);}' inputfile > outputfile  # UNIX to DOS  (adding CRs on Linux and BSD based OS that haven't GNU extensions)
$ awk '{gsub("\r",""); print;}' inputfile > outputfile              # DOS to UNIX  (removing CRs on Linux and BSD based OS that haven't GNU extensions)
$ sed -e 's/$/\r/' inputfile > outputfile              # UNIX to DOS  (adding CRs on Linux based OS that use GNU extensions)
$ sed -e 's/\r$//' inputfile > outputfile              # DOS  to UNIX (removing CRs on Linux based OS that use GNU extensions)
$ perl -pe 's/\r?\n|\r/\r\n/g' inputfile > outputfile  # Convert to DOS
$ perl -pe 's/\r?\n|\r/\n/g'   inputfile > outputfile  # Convert to UNIX
$ perl -pe 's/\r?\n|\r/\r/g'   inputfile > outputfile  # Convert to old Mac

La commande file permet d'identifier le type de fin de ligne :

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

La commande Unix egrep (extension grep) peut être utilisée pour imprimer les noms 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

Interprétation

Deux façons d'afficher les retours à la ligne, qui sont tous deux cohérents , sont que les retours à la ligne séparent les lignes ou qu'ils terminent les lignes. Si un saut de ligne est considéré comme un séparateur, il n'y aura pas de saut de ligne après la dernière ligne d'un fichier. Certains programmes ont des problèmes pour traiter la dernière ligne d'un fichier s'il n'est pas terminé par une nouvelle ligne. D'un autre côté, les programmes qui s'attendent à ce que la nouvelle ligne soit utilisée comme séparateur interpréteront une nouvelle ligne finale comme le début d'une nouvelle ligne (vide). Inversement, si une nouvelle ligne est considérée comme un terminateur, toutes les lignes de texte, y compris la dernière, doivent se terminer par une nouvelle ligne. Si la séquence de caractères finale dans un fichier texte n'est pas une nouvelle ligne, la dernière ligne du fichier peut être considérée comme une ligne de texte incorrecte ou incomplète, ou le fichier peut être considéré comme tronqué de manière incorrecte.

Dans le texte destiné principalement à être lu par des humains à l'aide d'un logiciel qui implémente la fonction de retour à la ligne, un caractère de nouvelle ligne ne doit généralement être stocké que si un saut de ligne est requis, indépendamment du fait que le mot suivant puisse tenir sur la même ligne, par exemple entre les paragraphes et dans les listes verticales. Par conséquent, dans la logique du traitement de texte et de la plupart des éditeurs de texte , le saut de ligne est utilisé comme un saut de paragraphe et est connu sous le nom de "retour forcé", contrairement aux "retours progressifs" qui sont créés dynamiquement pour implémenter le retour à la ligne et sont modifiables à chaque instance d'affichage. Dans de nombreuses applications, un caractère de contrôle distinct appelé "saut de ligne manuel" existe pour forcer les sauts de ligne à l'intérieur d'un seul paragraphe. Le glyphe du caractère de contrôle pour un retour ferme est généralement un pilcrow (¶), et pour le saut de ligne manuel est généralement une flèche de retour chariot (↵).

Sauts de ligne inversés et partiels

RI , ( U +008D REVERSE LINE FEED, ISO/IEC 6429 8D, decimal 141) est utilisé pour reculer la position d'impression d'une ligne (en faisant avancer le papier ou en déplaçant un curseur d'affichage vers le haut d'une ligne) afin que les autres caractères peut être imprimé sur du texte existant. Cela peut être fait pour les rendre plus gras, ou pour ajouter des soulignements, des barrés ou d'autres caractères tels que des signes diacritiques .

De même, PLD ( U +008B PARTIEL LIGNE AVANT, décimal 139) et PLU ( U +008C PARTIEL LIGNE ARRIÈRE, décimal 140) peuvent être utilisés pour avancer ou inverser la position d'impression du texte d'une fraction de l'interligne vertical (généralement, la moitié ). Ceux-ci peuvent être utilisés en combinaison pour les indices (en avançant puis en inversant) et les exposants (en inversant puis en avançant), et peuvent également être utiles pour imprimer des signes diacritiques.

Voir également

Les références

Liens externes