Fins de ligne, encodages et chemins : ce qui casse quand un fichier change de système d'exploitation

Ce que c'est

Quatre pièges de compatibilité sans rapport entre eux, qui se manifestent tous par la même situation : « le fichier est correct en local, mais ne fonctionne plus ailleurs ».

• Fins de ligne : les outils texte de Windows écrivent traditionnellement du CRLF (\r\n), alors que les outils de type Unix n'écrivent que du LF (\n). Un script comportant une ligne shebang et enregistré avec des CRLF échoue sous Linux avec une erreur « interpreter not found » (interpréteur introuvable) : le \r final est interprété comme faisant partie du chemin de l'interpréteur.
• Encodages et marques d'ordre des octets (BOM) : dans Windows PowerShell 5.1, Out-File et > écrivent de l'UTF-16LE avec BOM, Set-Content utilise l'ancienne page de code ANSI, et -Encoding UTF8 produit de l'UTF-8 avec BOM ; PowerShell 7 utilise par défaut de l'UTF-8 sans BOM (utf8NoBOM). Un fichier écrit par l'une de ces versions et lu par un analyseur UTF-8 strict peut contenir trois octets initiaux inattendus, voire être totalement illisible.
• EBCDIC : les systèmes de la famille des mainframes IBM (z/OS et, historiquement, d'autres plateformes IBM) peuvent représenter le texte dans des pages de code EBCDIC telles que cp037, incompatibles octet par octet avec l'ASCII/UTF-8. Un fichier transféré sans étape de conversion explicite (FTP en mode binaire ou texte, ou iconv explicite) devient du charabia illisible de l'autre côté.
• Sensibilité à la casse et longueur des chemins : ext4 est sensible à la casse par défaut (Linux 5.2 et versions ultérieures permettent de rendre certains répertoires insensibles à la casse, mais uniquement sur un système de fichiers créé ou ajusté avec la fonctionnalité casefold, et seulement pour des répertoires vides marqués avec chattr +F). APFS sous macOS est livré par défaut dans une variante insensible à la casse, un format distinct sensible à la casse étant également proposé par Utilitaire de disque. NTFS est insensible à la casse tout en la conservant pour un usage courant (Windows 10 1803 et versions ultérieures permettent de rendre un répertoire donné sensible à la casse avec fsutil file setCaseSensitiveInfo). Windows a historiquement limité les chemins à MAX_PATH (260 caractères), sauf si une application active explicitement la prise en charge des chemins longs.

Pourquoi c'est important

Deux fichiers identiques octet pour octet, à l'exception des fins de ligne ou d'un BOM, peuvent échouer à une comparaison de somme de contrôle, échouer à la résolution d'un shebang, ou ajouter silencieusement un caractère parasite au début de la première ligne lue par un programme. Les différences de sensibilité à la casse transforment un « ça marche sur mon Mac » en « ça casse dans le conteneur Linux » lorsque deux fichiers ne diffèrent que par la casse et que le système de fichiers insensible à la casse les a silencieusement traités comme un seul. Les limites de longueur de chemin font d'une sortie de build profondément imbriquée une défaillance propre à Windows, qui ne se reproduit jamais sous Linux ou macOS.

Comment l'appliquer

• Normaliser explicitement les fins de ligne à la frontière du dépôt (par exemple avec .gitattributes) plutôt que de s'en remettre au comportement par défaut d'un éditeur.
• Lorsque l'on écrit du texte depuis PowerShell pour qu'il soit consommé ailleurs, passer explicitement -Encoding utf8NoBOM dans PowerShell 7. Windows PowerShell 5.1 ne connaît pas cette valeur et la rejette ; il faut y écrire de l'UTF-8 sans BOM avec [System.IO.File]::WriteAllText(PATH, TEXT, [System.Text.UTF8Encoding]::new($false)), en utilisant un PATH absolu.
• Avant tout transfert de fichier vers ou depuis un mainframe, vérifier le mode de transfert (texte ou binaire) et, si l'EBCDIC est en jeu, effectuer la conversion explicitement et vérifier qu'un échantillon de texte connu survit à un aller-retour.
• Tester des noms de fichiers qui ne diffèrent que par la casse sur tout système de fichiers que l'on ne contrôle pas directement ; ne pas supposer que la cible se comporte comme la configuration par défaut de la machine de développement.

Pièges

• Corriger un bogue de type « fichier introuvable » dû à une différence de casse sur un Mac insensible à la casse, pour le voir réapparaître dès que le même code s'exécute en CI sous Linux, sensible à la casse.
• Supposer que la prise en charge des chemins longs est universelle sous Windows dès qu'elle est activée à un endroit ; de nombreuses applications et d'anciennes API continuent d'appliquer MAX_PATH quel que soit le réglage à l'échelle du système.