Encodage des caractères et fins de ligne sous Windows - Les bases du mojibake et de CRLF/LF

Dans les consultations sur le traitement du texte sous Windows, les questions suivantes se mélangent avec une fréquence remarquable.

• Quelle est la différence entre Shift_JIS et UTF-8
• Pourquoi le mojibake se produit-il
• Quelle est la différence entre CRLF et LF
• On est passé à UTF-8, alors pourquoi le fichier reste-t-il parfois illisible
• Pourquoi le même fichier ne s’affiche-t-il pas de la même façon dans l’éditeur, la console, Excel et Git

Ce sujet n’est pas compliqué parce que le japonais serait difficile. Dans la grande majorité des cas, la cause est que la même suite d’octets a été lue avec une hypothèse différente, ou que le contenu mal lu a été enregistré tel quel.

De plus, sous Windows, le monde Unicode et celui des pages de code (code page) coexistent encore aujourd’hui. À cela s’ajoutent le BOM, le caractère de fin de ligne, la détection automatique des éditeurs, la page de code de la console et la conversion des fins de ligne par Git, ce qui donne l’impression d’un sujet particulièrement compliqué.

Cet article met de l’ordre, pour un usage pratique, dans les confusions fréquentes sous Windows entre Shift_JIS / UTF-8 / UTF-16, dans les raisons du mojibake, dans la différence entre CRLF et LF, et dans les raisons pour lesquelles ce sujet prête autant à confusion.

Le contenu s’appuie sur les informations publiques de Microsoft Learn, PowerShell, Git et W3C / Unicode telles qu’elles étaient au mois d’avril 2026. Pour plus de détails, voir les références en fin d’article.

Table des matières

1. Ce qu’il faut retenir en premier
2. Décomposer le vocabulaire
   • 2.1 En quoi Unicode / UTF-8 / UTF-16 / CP932 diffèrent
   • 2.2 Comment penser Shift_JIS face à CP932
   • 2.3 Les pièges des mots ANSI, Unicode et UTF-8N
3. Pourquoi le mojibake se produit
   • 3.1 Ce qu’est vraiment le mojibake
   • 3.2 Affichage corrompu et corruption des données sont deux choses différentes
   • 3.3 Convertir vers des caractères non représentables est irréversible
4. Les différences entre caractères de fin de ligne
   • 4.1 CRLF / LF / CR
   • 4.2 La fin de ligne est un problème distinct de l’encodage
   • 4.3 \n et les octets de fin de ligne du fichier ne coïncident pas toujours
5. Pourquoi c’est particulièrement déroutant sous Windows
   • 5.1 Unicode et les pages de code legacy coexistent
   • 5.2 Les étiquettes ne sont pas alignées
   • 5.3 Le contenu tout-ASCII masque le problème
   • 5.4 Contenu du fichier, nom du fichier, console et fichier source sont des couches distinctes
   • 5.5 Le BOM et la fin de ligne jouent aussi sur d’autres axes
   • 5.6 Les outils modifient les choses de leur propre initiative
6. Schémas d’incidents fréquents
7. Règles pour réduire les incidents en pratique
8. Mener l’investigation sur le mojibake et les écarts de fin de ligne avec ces 5 questions
9. Résumé
10. Articles connexes
11. Références

1. Ce qu’il faut retenir en premier

En posant d’abord les conclusions, sept points sont particulièrement importants.

• Un fichier texte n’est pas la chaîne de caractères elle-même, mais se compose d’octets + un encodage de caractères + un caractère de fin de ligne. Un BOM peut parfois s’y ajouter.
• Le mojibake se produit quand les mêmes octets sont décodés avec un encodage différent.
• Les problèmes de fin de ligne surviennent quand l’encodage est correct mais que l’hypothèse sur le séparateur de ligne est erronée.
• Unicode et UTF-8 ne signifient pas la même chose. Unicode concerne le jeu de caractères, tandis que UTF-8 et UTF-16 concernent l’encodage.
• Ce que l’on appelle « Shift_JIS » sous Windows gagne, en pratique, à être considéré comme CP932 / une page de code japonaise de la famille Windows : les échanges dérivent moins ainsi.
• Dire « on est passé à l’UTF-8 » ne constitue pas encore une spécification suffisante. Ce n’est une véritable règle d’exploitation qu’une fois décidées la présence ou non d’un BOM et le caractère de fin de ligne.
• La source de la confusion n’est pas le japonais lui-même, mais la coexistence, sur une même machine Windows, de plusieurs hypothèses issues d’histoires différentes.

Pour traiter du texte sous Windows, le point de départ consiste à distinguer d’abord ces quatre éléments :

1. Quels sont les octets de ce fichier
2. Avec quel encodage a-t-il été écrit
3. Avec quel encodage est-il lu
4. La fin de ligne est-elle en CRLF ou en LF

Le simple fait de distinguer ces points réduit déjà considérablement les hésitations.

2. Décomposer le vocabulaire

2.1 En quoi Unicode / UTF-8 / UTF-16 / CP932 diffèrent

Il est d’abord plus rapide de décomposer une fois pour toutes ce vocabulaire.

Même pour un seul caractère comme あ, les octets diffèrent selon l’encodage.

Caractère : あ

UTF-8    : E3 81 82
CP932    : 82 A0
UTF-16LE : 42 30

L’essentiel est que les caractères et les octets sont deux choses différentes. Une application manipule à l’écran ce qui ressemble à des « caractères », mais pour l’enregistrement ou la transmission, ce sont en fin de compte des octets qui s’échangent. Les incidents se produisent presque toujours à la frontière de cette conversion.

2.2 Comment penser Shift_JIS face à CP932

Sur le terrain, on regroupe souvent les fichiers texte des Windows japonais sous l’appellation « Shift_JIS ». Cela fonctionne à l’oral, mais c’est un peu imprécis en pratique.

Pour être plus précis sur le texte legacy japonais de Windows, il est plus sûr de penser en termes de CP932, ou de page de code japonaise de la famille Windows.

Rester approximatif sur ce point fait dériver des échanges comme ceux-ci :

• On a demandé « enregistre en Shift_JIS », mais l’interlocuteur avait en tête le CP932 côté Windows
• Côté Linux / macOS, le fichier a été traité comme shift_jis, mais certains fichiers d’origine Windows ne se reproduisent pas correctement
• On a demandé un enregistrement en « ANSI », mais la page de code réellement utilisée dépendait de l’environnement

C’est pourquoi, dans les spécifications ou les notes d’investigation, il est plus sûr d’écrire autant que possible :

• CP932 plutôt que Shift_JIS
• ACP (active code page) / généralement CP932 en environnement japonais plutôt que ANSI
• Quelque chose de concret comme UTF-8 no BOM, LF plutôt que text

2.3 Les pièges des mots ANSI, Unicode et UTF-8N

Autour de Windows, les étiquettes verbales elles-mêmes sont aussi une source de confusion.

Ces trois-là prêtent particulièrement à confusion.

• ANSI Ce terme apparaît dans l’interface Windows ou dans d’anciennes documentations, mais il ne s’agit pas d’ASCII. Dans la plupart des cas, il désigne la page de code active (active code page) de la machine.
• Unicode Dans certains éditeurs ou outils, l’entrée « Unicode » du menu peut en réalité désigner UTF-16LE. Dire « je l’ai enregistré en Unicode » ne signifie donc pas forcément UTF-8.
• UTF-8N On le rencontre parfois dans des éditeurs du marché japonais ; il s’agit normalement d’une étiquette d’interface destinée à distinguer UTF-8 sans BOM. Ce n’est pas un nom d’encodage officiel.

Autrement dit, sous Windows, un même mot change de sens d’un outil à l’autre. C’est le premier grand point de confusion.

3. Pourquoi le mojibake se produit

3.1 Ce qu’est vraiment le mojibake

Ce qu’est vraiment le mojibake est en fait assez simple.

1. Une chaîne de caractères est transformée en octets avec un certain encodage
2. Ces octets sont retransformés en chaîne avec un encodage différent
3. Si les hypothèses ne correspondent pas, on obtient une chaîne différente

Par exemple, si l’on enregistre あ en UTF-8, on obtient les octets suivants.

E3 81 82

Lus comme de l’UTF-8, ces octets redonnent あ ; mais lus sous l’hypothèse CP932, ils apparaissent comme une chaîne différente, du type 縺�. Ce qui est cassé à ce moment-là n’est pas « le japonais », mais l’hypothèse de décodage.

En une phrase, le mojibake, c’est :

Les mêmes octets ont été lus avec un encodage différent.

3.2 Affichage corrompu et corruption des données sont deux choses différentes

Ce qui compte ici, c’est de distinguer le stade où l’on peut encore revenir en arrière du stade où c’est devenu difficile.

Par exemple, le déroulement suivant permet encore, potentiellement, de revenir en arrière :

1. Un fichier UTF-8 est ouvert en tant que CP932
2. À l’écran, cela apparaît comme 縺�
3. Rien n’a encore été enregistré

À ce stade, les octets d’origine restent encore en UTF-8. Rouvrir le fichier avec le bon encodage permet souvent de tout récupérer.

Le déroulement dangereux est celui-ci :

1. Un fichier UTF-8 est mal lu comme du CP932
2. Le contenu qui apparaît corrompu est enregistré tel quel
3. Les octets UTF-8 d’origine sont perdus

Une fois qu’on en arrive là, ce n’est plus un simple problème d’affichage, mais une véritable corruption de données.

En pratique, plutôt que de tout résumer par « ça s’est corrompu », il est important de distinguer au moins ces deux questions :

• Les octets eux-mêmes sont-ils encore corrects
• Le contenu mal lu a-t-il déjà été réenregistré

3.3 Convertir vers des caractères non représentables est irréversible

Un autre point dangereux est celui où l’on convertit une chaîne Unicode vers une page de code restreinte comme CP932.

Si la chaîne contient des caractères qui n’existent pas côté cible, l’un des cas suivants se produit :

• Ils sont remplacés par ?
• Un caractère de remplacement est inséré
• La conversion échoue avec une erreur
• Ils sont rapprochés d’un caractère proche

Par exemple, certains emoji ou kanji étendus ne peuvent pas être convertis tels quels vers CP932. Ce type d’incident doit être évalué non pas en fonction de « est-ce lisible ? », mais de « une conversion aller-retour redonne-t-elle l’original ? ».

Une information perdue une fois ne revient pas, même si l’on découvre ensuite le bon encodage.

4. Les différences entre caractères de fin de ligne

4.1 CRLF / LF / CR

La fin de ligne, elle aussi, se résume à des octets.

• CR = carriage return = 0D
• LF = line feed = 0A
• Les fichiers texte de Windows utilisent traditionnellement CRLF (0D 0A)
• Les systèmes Linux / Unix utilisent généralement LF (0A)
• Le CR seul peut apparaître dans des contextes anciens, comme les vieux systèmes Mac

Sous forme de tableau :

4.2 La fin de ligne est un problème distinct de l’encodage

Ce point est vraiment important.

Le caractère de fin de ligne est un problème distinct de l’encodage.

Un même fichier UTF-8 peut avoir des fins de ligne en CRLF comme en LF. Par exemple, pour un contenu « A, saut de ligne, B », les octets changent comme suit :

UTF-8 + LF   : 41 0A 42
UTF-8 + CRLF : 41 0D 0A 42

Autrement dit, les cas suivants sont parfaitement possibles :

• UTF-8, mais seule la fin de ligne diffère
• CP932, mais la fin de ligne est en LF
• UTF-16LE, mais la fin de ligne est en CRLF

Ainsi, quand on constate que « même passé en UTF-8, ça ne va toujours pas », il arrive en réalité que seule la fin de ligne soit en cause, et non l’encodage.

4.3 \n et les octets de fin de ligne du fichier ne coïncident pas toujours

C’est ici que se cache une confusion discrète, du point de vue du programmeur.

Écrire \n dans le code source ne garantit pas que seul 0A se retrouvera dans le fichier. Selon le langage, le runtime ou le mode texte (text mode) de l’API d’E/S, \n peut être converti en CRLF sous Windows.

Autrement dit, les éléments suivants peuvent diverger :

• la notation de la fin de ligne dans le code source
• la chaîne au moment de l’exécution
• les octets enregistrés dans le fichier
• la fin de ligne visible dans l’éditeur

C’est ainsi que se produit l’incident : « je pensais avoir écrit du LF, mais le fichier était en CRLF ».

Les éditeurs récents gèrent normalement le LF seul, mais les outils périphériques, les applications legacy et les pratiques d’exploitation métier reposent encore souvent sur l’hypothèse CRLF. C’est pourquoi les problèmes de fin de ligne ne relèvent pas du « passé » : ils surviennent encore couramment en pratique aujourd’hui.

5. Pourquoi c’est particulièrement déroutant sous Windows

5.1 Unicode et les pages de code legacy coexistent

C’est la principale raison pour laquelle Windows est compliqué.

Windows conserve les deux voies :

• celle qui utilise Unicode
• celle qui repose sur les pages de code

Les applications récentes, le web et les actifs multiplateformes tendent à privilégier l’UTF-8, tandis que les anciens CSV, TXT, journaux, l’écosystème Excel et les intégrations de systèmes métier conservent encore le CP932. De plus, l’UTF-16LE apparaît couramment dans certaines sorties ou autour de certaines API.

Autrement dit, plusieurs cultures du texte cohabitent au sein d’une même machine Windows.

5.2 Les étiquettes ne sont pas alignées

Ce qui multiplie la confusion, ce n’est pas tant la technologie elle-même que le décalage des étiquettes.

• On dit Shift_JIS, mais la réalité est du CP932
• On dit ANSI, mais la réalité est la page de code active
• On dit Unicode, mais la réalité est de l’UTF-16LE
• On dit UTF-8, mais la présence ou non d’un BOM n’a jamais été tranchée
• Des étiquettes propres à certains éditeurs, comme UTF-8N, font leur apparition

Rester flou sur ce point donne l’impression que la conversation fonctionne, alors que les réalités sous-jacentes ne coïncident pas.

5.3 Le contenu tout-ASCII masque le problème

Ce point pèse lourd également.

Comme l’UTF-8 est compatible avec la plage ASCII, un fichier ne contenant que des caractères alphanumériques et des symboles peut « sembler à peu près lisible » même sous une mauvaise hypothèse. Côté CP932 aussi, la plage équivalente à l’ASCII s’affiche rarement de façon visiblement corrompue, si bien que le problème ne fait pas surface.

Il en résulte une situation de ce type :

• Une configuration entièrement en anglais paraît sans problème
• Dès qu’une ligne de japonais est ajoutée, tout se corrompt
• Un problème resté latent se déclenche pour la première fois en cours d’exploitation

C’est pourquoi les incidents d’encodage donnent souvent l’impression que « ça marchait encore hier, et ça s’est soudainement cassé aujourd’hui ». En réalité, il s’agit le plus souvent d’une mine posée depuis longtemps, qui n’est devenue visible qu’au moment où un caractère non-ASCII est apparu.

5.4 Contenu du fichier, nom du fichier, console et fichier source sont des couches distinctes

Sous Windows, regrouper tout ce qui suit sous l’appellation « encodage des caractères » prête à confusion :

• le nom de fichier / le chemin
• le contenu du fichier
• l’affichage dans la console
• l’encodage du fichier source de code lui-même
• la représentation de la chaîne à l’exécution
• l’affichage dans le presse-papiers ou les composants d’interface graphique

Par exemple, même si un nom de fichier en japonais s’affiche normalement, le contenu du fichier peut être enregistré en CP932. Inversement, même si le fichier lui-même est en UTF-8, seul l’affichage sera corrompu si la page de code de la console ne correspond pas.

Une commande comme chcp 65001 agit fondamentalement sur l’hypothèse côté console ; elle ne modifie pas les octets des fichiers existants.

De plus, même si le fichier source de code est en UTF-8, le fichier journal écrit à l’exécution n’est pas forcément lui aussi en UTF-8. Il faut à chaque fois clarifier de quelle couche d’encodage on parle.

Notons par ailleurs que, sur les Windows japonais, \ peut s’afficher comme un signe yen, ce qui a également tendance à se mêler aux discussions sur l’encodage. Dans la plupart des cas, il s’agit toutefois d’un problème de police d’affichage ou de glyphe : le sens du caractère comme séparateur de chemin ou caractère d’échappement n’a pas changé.

5.5 Le BOM et la fin de ligne jouent aussi sur d’autres axes

Dire simplement « UTF-8 » ne règle encore que la moitié de la question.

En pratique, les éléments suivants comptent également :

• Y a-t-il un BOM ou non
• La fin de ligne est-elle en CRLF ou en LF

Par exemple, pour un même UTF-8 :

• certains outils Windows ne le lisent correctement que si un BOM est présent
• certains traitements côté Unix récupèrent un caractère parasite en première colonne quand un BOM est présent
• certains outils legacy ont du mal avec le LF seul
• le CRLF peut perturber les scripts shell ou alourdir les diffs

Ainsi, même avec un encodage correctement aligné, un incident reste possible.

5.6 Les outils modifient les choses de leur propre initiative

Ce qui complique encore les choses, c’est que les outils locaux modifient les choses de manière implicite.

• L’éditeur effectue une détection automatique
• Un BOM est ajouté ou retiré au moment de l’enregistrement
• Git convertit entre CRLF et LF
• Le shell ou une commande enregistre avec son encodage par défaut
• Un export CSV utilise une page de code inattendue
• Les valeurs par défaut diffèrent selon la version de PowerShell ou de l’outil

Autrement dit, même quand l’opérateur n’a rien précisé, une couche ou une autre ajoute d’elle-même sa propre hypothèse — c’est le quotidien de la pratique sous Windows.

C’est là la véritable explication du « je n’ai rien changé, et pourtant ça s’est cassé ». En réalité, ce n’est pas rare que ce soit la valeur par défaut d’un outil, et non une personne, qui ait modifié quelque chose.

6. Schémas d’incidents fréquents

Voici, sous forme de tableau, les incidents typiques.

Le schéma le plus dangereux est celui où l’on constate un affichage corrompu, puis on enregistre quand même, ce qui scelle l’incident.

7. Règles pour réduire les incidents en pratique

À partir d’ici, il s’agit de déterminer quelles règles d’exploitation permettent de réduire les incidents.

7.1 Décider la référence pour les nouveaux fichiers texte

Pour un nouveau fichier, il est raisonnable de faire de l’UTF-8 le premier choix. Cela ne suffit toutefois pas à soi seul.

Il est plus sûr de trancher au minimum les points suivants :

• UTF-8 with BOM ou UTF-8 no BOM
• La fin de ligne en CRLF ou en LF
• Qui va lire ce fichier
• Une compatibilité avec d’anciens outils Windows est-elle nécessaire
• Linux / macOS / la CI / les conteneurs le liront-ils également

Par exemple, pour du code source ou une configuration destinés à être multiplateformes, UTF-8 no BOM + LF est souvent le premier choix. En revanche, s’il faut s’aligner sur d’anciens outils Windows ou sur des pratiques d’exploitation existantes, UTF-8 with BOM, voire CP932 + CRLF, peuvent rester nécessaires.

Ce qui compte, ce n’est pas de trancher selon des considérations générales sur « ce qui est correct », mais en fonction de avec qui les données sont échangées.

7.2 Ne pas convertir à la légère les fichiers legacy existants

Si un fichier existant est en CP932, il est plus sûr de ne pas le convertir en UTF-8 à l’occasion d’une petite modification courante.

L’exploitation prudente consiste à :

• Conserver, pour les fichiers existants, l’encodage / le BOM / la fin de ligne d’origine
• Traiter la conversion d’encodage comme une tâche de migration séparée
• Ne procéder à une conversion en masse qu’après avoir vérifié le périmètre concerné et les consommateurs en aval

Les incidents de mojibake naissent souvent d’une bonne intention du type « on en profite pour moderniser ».

7.3 Traiter l’encodage et la fin de ligne comme faisant partie de l’interface

Pour les CSV, TXT, journaux, fichiers de configuration et protocoles simples, ce n’est pas seulement le contenu, mais le format texte lui-même qui constitue l’interface.

Il est plus sûr d’indiquer, dans la spécification, au moins :

• l’encodage
• la présence ou non d’un BOM
• le style de fin de ligne
• la présence ou non d’un en-tête
• les règles de guillemets / de séparateur
• avec quel outil cela a été validé

Par exemple, les trois lettres CSV ne suffisent pas. Ce n’est qu’en écrivant quelque chose comme UTF-8 with BOM, CRLF, séparateur virgule, avec en-tête que la conversation cesse de dériver.

7.4 Être explicite aux frontières de lecture/écriture

Côté code également, il est plus sûr de ne pas s’en remettre à des valeurs par défaut implicites.

• Préciser explicitement l’encodage lors des lectures / écritures de fichiers
• Rester attentif à l’encodage lors des échanges de texte entre processus
• Fixer également la fin de ligne dans la spécification des traitements d’export / import
• Ne pas faire d’une redirection shell improvisée un chemin de production

Sous Windows en particulier, « avoir réussi à enregistrer » et « avoir enregistré avec les bons octets » ne sont pas la même chose.

7.5 Partager aussi les règles de Git et de l’éditeur

Git n’est pas un outil qui corrige automatiquement l’encodage. En revanche, une conversion peut intervenir sur les fins de ligne.

C’est pourquoi il est plus sûr de décider, par dépôt (repository) :

• Si le code source doit avoir LF comme référence
• Si le texte réservé à Windows peut tolérer CRLF
• Comment fixer cela via .gitattributes
• Comment partager les réglages d’éditeur

Il est important de penser séparément l’encodage et la fin de ligne. Même si Git harmonise les fins de ligne, les incidents d’encodage subsistent tels quels.

7.6 Ne pas s’arrêter à « c’est corrompu » — dire ce qui est en décalage

Sur le terrain, cette reformulation est souvent très efficace.

• Mauvaise formulation : « C’est corrompu »
• Bonne formulation : « Il semble qu’un fichier UTF-8 no BOM soit ouvert avec l’hypothèse CP932 »
• Mauvaise formulation : « Les fins de ligne sont bizarres »
• Bonne formulation : « Un fichier en LF est converti en CRLF, ce qui gonfle le diff »

Le simple fait de pouvoir exprimer ce qui est en décalage change considérablement la vitesse de l’investigation.

8. Mener l’investigation sur le mojibake et les écarts de fin de ligne avec ces 5 questions

En cas d’hésitation durant l’investigation, revenir aux cinq questions suivantes est la voie la plus rapide.

1. Quels sont, en ce moment, les octets de ce fichier
   • Est-ce de l’UTF-8 ?
   • De l’UTF-8 with BOM ?
   • Du CP932 ?
   • De l’UTF-16LE ?
2. Qui l’a écrit en premier, et sous quelle hypothèse
   • un éditeur
   • une application legacy
   • un export Excel
   • un shell / script
   • un batch / middleware
3. Qui le lit maintenant, et sous quelle hypothèse
   • la détection automatique de l’éditeur
   • la page de code de la console
   • l’encodage par défaut de la bibliothèque
   • la spécification côté import
4. Quels sont le BOM et la fin de ligne
   • BOM présent / absent
   • CRLF / LF
5. Le contenu mal lu a-t-il déjà été enregistré
   • Est-ce encore uniquement un problème d’affichage ?
   • A-t-il déjà été réenregistré, avec perte des octets d’origine ?

Une fois ces cinq questions renseignées, la cause devient généralement visible.

9. Résumé

Si l’encodage des caractères et les fins de ligne semblent compliqués sous Windows, ce n’est pas parce que le japonais lui-même serait difficile. C’est parce que les octets, l’encodage, le BOM, la fin de ligne et les valeurs par défaut des outils existent de façon indépendante, et que par-dessus tout cela, les cultures textuelles anciennes et nouvelles cohabitent sous Windows.

Les six points suivants méritent particulièrement d’être retenus :

• Le mojibake est le résultat de la lecture des mêmes octets avec un encodage différent
• Les problèmes de fin de ligne relèvent d’un axe distinct de l’encodage
• Ne pas faire une confiance excessive, telle quelle, aux mots Shift_JIS, CP932, ANSI, Unicode
• Dire « on est passé à l’UTF-8 » ne suffit pas : le BOM et la fin de ligne sont également nécessaires
• Distinguer l’affichage corrompu de la corruption de données déjà réenregistrée
• Dans les spécifications, écrire non pas text mais quelque chose comme UTF-8 no BOM, LF

En résumé, pour traiter du texte sous Windows, l’approche la plus pragmatique consiste à considérer qu’il ne s’agit pas d’« une question de chaînes de caractères », mais d’une question portant sur la manière d’aligner le contrat sur les octets.

10. Articles connexes

• Comprendre les encodages de caractères sous Windows - Pourquoi le mojibake se produit, et ce qui dérape particulièrement en combinaison avec Linux
• Bonnes pratiques pour réduire les incidents de mojibake avec Codex sous Windows - Décider « comment donner ses instructions » avant de peaufiner l’environnement

11. Références

1. Microsoft Learn, Code Page Identifiers - Win32 apps https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
2. Microsoft Learn, about_Character_Encoding - PowerShell https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding?view=powershell-7.6
3. Microsoft Learn, Understanding file encoding in VS Code and PowerShell https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding?view=powershell-7.6
4. W3C Internationalization, Character encodings: Essential concepts https://www.w3.org/International/articles/definitions-characters/
5. Git documentation, gitattributes https://git-scm.com/docs/gitattributes
6. Git documentation, git-config https://git-scm.com/docs/git-config

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Pourquoi le mojibake (texte corrompu) se produit-il ?

Parce qu'une même suite d'octets est lue avec un encodage différent de celui utilisé lors de son écriture. Par exemple, le caractère « あ » enregistré en UTF-8 devient les octets E3 81 82, mais si on les lit en supposant du CP932, on obtient une chaîne différente, du type « 縺 ». Ce qui est « cassé » à ce moment-là n'est pas le japonais lui-même, mais l'hypothèse de décodage. Cela dit, si le contenu mal lu est réenregistré tel quel, les octets d'origine sont perdus : on passe alors d'un simple problème d'affichage à une véritable corruption de données. Il est donc essentiel de rouvrir le fichier avec le bon encodage avant tout enregistrement.

Quelle est la différence entre CRLF et LF ?

C'est une différence d'octets utilisés pour séparer les lignes. CRLF correspond aux deux octets 0D 0A et est traditionnellement utilisé dans les fichiers texte de Windows, tandis que LF correspond à l'octet unique 0A et est courant sous Linux / macOS ainsi que dans de nombreux outils de développement. Le point important est que le caractère de fin de ligne est un problème distinct de l'encodage des caractères. Un même fichier en UTF-8 peut avoir des fins de ligne en CRLF comme en LF ; ainsi, quand on constate que « même en UTF-8, ça ne va toujours pas », il arrive que seul le caractère de fin de ligne soit en cause, et non l'encodage.

Shift_JIS et CP932 sont-ils la même chose ?

À l'oral, cela passe, mais en pratique il est plus sûr de les distinguer. Pour parler avec précision du texte legacy des Windows japonais, il vaut mieux penser en termes de CP932, ou de page de code japonaise de la famille Windows. De la même façon, sous Windows, « ANSI » désigne le plus souvent la page de code active (active code page) de la machine, et l'entrée « Unicode » dans le menu de certains éditeurs peut en réalité signifier UTF-16LE. Dans les spécifications ou les notes d'investigation, écrire quelque chose de concret comme « UTF-8 no BOM, LF » limite les malentendus.

Que faut-il fixer dans la spécification d'un fichier texte ?

Se contenter de dire « on passe à l'UTF-8 » ne suffit pas : ce n'est une véritable règle d'exploitation qu'à partir du moment où l'on a aussi tranché la présence ou non d'un BOM et le caractère de fin de ligne. Pour des fichiers d'échange comme les CSV ou les journaux, il est plus sûr de préciser jusqu'à l'encodage, la présence ou non d'un BOM, le caractère de fin de ligne, la présence ou non d'un en-tête et le séparateur. Pour du code source ou une configuration destinés à être multiplateformes, UTF-8 no BOM + LF est souvent le premier choix ; en revanche, s'il faut s'aligner sur d'anciens outils Windows, UTF-8 with BOM ou même CP932 + CRLF peuvent rester nécessaires.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.