Introduction à l'encodage des caractères sous Windows - Le mojibake qui survient avec Linux

Le mojibake sous Windows ne se produit pas 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 un code de caractères différent, ou que le résultat d’une lecture erronée a été enregistré avec encore un autre code de caractères.

En particulier lorsqu’on passe de Windows à Linux, le côté Windows conserve plusieurs contextes à la fois — CP932, UTF-8, UTF-16, la page de code de la console, les différences de version de PowerShell — tandis que le côté Linux fonctionne le plus souvent sur une hypothèse UTF-8. Des décalages d’hypothèses jusque-là invisibles au quotidien remontent alors tous en surface d’un coup.

Ce sujet n’est pas tant une question de difficulté du traitement du japonais que la question de savoir si l’hypothèse sous laquelle les octets sont traités est bien alignée des deux côtés. Cet article met en ordre l’encodage des caractères sous Windows sous l’angle « pourquoi le mojibake se produit-il », en se concentrant, de façon pratique, sur les points où les incidents se multiplient lorsqu’on combine Windows avec Linux.

1. Ce qu’il faut retenir en premier

En posant d’abord l’essentiel, six points sont importants.

• Le mojibake n’est pas un problème de « caractères », mais un problème de « la façon dont une suite d’octets a été interprétée ».
• Sous Windows, le monde Unicode et le monde des pages de code legacy coexistent, et même au sein d’une seule machine, l’hypothèse diffère selon le contexte.
• Le côté Linux a une forte hypothèse UTF-8, si bien que lorsque le CP932 ou l’UTF-16 côté Windows s’y mêle, les incidents surviennent facilement.
• Le stade où seul l’affichage est corrompu et le stade où un contenu corrompu a été enregistré doivent être considérés séparément.
• Pour les nouveaux textes, il est plus sûr de faire d’UTF-8 le premier choix, et de laisser les fichiers legacy existants en l’état jusqu’à une tâche de migration explicite.
• L’encodage du fichier, l’encodage de l’éditeur, la page de code de la console et le format interne des chaînes de caractères de l’application sont des choses différentes. Les confondre fait perdre le fil de l’investigation.

Dire simplement « ça s’est corrompu sous Windows » ne permet pas d’identifier la cause. Il faut au minimum distinguer lequel des éléments suivants est en cause.

• L’encodage du fichier lui-même
• L’encodage utilisé lors de l’enregistrement
• L’interprétation de l’éditeur
• La page de code d’entrée/sortie de la console
• Le format interne des chaînes de caractères de l’application
• La locale et l’encodage supposé côté Linux

2. 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 encodée dans un certain code de caractères pour devenir une suite d’octets
2. Cette suite d’octets est décodée avec un certain code de caractères pour redevenir une chaîne de caractères
3. Si les hypothèses d’encodage et de décodage ne coïncident pas, elle est lue comme une chaîne différente

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

E3 81 82

Lue comme de l’UTF-8, cette suite d’octets redonne あ, mais lue dans un contexte CP932, elle apparaît comme une chaîne différente, du type 縺�. C’est cela, le mojibake.

Ce qui compte, c’est que ce qui se passe ici n’est pas « le japonais s’est cassé », mais simplement que l’interprétation d’un même ensemble d’octets a divergé.

2.1 Si seul l’affichage est corrompu, il est parfois encore possible de revenir en arrière

Le mojibake connaît un stade où l’on peut encore rattraper la situation. Par exemple, si les octets d’origine n’ont pas changé, rouvrir le fichier avec le bon encodage permet parfois de tout récupérer.

À l’inverse, le déroulement suivant est dangereux.

1. Un fichier UTF-8 est mal lu comme du CP932
2. À l’écran, cela apparaît comme 縺�
3. La « chaîne telle qu’affichée » est enregistrée telle quelle
4. Les octets UTF-8 d’origine sont perdus

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

2.2 Encore plus dangereux : convertir des « caractères non représentables » vers une page de code restreinte

Un autre incident classique consiste à convertir une chaîne Unicode vers une page de code legacy restreinte comme CP932.

Par exemple, si la chaîne contient des caractères absents de la page de code du destinataire, il se produit l’un des cas suivants :

• ils sont remplacés par ?
• le caractère de substitution � apparaît
• ils sont convertis vers un caractère proche mais différent
• la conversion échoue

Cet incident doit être jugé non pas seulement en termes de lisible / illisible, mais en fonction de la question de savoir si une conversion aller-retour redonne l’original. Un caractère une fois perdu ne peut plus être restauré, même en connaissant ensuite le bon encodage.

3. Pourquoi c’est particulièrement compliqué sous Windows

Windows n’est pas compliqué simplement parce qu’il est ancien. C’est parce que le monde Unicode et le monde des pages de code legacy y cohabitent encore aujourd’hui.

3.1 L’API Windows fait coexister la lignée Unicode et la lignée des pages de code

L’API Windows comporte globalement deux lignées.

• La famille W : wide character. Traite Unicode en UTF-16
• La famille A : la lignée des pages de code, appelée ANSI

Autrement dit, Windows dispose dès le départ à la fois d’une voie « traiter en Unicode » et d’une voie « traiter selon la page de code active à cet instant ». C’est pourquoi, même sur une même machine Windows, l’hypothèse change selon l’API ou l’outil par lequel le texte est passé.

3.2 « Le japonais sous Windows » n’est pas une chose unique

Dans le contexte du japonais sous Windows, ce sont en pratique les quatre éléments suivants qui se mélangent le plus souvent.

• CP932 : fréquent dans le texte legacy des Windows japonais
• UTF-8 : de plus en plus courant dans les nouveaux actifs texte, le web, et les contextes multiplateformes
• UTF-16LE : encore couramment présent dans le contexte des outils et des API Windows
• La page de code de la console : une couche distincte qui agit sur l’entrée/sortie de cmd.exe et de certains outils console

Le point important ici est que ce n’est pas parce qu’on a fait chcp 65001 que le fichier devient UTF-8 pour autant. Changer la page de code de la console et savoir quels sont les octets d’un fichier existant sont deux questions distinctes.

Par ailleurs, le texte legacy des Windows japonais est souvent appelé familièrement « Shift_JIS », mais en pratique, garder à l’esprit le nom CP932 limite les malentendus dans les échanges. Cela permet au moins d’expliciter que l’on parle de « l’encodage legacy japonais propre à Windows ».

3.3 Le nom de fichier et le contenu du fichier sont deux problèmes distincts

Lorsqu’un nom de fichier en japonais s’affiche normalement sous Windows, on a tendance à penser « donc le contenu doit aussi être correct ». C’est là que réside le danger.

• La couche qui traite le chemin / le nom de fichier
• La couche qui lit le contenu du fichier
• La couche qui affiche dans la console

Ces trois couches sont distinctes.

Par exemple, un chemin en japonais peut être traité sans problème, alors que le contenu du fichier, enregistré en CP932, se corrompt s’il est lu comme de l’UTF-8 côté Linux. À l’inverse, même si le contenu du fichier est en UTF-8, seul l’affichage se corrompt si la page de code de la console ne correspond pas.

3.4 Les valeurs par défaut de PowerShell et des outils associés ne sont pas non plus alignées

Ce qui multiplie discrètement les incidents sous Windows, c’est que même en ayant « l’impression d’écrire le même texte », les octets produits diffèrent selon le chemin emprunté.

Les points à surveiller en particulier sont les suivants.

• Windows PowerShell 5.1 n’a pas d’encodage par défaut cohérent
• Certains cmdlets et redirections produisent de l’UTF-16LE
• D’autres chemins utilisent la page de code ANSI active
• PowerShell 7 et versions ultérieures ont par défaut l’UTF-8 sans BOM

Autrement dit, « du texte produit par PowerShell » seul ne détermine pas l’encodage. Il faut savoir quelle version, quel cmdlet et quel chemin d’écriture ont été utilisés.

4. Incidents classiques lorsqu’on combine avec Linux

Il n’est pas rare qu’une situation qui fonctionnait à peu près sous Windows seul se corrompe dès que Linux entre en jeu. La raison est simple : le côté Linux a une forte hypothèse UTF-8.

4.1 Un texte enregistré en CP932 sous Windows est lu comme de l’UTF-8 par Linux

C’est l’incident le plus fréquent.

• Une application legacy Windows ou un processus d’exploitation ancien écrit des CSV / TXT / journaux en CP932
• Les scripts et outils côté Linux les lisent en supposant de l’UTF-8, conformément à la locale
• Résultat : erreurs de décodage, �, chaînes incompréhensibles

L’outil côté Linux n’est pas en cause ici. La cause profonde est que les octets reçus ne portaient aucun accord sur leur encodage.

4.2 De l’UTF-8 sans BOM créé sous Linux / VS Code est considéré comme de l’ANSI côté Windows

L’incident inverse existe aussi.

• Un script / une configuration / un texte est créé sous Linux ou dans VS Code en UTF-8 sans BOM
• Windows PowerShell 5.1 ou un outil legacy considère le fichier sans BOM comme relevant de la page de code côté ANSI
• Seules les lignes contenant du japonais ou d’autres caractères non-ASCII se corrompent

C’est souvent l’UTF-8 qui se retrouve accusé ici, mais la cause réelle est le mélange d’un lecteur incapable de bien déduire un UTF-8 sans BOM.

4.3 Windows écrit de l’UTF-16LE, et côté Linux « ça ne ressemble pas à du texte »

Ce cas est également fréquent.

• Une partie de la sortie de Windows PowerShell 5.1, ou un outil legacy, écrit de l’UTF-16LE
• Les outils texte côté Linux s’attendent à un flux UTF-8 sur un octet
• Résultat : un « texte à l’allure binaire », truffé d’octets NUL

L’UTF-16LE en lui-même n’a rien de mauvais. Simplement, il se marie mal, dans bien des cas, avec l’hypothèse consistant à le faire passer tel quel dans les outils de traitement de texte Linux.

4.4 La présence ou l’absence du BOM crée elle aussi des frictions

Le BOM n’est pas l’encodage lui-même, mais en pratique, il pèse beaucoup.

• Certains outils côté Windows sont aidés par la présence d’un BOM
• Certains outils côté Linux traitent le BOM comme des octets superflus en tête de fichier
• Résultat : seule la première colonne ou le début de la première ligne se corrompt, des déchets invisibles apparaissent, les comparaisons ne coïncident plus

En particulier pour l’UTF-8, le même UTF-8 avec ou sans BOM correspond à des octets différents. Se contenter de dire « on est passé à l’UTF-8 » ne règle encore que la moitié de la règle d’exploitation.

4.5 Se fier à l’apparence dans la console fait perdre le fil

Lorsqu’on passe de Windows à Linux, la console est un autre point dangereux.

• La console Windows a des pages de code d’entrée et de sortie
• Le terminal côté Linux fonctionne le plus souvent sous une hypothèse de locale UTF-8
• Passer par WSL, SSH, un conteneur ou la CI multiplie les chemins d’affichage

Dans cet état, juger que « c’était lisible dans la console, donc le fichier va bien » ou que « c’était corrompu dans la console, donc le fichier est cassé » se révèle facilement erroné. Il vaut mieux vérifier séparément si ce que l’on voit est corrompu et si les octets enregistrés sont corrompus.

4.6 Les incidents classiques résumés en tableau

5. Mener l’investigation sur le mojibake avec ces 4 questions

Quand une investigation sur le mojibake est bloquée, revenir aux 4 questions suivantes est le chemin le plus rapide.

5.1 Quels sont les octets d’origine ?

La première chose à regarder est « quels sont les octets de ce fichier, actuellement ». Il faut avoir le réflexe de regarder les octets, et non l’apparence.

• Est-ce de l’UTF-8 ?
• De l’UTF-8 avec BOM ?
• Du CP932 ?
• De l’UTF-16LE ?
• N’a-t-il pas été réenregistré en cours de route et transformé en autre chose ?

5.2 Qui a écrit en premier, et sous quelle hypothèse ?

Ensuite, identifier « le premier rédacteur ».

• Une application legacy Windows ?
• PowerShell 5.1 ou 7 ?
• Un script Linux ?
• VS Code ?
• Un export issu d’Excel ?
• Un middleware, un batch ou une CI quelconque ?

Tant que ce point reste flou, l’estimation de l’encodage relève du hasard.

5.3 Qui lit actuellement, et sous quelle hypothèse ?

Au-delà du rédacteur, il faut aussi connaître l’hypothèse du lecteur.

• L’éditeur fait-il de la détection automatique ?
• PowerShell tient-il compte du BOM ?
• Le côté Linux traite-t-il le fichier comme de l’UTF-8, conformément à la locale ?
• La bibliothèque utilise-t-elle son encodage par défaut ?
• Encoding.UTF8 ou cp932 est-il spécifié explicitement ?

C’est presque toujours ici que le mojibake se produit.

5.4 Le contenu mal lu a-t-il déjà été enregistré ?

Enfin, vérifier si les dégâts se sont arrêtés au stade de l’affichage.

• Les octets sont-ils encore les octets d’origine ?
• Quelqu’un a-t-il enregistré le contenu apparaissant comme corrompu ?
• Des ? ou des � sont-ils entrés dans le diff ?
• Le fichier entier a-t-il été réécrit avec un autre encodage ?

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

6. Règles d’exploitation pour réduire les incidents

À partir d’ici, place au côté pratique. Dans les projets qui traversent Windows et Linux, fixer les règles suivantes en amont réduit nettement les incidents.

6.1 Faire d’UTF-8 le premier choix pour les nouveaux fichiers

Pour un nouveau fichier texte, faire d’UTF-8 le premier choix est un choix sûr par défaut. Mais il ne faut pas s’arrêter là. Il faut aussi trancher la question du BOM.

Voici la façon de décider recommandée :

• Texte majoritairement lu côté Linux : UTF-8 sans BOM par défaut
• Script lu par un outil legacy Windows ou par Windows PowerShell 5.1 : préciser explicitement la présence ou non du BOM selon les besoins du lecteur
• S’il existe un interlocuteur précis nécessitant de l’UTF-16LE, écrire cette exigence dans la spécification

Se contenter d’écrire « on unifie sur UTF-8 » finit par provoquer des désaccords sur le BOM plus tard.

6.2 Laisser les fichiers legacy existants en l’état jusqu’à une tâche de migration explicite

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

La forme d’exploitation suivante est sûre :

• Les fichiers existants conservent leur encodage / BOM / fin de ligne d’origine
• Le changement d’encodage est séparé en tant que tâche de migration
• Ne procéder à une conversion en masse qu’après avoir vérifié les cibles de conversion, le périmètre d’impact et les consommateurs en aval

De nombreux incidents de mojibake commencent par une « conversion UTF-8 au passage » bien intentionnée.

6.3 Traiter l’encodage 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 l’encodage lui-même qui fait partie de l’interface.

Par exemple, voici le minimum à écrire dans la spécification :

• Ce fichier est-il en UTF-8 / CP932 / UTF-16LE ?
• Dans le cas de l’UTF-8, y a-t-il un BOM ?
• La fin de ligne est-elle en LF ou en CRLF ?
• Qui, de Linux ou de Windows, est producteur / consommateur ?
• Un batch ou un ETL intermédiaire réenregistre-t-il le fichier ?

« On le transmet en tant que texte » ne constitue pas une spécification.

6.4 Ne pas faire confiance aux valeurs par défaut, et les préciser explicitement à l’écriture

Que ce soit dans le code ou dans un script, il est plus sûr de préciser l’encodage explicitement.

Les raisonnements suivants sont dangereux :

• Enregistrer avec les valeurs par défaut
• Penser que ça ira probablement bien en fonction de l’OS
• Penser que le fichier va bien parce que c’était lisible dans la console
• Penser que ça ira parce qu’il existe une détection automatique

Les valeurs par défaut changent normalement selon Windows / Linux, PowerShell 5.1 / 7, l’éditeur et le runtime. À moins de les préciser explicitement, on se contente le plus souvent d’un fonctionnement dû au hasard.

6.5 Vérifier séparément la console et le fichier

Voici une règle qui, discrètement, fait beaucoup d’effet.

• Vérification de l’affichage dans la console
• Vérification en rouvrant le fichier

Il faut séparer ces deux vérifications.

Même si chcp ou l’affichage du terminal semble correct, cela ne veut rien dire si le fichier enregistré est dans un autre encodage. À l’inverse, même si le fichier est normal, seul l’aspect visuel se corrompt si la page de code d’affichage de la console ne correspond pas.

6.6 Git ne corrige pas l’encodage à votre place

C’est discret, mais important.

Git se contente, fondamentalement, de suivre des octets. Autrement dit, il enregistre aussi consciencieusement des octets corrompus dans l’historique, tels quels.

C’est pourquoi, lorsque :

• un diff énorme apparaît alors qu’on n’a rien changé
• seules les lignes en japonais présentent un diff mystérieux
• seule la première ligne a changé
• la fin de ligne et l’encodage ont changé en même temps

il vaut mieux suspecter un incident de réencodage avant de suspecter un changement de contenu.

7. Liste de contrôle minimale

Voici une liste de contrôle à fixer en premier lieu dans les projets où Windows et Linux se mélangent.

7.1 Avant modification

• Quel est l’encodage actuel de ce fichier ?
• Y a-t-il un BOM ?
• La fin de ligne est-elle en LF ou en CRLF ?
• A-t-on noté 2 ou 3 lignes japonaises représentatives ?
• Sait-on lequel, du côté Linux ou du côté Windows, est le consommateur final ?

7.2 Pendant la modification

• N’écrit-on pas d’une manière qui dépend de l’encodage par défaut ?
• N’enregistre-t-on pas en laissant la détection automatique décider ?
• N’utilise-t-on pas négligemment le chemin de PowerShell ou de la redirection shell ?
• Ne se rassure-t-on pas simplement parce que « l’affichage est lisible » ?

7.3 Après modification

• A-t-on rouvert le fichier après l’enregistrement pour vérifier ?
• Les lignes représentatives sont-elles intactes aussi bien côté Linux que côté Windows ?
• Des ? ou des � se sont-ils ajoutés au diff ?
• Seule la première ligne ou la première colonne est-elle corrompue ?
• Le diff se limite-t-il à un énorme changement de BOM / fin de ligne uniquement ?

7.4 Ce qui relève d’une tâche de migration

• Conversion en masse du CP932 vers l’UTF-8
• Unification de la politique de BOM pour l’UTF-8
• Inventaire des scripts qui présupposent PowerShell 5.1
• Documentation explicite des chemins de texte passant par la CI / les conteneurs / WSL / SSH
• Unification des paramètres d’enregistrement de l’éditeur / du formateur / du batch

8. Résumé

Si l’on devait résumer le problème d’encodage sous Windows en une phrase, l’essentiel est que le monde Unicode et le monde des pages de code legacy y cohabitent encore aujourd’hui.

Et si les incidents se multiplient lorsqu’on combine avec Linux, c’est parce que le côté Linux fonctionne le plus souvent sur une hypothèse UTF-8, ce qui fait remonter d’un coup le CP932 ou l’UTF-16 côté Windows, la page de code de la console et les différences de version de PowerShell.

Voici les 5 points à retenir :

• Le mojibake est un décalage dans l’interprétation des octets
• La corruption d’affichage et la corruption de données sont deux choses différentes
• Sous Windows, il faut raisonner en distinguant les couches fichier / éditeur / console / API
• Pour le texte échangé avec Linux, faire d’UTF-8 le premier choix
• Séparer la conversion des fichiers legacy existants des corrections habituelles

Traiter « ça s’est corrompu sous Windows » tel quel rend le sujet bien trop vaste. Mais en le découpant selon ces 4 questions,

• Quels sont les octets d’origine ?
• Qui a écrit quoi, et comment ?
• Qui a lu quoi, et comment ?
• Le fichier a-t-il déjà été enregistré ?

on peut y voir beaucoup plus clair.

L’encodage des caractères est un sujet discret, mais entre Windows et Linux, c’est le contrat d’E/S lui-même. Ne pas laisser ce point dans le flou est la mesure la plus efficace qui soit.

9. Références

Windows / Microsoft

• [Code Pages - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/code-pages)

• [Code Page Identifiers - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers)

• [Unicode in the Windows API - Win32 apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/win32/intl/unicode-in-the-windows-api)

• [Console Code Pages - Windows Console

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/console/console-code-pages)

• [chcp

  Microsoft Learn](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp)

• [Use UTF-8 code pages in Windows apps

  Microsoft Learn](https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page)

PowerShell / VS Code

• [about_Character_Encoding

  Microsoft Learn](https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_character_encoding)

• [Understanding file encoding in VS Code and PowerShell

  Microsoft Learn](https://learn.microsoft.com/en-us/powershell/scripting/dev-cross-plat/vscode/understanding-file-encoding)

GNU / Linux locale

• GNU gettext manual: Header Entry
• Debian Reference, Chapter 8. I18N and L10N

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.

Quelle est la cause du mojibake sous Windows ?

Dans la grande majorité des cas, la cause est que la même suite d'octets a été lue avec un code de caractères différent, ou que le résultat d'une telle lecture erronée a ensuite été enregistré avec encore un autre code de caractères. Par exemple, si l'on enregistre « あ » en UTF-8, on obtient la suite d'octets (E3 81 82) ; si on la lit dans un contexte CP932, on obtient une chaîne différente, du type « 縺 ». Ce n'est pas parce que le japonais est difficile que cela se produit : la véritable cause est que les hypothèses d'encodage et de décodage ne coïncident pas.

Un fichier devenu illisible (mojibake) peut-il être restauré ?

Si la suite d'octets d'origine n'a pas changé, il est parfois possible de la récupérer en rouvrant le fichier avec le bon encodage. Ce qui est dangereux, c'est d'enregistrer tel quel le contenu qui apparaît corrompu à la suite d'une lecture erronée : à partir de ce moment-là, ce n'est plus un simple problème d'affichage, mais une véritable corruption des données. De plus, si une chaîne Unicode est convertie vers une page de code restreinte comme CP932 et que des caractères sont remplacés par « ? » ou par un caractère de substitution, les caractères ainsi perdus ne peuvent plus être restaurés, même en connaissant ensuite le bon encodage.

Faire chcp 65001 suffit-il à mettre les fichiers en UTF-8 ?

Non. Changer la page de code de la console et savoir quelle est la suite d'octets d'un fichier existant sont deux questions distinctes. Sous Windows, l'encodage du fichier lui-même, l'interprétation de l'éditeur, la page de code d'entrée/sortie de la console et le format interne des chaînes de caractères de l'application sont des choses différentes, et il faut absolument raisonner en distinguant ces couches. Le raisonnement « c'était lisible dans la console, donc le fichier est forcément bon » se révèle souvent faux : il faut donc vérifier séparément l'affichage dans la console et le contenu obtenu en rouvrant le fichier.

Quelles sont les règles sûres pour échanger du texte entre Windows et Linux ?

Choisir UTF-8 en premier pour les nouveaux fichiers, et trancher également la question du BOM. Pour un texte majoritairement lu côté Linux, partir sur UTF-8 sans BOM par défaut ; lorsqu'un outil legacy tel que Windows PowerShell 5.1 doit le lire, préciser explicitement la présence ou non du BOM selon les besoins du lecteur. Pour les fichiers CP932 existants, ne pas les convertir au passage lors de corrections courantes, mais les traiter comme une tâche de migration à part entière. Enfin, pour les CSV et les journaux, l'encodage fait lui-même partie de l'interface : documenter l'encodage, le BOM et le caractère de fin de ligne dans la spécification permet de réduire les incidents.

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.