Pré-vérification de portabilité des fichiers texte
Collez du texte ou sélectionnez un fichier texte brut pour repérer les différences d'encodage, de fins de ligne et d'espaces susceptibles d'affecter Git, les outils diff, CI, le Bloc-notes Windows ou d'anciens outils Unix, même si votre éditeur l'affiche normalement.
Traitement effectué localement dans votre navigateur. Votre fichier n’est jamais téléversé.
Comment utiliser cet outil outil
- Collez du texte ou sélectionnez un fichier .txt/.csv/.log/texte brut ; le navigateur le lit localement, sans téléversement.
- Sélectionnez « Vérifier la portabilité ».
- Examinez chaque problème signalé, son effet sur la portabilité et les outils concernés.
- Utilisez la réécriture sûre combinée si elle est proposée : normaliser les fins de ligne, retirer un BOM initial, supprimer les espaces finaux, ajouter le saut final et corriger les espaces visuellement similaires.
Hypothèses
- L'entrée est déjà une chaîne JavaScript décodée par le navigateur via .text() du sélecteur de fichier ou par collage. L'analyse porte sur ce texte, pas sur les octets d'origine ; l'encodage initial n'est pas détecté directement.
- Reconnaît huit problèmes : fins de ligne CRLF/LF mélangées, CR sans LF, BOM initial, caractères de remplacement Unicode, espaces finaux, absence de saut final, indentation mêlant tabulations et espaces, espaces Unicode visuellement similaires. Les autres aspects d'encodage ne sont pas couverts.
- Un caractère de remplacement Unicode (U+FFFD) indique un échec de décodage antérieur à l'analyse. Les octets d'origine ne peuvent pas être récupérés à partir du texte ; aucune réécriture n'est proposée pour ce cas.
Sources et données de référence
Méthodologie
Le texte est séparé en lignes tout en conservant le terminateur original de chacune (CRLF, LF, CR seul ou aucun), ce qui permet de détecter les mélanges. Huit contrôles ciblés sont ensuite appliqués aux lignes et caractères. La réécriture combinée ne couvre que les corrections mécaniques sans ambiguïté : normaliser les fins, retirer BOM, supprimer les espaces finaux, ajouter le saut final et remplacer/supprimer les espaces similaires. Les caractères de remplacement et indentations mixtes sont seulement signalés : les premiers impliquent une perte déjà survenue, la correction des seconds dépend d'une convention de tabulation inconnue.
Exemple détaillé
Fichier modifié sous Windows et Unix avec fins CRLF et LF mélangées
Données d’entrée: ligne un\r\nligne deux\n
Résultat: Git et les outils diff comparant les lignes voient les terminateurs ; toutes les lignes peuvent sembler modifiées alors qu'une seule a changé de contenu. Erreur et normalisation sûre en LF.
BOM UTF-8 avant une ligne shebang
Données d’entrée: \uFEFF#!/bin/sh\necho "Bonjour"
Résultat: Un BOM avant `#!/bin/sh` empêche de nombreux shells Unix de reconnaître la shebang. Avertissement et retrait sûr du BOM initial.
Espace insécable (U+00A0) collé à la place d'un espace ordinaire
Données d’entrée: const total = prix + taxe;
Résultat: Il ressemble à un espace normal dans la plupart des éditeurs et polices, mais l'analyse et la comparaison exactes le traitent comme un autre caractère. Avertissement et remplacement sûr par un espace ASCII.
Conseils pratiques
- Configurez l'éditeur et `core.autocrlf` de Git (ou `.gitattributes`) pour imposer une convention de fins de ligne au dépôt.
- Traitez un caractère de remplacement Unicode comme une perte de données : réexportez ou rouvrez la source avec le bon encodage, ne tentez pas de reconstruire les octets depuis le texte corrompu.
- Activez l'affichage des espaces ou caractères invisibles dans l'éditeur pour le texte copié depuis un traitement de texte, PDF ou site Web ; c'est une source courante d'espaces insécables et de largeur nulle.
- Préférez une indentation uniquement avec espaces ou uniquement avec tabulations selon la convention du projet, appliquée par un formateur.
Erreurs fréquentes
- Supposer qu'un fichier sans problème visible dans l'éditeur n'a pas de problème de fins de ligne ou d'espaces : les éditeurs masquent souvent les espaces finaux et normalisent l'affichage CRLF/LF.
- Retaper le texte après corruption en caractères de remplacement au lieu de revenir au fichier source : les octets corrompus sont irrécupérables depuis la chaîne décodée.
Questions fréquentes
Pourquoi les fins de ligne mélangées et CR seuls sont-ils des erreurs, mais les espaces finaux une information ?
Les fins mélangées ou CR seuls peuvent induire en erreur les outils ligne par ligne (Git, diff, analyseurs) sur la structure réelle : c'est fonctionnel. Les espaces finaux sont invisibles et n'empêchent pas la lecture ; ils peuvent surtout créer du bruit dans les formateurs ou linters, un problème moindre.
Pourquoi l'outil ne corrige-t-il pas automatiquement l'indentation mêlant tabulations et espaces ?
Une conversion correcte exige de connaître la largeur prévue d'une tabulation (2, 4 ou 8 colonnes). L'outil ne peut pas déduire la convention du texte sans risque de modifier la structure visuelle ; il signale donc les lignes exactes.
L'outil peut-il détecter l'encodage réel du fichier ?
Non. Quand l'outil reçoit le texte, le navigateur a déjà décodé les octets en chaîne JavaScript selon son estimation ou l'encodage choisi. Seul un U+FFFD peut indiquer un échec de décodage ; les octets d'origine ne sont pas inspectés.
Pourquoi CRLF et LF mélangés créent-ils des diffs bruyants, et que détecte l'outil ?
Les outils ligne par ligne peuvent considérer différents des terminateurs distincts même si le texte est identique, faisant paraître une petite modification comme un changement de fichier entier. Cet outil détecte les mélanges CRLF/LF, CR seuls et les autres problèmes listés, mais analyse le texte décodé par le navigateur, pas les octets d'origine ni tous les problèmes possibles.
Dernière vérification : 2026-09-26
Analyseur limité aux lignes et caractères, pas détecteur d'encodage au niveau octet : travaille sur le texte déjà décodé par le navigateur, ne retrouve pas l'encodage original ni les données perdues lors du décodage. Reconnaît huit problèmes précis ; paires de substitution, normalisation des caractères combinés et marques droite-à-gauche ne sont pas couverts.
Cet outil fournit une estimation indicative fondée sur les hypothèses indiquées ci-dessus.
Les préférences de thème et d’outils, ainsi que les listes enregistrées et récemment utilisées, sont stockées uniquement dans ce navigateur.