CRLF vs. LF sous Windows : convertissez, configurez et évitez les tracas liés au projet

Si vous travaillez sous Windows et alternez les projets avec des personnes de Linux ou macOS, tôt ou tard vous vous retrouverez dans la bataille éternelle CRLF contre LFParfois, cela ressemble à de la magie noire : vous modifiez un fichier, ne changez rien de « visible », et Git marque la moitié du fichier comme modifié. Rassurez-vous, ce n'est pas de la sorcellerie ; c'est la fins de ligne jouer contre toi.

Pour vous éviter des maux de tête, il est utile de comprendre ce qui se cache en dessous et comment s'adapter. Git, vos éditeurs et vos outils afin que chaque fichier arrive « propre » au dépôt, sans modifications fantômes ni erreurs étranges lors des CI/CD ou des scripts. Dans ce guide, je vous explique en détail et de manière concise comment convertir, configurer et normaliser CRLF et LF sur Windows sans perdre le temps.

Que sont LF et CRLF et pourquoi sont-ils importants ?

Les fins de ligne sont des caractères de contrôle qui délimitent chaque ligne dans un fichier texte : LF (\n, ASCII 10) y CRLF (\r\n, ASCII 13+10)Sur les systèmes de type Unix (Linux, macOS), il est utilisé LF, tandis que Windows utilise CRLF hérité des imprimantes et des machines à écrire : d'abord le retour chariot (CR), puis le saut de ligne (LF).

Le choix n’est pas esthétique : passer d’un format à un autre peut entraîner différences artificielles, des scripts qui échouent avec le message « commande introuvable », des pipelines qui plantent lors de l'exécution de fichiers enregistrés avec CRLF sous Linux, ou des éditeurs qui affichent tout sur une seule ligne. Oui, vous ouvrez un fichier .sh avec CRLF dans Bash et tu peux avoir une bonne frayeur.

Pour couronner le tout, Unicode reconnaît davantage de séparateurs (NEL U+0085, LS U+2028, PS U+2029, VT U+000B, FF U+000C), mais dans le développement quotidien, le véritable duel est CRLF contre LF. Cependant, savoir qu'ils existent aide quand on tombe sur des textes de ordinateurs centraux ou des fichiers étranges qu'un éditeur plus ancien n'interprète pas bien.

Autre curiosité technique utile : un saut peut être traité comme séparateur (entre les lignes) ou comme terminateur (marque la fin). Cette subtilité explique pourquoi on voit parfois une dernière ligne insécable ou des lignes vides supplémentaires lorsque l'on mélange des outils. Si vous avez besoin d'apprendre à rechercher et remplacer les sauts de paragraphe, soyez prudent, car certains analyseurs s'attendent à une chose ou à une autre.

Différences selon le système et problèmes typiques

Sous Windows, la chose normale est CRLF; sur Linux et macOS, LF. Ce conflit est immédiatement perceptible dans une équipe mixte : quelqu'un modifie un fichier avec son système, l'enregistre, et le diff est rempli de modifications qui sont en fait uniquement les fins de ligneSur le plan pratique, cela complique vos examens médicaux et contamine votre historique.

Il existe également des effets secondaires : scénario L'exécution de CRLF dans un environnement Unix peut échouer avec des erreurs cryptiques, ou une tâche peut s'interrompre en CI à cause d'une mauvaise interprétation des résultats par un shell. À l'inverse, l'ouverture d'un fichier contenant uniquement CRLF dans d'anciens éditeurs sous Windows peut entraîner des erreurs. l'aplatir en une ligne.

Soyez prudent avec les outils d'intégration continue comme Jenkins ou GitHub Actions : si la build s'exécute sous Linux mais que vous téléchargez des fichiers avec des fins de ligne incohérentes, vous pouvez briser le pipeline Même si « tout fonctionne sur ma machine », plus d'une personne a perdu des heures à cause de cela.

La bonne nouvelle est qu’il existe une recette claire : établir une convention et la mettre en œuvre. les outils l'appliquent seuls. Cela se produit via Git et votre éditeur. Et si le mal est déjà fait, renormaliser le repo.

Au fait, les éditeurs modernes comme VS Code affichent le type de saut dans la barre d'état et vous permettent de le modifier à la volée ; c'est une bouée de sauvetage lorsque vous repérez des fichiers « coupés en croix » et que vous souhaitez mettre les choses en ordre rapidement, ou quand vous en avez besoin éviter les sauts de page et les mises en forme inattendues lors du collage de texte dans des documents.

Git et fins de ligne : core.autocrlf et .gitattributes

Git peut convertir automatiquement les fins de ligne pour préserver la clarté de votre historique et éviter les mauvaises surprises. L'essentiel est l'option. noyau.autocrlf, qu'il faut bien comprendre avant de le toucher, et savoir que la configuration peut être au niveau de défis o locales à partir du référentiel (règles locales).

Vérifiez vos paramètres globaux avec -mondial N'oubliez pas que le dépôt peut avoir une valeur différente. Pour tout visualiser globalement, utilisez git config –list –globalSi vous constatez un comportement étrange dans le dépôt, vérifiez la valeur locale et donnez-lui la priorité selon ce dont vous avez besoin.

Modes Core.autocrlf en termes pratiques (Windows vs Unix) : oui convertit en CRLF lors de l'extraction et revient en LF lors de la validation ; contribution convertir uniquement en LF lors de la validation (excellent sur Linux/macOS) ; non ne touche à rien (et c'est généralement une solution rapide si l'équipe est mixte). Sous Windows, la solution la plus judicieuse est oui si vous ne voulez pas de surprises.

Commandes utile pour ajuster et nettoyer la situation de votre dépôt sans trop le gâcher : si vous souhaitez que le dépôt utilise la valeur globale, élimination la clé locale ; si vous préférez forcer une valeur dans ce dépôt, définissez-la sans -mondialPour réparer les fichiers déjà mélangés, renormalisez et validez les modifications de fin de ligne ensemble.

git config --list --global
# Ver el valor global efectivo

git config --unset core.autocrlf
# Quitar el valor local y heredar el global

git config core.autocrlf true
# Fijar el valor solo en el repo actual (Windows)

git add --renormalize .
# Recorrerá el repo y homogeneizará line endings según la config

git commit -m 'Homogeneizados los cambios de línea'
# Sube un solo commit de normalización

Mais il y a quelque chose d'encore mieux : un .gitattributes dans la racine qui accompagne le code. Avec la règle * texte=auto Vous indiquez à Git de détecter les fichiers texte et de gérer les sauts de ligne en conséquence (LF dans le dépôt ; CRLF dans la copie de travail Windows, le cas échéant). Vous pouvez également affiner l'extension, par exemple en forçant Git à gérer les sauts de ligne en conséquence. .sln de Visual Studio pour rester toujours en tant que CRLF.

* text=auto
# Homogeneiza automáticamente (LF en el repo)

*.sln text eol=crlf
# Asegura CRLF en soluciones de Visual Studio

Lorsque vous introduisez .gitattributes dans un dépôt déjà en ligne, n'oubliez pas de git add –renormalize . et regrouper les commits. De cette façon, vous évitez que chaque contributeur génère son propre « méga-commit de nettoyage ». C'est une de ces tâches que l'on effectue une seule fois. ça enlève tes problèmes pendant des années.

Configurer l'éditeur : VS Code, EditorConfig et Visual Studio

Votre éditeur peint aussi beaucoup. Code VS Vous pouvez définir le saut de ligne à partir de la barre d'état ou avec l'option fichiers.eolSi votre projet utilise LF, sélectionnez-le et c'est tout ; l'éditeur l'enregistrera ainsi sans que vous ayez à parcourir chaque fichier. C'est rapide et vous évite les différences bruyantes.

Si tous les membres de l’équipe utilisent un éditeur différent, incorporez-le ÉditeurConfig (.editorconfig) à la racine est une véritable aubaine : il définit des règles comme les fins de ligne, l'encodage et les espaces/tabulations de manière cohérente. La plupart des éditeurs modernes le respectent et il s'intègre parfaitement à Git et à l'intégration continue.

Pour ceux qui utilisent Visual Studio, il existe un panneau spécifique pour enregistrer avec un encodage et un saut de ligne spécifiques (Options d'enregistrement avancées). Vous pouvez accéder au menu déroulant Fichier > Enregistrer sous > Enregistrer. Enregistrer avec l'encodage, et aussi placer Options de sauvegarde avancées directement dans le menu Fichier pour un accès rapide.

1. Ouvre Outils > Personnaliser.
2. Cliquez sur l'onglet Commandeschoisir Barre de menu et sélectionnez armoires de bureau.
3. Cliquez Ajouter une commande, Catégorie armoires de bureauet ajouter Options de sauvegarde avancées.
4. Repositionner avec Télécharger/Télécharger et fermez-le. Vous l'avez prêt.

Avec Visual Studio, vous pouvez également rencontrer des fichiers utilisant d'autres séparateurs (NEL, LS, PS). L'IDE essayer de les normaliser Lorsqu'il détecte des incohérences, il vous demandera des instructions. Définir correctement les attributs .git et les options d'enregistrement évite que votre projet ne soit infesté de « cas exotiques ».

Au-delà du CRLF et du LF : NEL, LS, PS et compagnie

Unicode considère certains points de code supplémentaires comme des fins de ligne : NEL (U+0085), LS (U+2028) y PS (U+2029), Plus VT (U+000B) y FF (U+000C)Ils ne sont pas courants dans les projets d'application/web, mais ils apparaissent dans Mainframes IBM (EBCDIC) et dans certains documents traités avec des outils plus anciens ou de niche.

Pour des raisons de compatibilité, Unicode réplique les anciens contrôles ASCII avec la même valeur numérique (CR et LF) et en ajoute de nouveaux pour des conversions sans perte entre les encodages (par exemple, le mappage). EBCDIC Pays-Bas vers Unicode NEL). Si vous obtenez un fichier « étrange », un éditeur moderne affichera ou demandera généralement normalizar.

Dans les anciennes versions du Bloc-notes de Windows, cela ne fonctionne même pas. LF Le système fonctionnait bien ; le support est aujourd'hui bien meilleur, mais NEL pose encore problème dans certains environnements. Par conséquent, pour les dépôts et l'intégration continue, conservez tout. LF dans le repo et laisser à Git/éditeurs le CRLF de la copie de travail sous Windows est la décision gagnante.

Langages de programmation et sauts de ligne (\r, \n et traps)

Dans les chaînes de texte, de nombreux langages autorisent les séquences d'échappement : \n = LF, \r = CR. Avec cela, vous pouvez composer CRLF avec \r\n si nécessaire, ou insérer un LF « propre » avec \n. Attention, car tous les environnements d'exécution ne se comportent pas de la même manière.

Cas à garder à l'esprit : dans Java, en plus de \r et \n, vous avez %n (formateurs) et System.lineSeparator() pour obtenir le saut de ligne système de manière portable ; dans C#, Environnement.NewLine fait la même chose; dans PHP Existe PHP_EOL; Dans Python, os.linesep. Si vous souhaitez imprimer en fonction de la plateforme, utilisez ces constantes à la place de épouser CRLF.

Soins particuliers avec C et C ++: En mode texte, la séquence \n peut être mappée au saut de ligne système (sous Windows, CRLF), et si vous imprimez \r\n, vous risquez de générer CRCRLFEn mode binaire, la chose est littérale. Cette subtilité surprend beaucoup de gens lors de la compilation sous Windows et des tests sous Linux.

En JavaScript / TypeScript, \n est généralement suffisant pour la plupart des utilisations, mais si vous traitez des entrées provenant d'utilisateurs Windows, vous verrez \r\n et devrez normaliser les sauts de ligne. De plus, lors de la génération HTML, la mise en page finale est contrôlée par les balises (p., br, p, h2…), pas les caractères \r ou \n.

// C#
var s1 = "Primera\nSegunda";            // LF explícito
var s2 = "Primera" + Environment.NewLine + "Segunda"; // Salto del sistema

// Java
String a = "Uno\r\nDos";                 // CRLF explícito
String b = "Uno" + System.lineSeparator() + "Dos";    // Portátil

// Python
s = 'Linea1' + os.linesep + 'Linea2'

// JavaScript
const t = 'L1\nL2'; // Normaliza entrada si viene con \r\n

Si vous générez du trafic réseau, n’oubliez pas que des protocoles tels que HTTP, SMTP, FTP ou IRC sont exhaustifs : les titres et de nombreuses lignes de contrôle vont de pair CRLF Oui ou oui. Pas d'« inventions » : ajustez la sortie à la RFC ou vous trouverez des serveurs qui rejeter les demandes.

Comment détecter et convertir de manière fiable les fins de ligne

Il n’existe pas de « BOM » qui vous indique le type de saut de ligne dans un fichier : vous devez regarde les octetsEn pratique, les outils comptent CR (0x0D) et LF (0x0A) et voient leurs modèles : s'ils apparaissent appariés, il s'agit généralement de CRLF ; si seul 0x0A apparaît, il s'agit de LF ; s'il y a un mélange incohérent, vous avez un fatras cela devrait être corrigé.

Certains éditeurs détectent ce problème et vous en informent ; VS Code l'affiche dans la barre d'état ; Visual Studio peut proposer de le normaliser. Dans Git, la solution la plus sûre consiste à définir .gitattributes et, si nécessaire, renormalisez pour aligner l'arbre entier sur la politique. Votre référentiel (et vos révisions) vous en seront reconnaissants.

Et si vous travaillez avec des « formats exotiques » ? Des éditeurs comme Notepad++ et VS Code gèrent bien les CRLF et les LF, et les identifient généralement. LS/PSPour les cas NEL et EBCDIC, vous devrez parfois passer par un conversion précédente de codage en plus du saut de ligne.

La stratégie gagnante dans la plupart des projets est simple : sauvegarder dans le dépôt avec LF, permet la conversion automatique dans Windows et bloque les exceptions occasionnelles avec eol=crlf pour les fichiers qui en ont besoin (par exemple, .sln). Les autres sont des problèmes évitables.

Dépôts avec sauts de ligne mixtes : comment résoudre le problème

C'est très typique : certaines parties du code proviennent de Linux (LF) et d'autres ont été modifiées sous Windows (CRLF). Le résultat est un arbre avec des lignes mélangées, des différences illisibles, et les gens se demandent pourquoi leur script ne démarre pas aujourd'hui. mettre les choses en ordre.

Plan rapide et sûr:

1. Ajouter .gitattributes avec * texte=auto et des règles spécifiques si nécessaire (par exemple, *.sln texte eol=crlf).
2. Courir git add –renormalize . pour que Git parcoure le dépôt et ajuste les sauts de ligne selon les règles.
3. Faire un validation unique avec un message clair (par exemple, « Modifications de ligne homogénéisées »).
4. Informez l'équipe et demandez tirer avant de procéder à la minimisation des conflits.

Si vous avez des scripts sensibles (sh, py, etc.), assurez-vous qu'ils sont enregistrés avec LF et le shebang n'est pas déformé. Vous pouvez le forcer avec des motifs dans .gitattributes ou le vérifier dans votre éditeur avant de valider.

Pour Visual Studio, si des sauts incohérents sont détectés, une normalisation sera suggérée. Acceptez, examinez le diff et accompagnez-le de la validation de renormalisation précédent pour que tout soit rond.

À partir de ce moment, avec .gitattributes et core.autocrlf correctement configurés, ils sont finis Les correctifs « cette fois, c'est passé par CRLF ». Et si quelqu'un ouvre le projet sous Linux ou macOS, tout restera identique, car les fichiers du dépôt sont enregistrés avec LF.

Article connexe:

Formats Microsoft Office : définition et utilisation de chacun d'eux

Isaac

Écrivain passionné par le monde des octets et de la technologie en général. J'aime partager mes connaissances à travers l'écriture, et c'est ce que je vais faire dans ce blog, vous montrer toutes les choses les plus intéressantes sur les gadgets, les logiciels, le matériel, les tendances technologiques et plus encore. Mon objectif est de vous aider à naviguer dans le monde numérique de manière simple et divertissante.