Pourquoi votre CSV affiche des caractères spéciaux illisibles dans Excel, et comment corriger l'encodage (Guide 2026)

Diagnostiquez en 30 secondes : vos données ne sont pas abîmées, elles sont mal lues

La première chose à établir quand un CSV s'ouvre avec des caractères bizarres est de savoir si les données sont endommagées ou seulement affichées de façon erronée, parce que les deux cas appellent des correctifs très différents, et un mauvais correctif peut transformer un problème d'affichage en perte réelle de données. Voici le test de 30 secondes. Ouvrez le même fichier dans un éditeur de texte simple, le Bloc-notes sur Windows ou TextEdit en mode texte brut sur Mac, ou dans Google Sheets par Fichier, puis Importer. Si les caractères y semblent corrects, vos données sont intactes et seul l'affichage dans Excel est faux. Le fichier sur le disque contient les bons octets, et Excel les décode simplement avec le mauvais encodage. C'est le cas le plus fréquent, et tous les correctifs de ce guide partent de là.

Le deuxième indice est de savoir quels caractères sont erronés. Si le texte anglais simple, les chiffres et la ponctuation semblent corrects, mais que les lettres accentuées, les trémas, les cédilles, le signe euro et les écritures non latines semblent erronés, vous êtes face à un décalage d'encodage, pas à un problème de délimiteur ni à une corruption. Un problème de délimiteur place des lignes entières dans une seule colonne. Une corruption brouille tout ou fait disparaître des lignes. Un problème d'encodage est chirurgical : il casse exactement les caractères qui ont besoin de plus d'un octet en UTF-8, et il laisse tout le reste intact. Si votre fichier affiche José là où il devrait afficher José, ou München là où il devrait afficher München, ce motif est la signature d'octets UTF-8 lus comme un ancien encodage à un seul octet, et il vous indique à la fois la cause et le correctif.

Le troisième contrôle décide si un sauvetage est encore possible. Si les caractères déformés sont visibles aussi dans l'éditeur de texte, le fichier lui-même a peut-être été réenregistré après la mauvaise lecture, et les caractères erronés sont peut-être maintenant écrits dans le fichier. Ne paniquez pas encore, et surtout ne réenregistrez pas par-dessus l'original. La section de sauvetage plus loin dans ce guide couvre exactement ce cas, y compris la seule situation où les caractères sont vraiment irrécupérables : quand un caractère a été remplacé par un point d'interrogation ou un symbole de remplacement pendant un enregistrement, l'information d'origine a disparu de cette copie, et seules les données sources peuvent la régénérer. Tant que vous n'avez pas vérifié, gardez le fichier original intact, travaillez sur une copie, et ne réenregistrez jamais un fichier déformé par-dessus le bon.

Pourquoi Excel devine mal : un fichier CSV ne porte aucune étiquette d'encodage

Pour comprendre pourquoi cela se répète sans cesse, vous devez connaître un fait au sujet du format CSV : un fichier CSV est du texte brut sans en-tête qui indique l'encodage utilisé. Un fichier de tableur porte sa structure et son encodage de texte avec lui. Un fichier CSV ne porte ni l'un ni l'autre. Il n'est fait que d'octets, de virgules et de sauts de ligne. Quand un programme l'ouvre, le programme doit décider comment transformer ces octets en caractères, et les programmes ne décident pas tous de la même façon. Les éditeurs de texte modernes et Google Sheets détectent l'UTF-8 automatiquement dans la plupart des cas, et c'est pourquoi le même fichier y semble correct. Excel, quand vous double-cliquez sur un fichier CSV, ne détecte rien. Il suppose l'encodage par défaut de votre système, qui sur de nombreux systèmes Windows est une ancienne page de codes comme Windows-1252, et il ne vérifie pas si cette supposition était juste.

Cette supposition est tout le problème. L'UTF-8 représente un caractère comme é sur deux octets, et un caractère comme € sur trois octets. Un ancien encodage à un seul octet lit chaque octet comme un caractère à part entière, donc un seul é devient deux caractères erronés, é, et un seul € devient trois caractères, €. Le fichier n'a pas changé. Le lecteur a changé le sens des octets. C'est aussi pourquoi le problème suit un motif selon la région et selon la machine. Un collègue dont le système a un encodage par défaut qui correspond au fichier le voit correctement, tandis que vous voyez un texte déformé, et le même fichier peut sembler correct sur un ordinateur et cassé sur un autre. Aucun ordinateur n'est en panne, et le fichier n'est pas corrompu. Les deux lecteurs sont simplement en désaccord sur le sens des octets, et Excel au double-clic fait confiance à son propre défaut sans poser de question.

Cela explique aussi pourquoi ce problème apparaît si souvent avec des fichiers convertis depuis JSON. JSON est en UTF-8 par définition, donc une conversion de JSON vers CSV produit naturellement un CSV en UTF-8, y compris chaque nom accentué, chaque ville et chaque symbole de monnaie présents dans les données sources. La conversion est correcte. L'ouverture ne correspond pas. Le convertisseur de cette page, par exemple, télécharge de l'UTF-8 brut sans marque d'ordre des octets, ce qui est le bon choix pour les téléversements web, les bases de données, Google Sheets et Python, mais cela signifie qu'un double-clic dans Excel sous Windows peut deviner le mauvais encodage. Savoir que le décalage se situe à l'étape de l'ouverture, et non à l'étape de la conversion, vous indique où corriger : à l'import, ou avec un BOM, comme le montrent les sections suivantes.

Lisez le texte déformé : ce que les caractères bizarres vous disent

Le texte déformé n'est pas aléatoire, et apprendre à le lire vous indique le caractère d'origine et confirme le diagnostic avant que vous ne touchiez à quoi que ce soit. Le motif signature est à suivi d'un autre caractère. Chaque fois que vous voyez é, ä, ü ou ç, vous regardez un caractère UTF-8 qui a été lu comme Windows-1252. Le à est le premier octet de la séquence UTF-8, mal lu comme un caractère à part entière, et le deuxième caractère est le deuxième octet, lui aussi mal lu. Une fois que vous connaissez le motif, vous pouvez décoder le texte déformé mentalement : é était é, ü était ü, ç était ç, ão était ão, comme dans São Paulo qui apparaît sous la forme São Paulo. Le signe euro est le cas le plus spectaculaire : € fait trois octets en UTF-8, donc il apparaît sous la forme des trois caractères €. Un tiret long apparaît sous la forme â€, et une apostrophe courbe apparaît sous la forme ’.

Le motif change selon l'écriture, et ce changement est lui aussi un indice. Les noms en écriture latine produisent le motif à ci-dessus. Le japonais, le coréen et les autres écritures non latines produisent un texte déformé plus long, parce que chaque caractère fait trois octets en UTF-8, donc un seul caractère devient trois caractères erronés : Tokyo écrit 東京 apparaît sous la forme d'une suite de caractères comme æ±äº¬, et un nom coréen devient une suite semblable. Si vous voyez ce type de long texte déformé, le diagnostic est le même, de l'UTF-8 lu comme un encodage à un seul octet, seuls les caractères concernés sont des caractères sur trois octets. Si vous voyez plutôt des points d'interrogation ou des losanges noirs de remplacement là où des caractères devraient se trouver, le diagnostic est différent : ces symboles signifient que l'information a déjà été perdue pendant un enregistrement, et pas seulement mal lue pendant l'affichage, et la section de sauvetage explique alors quoi faire.

Correct text  ->  What Excel shows\nJosé García  ->  José GarcÃ\u00ada\nMünchen      ->  München\nFrançois     ->  François\nSão Paulo    ->  São Paulo\n€50,000      ->  €50,000\ncafé — ok    ->  café — ok\n東京 (Tokyo)  ->  æ\u00b1京\n김민준        ->  김민준

Remarquez ce que le tableau prouve : rien ne manque. Chaque caractère erroné correspond à un octet réel de l'original, simplement décodé avec la mauvaise table. C'est pourquoi le correctif par import fonctionne si complètement. Quand vous dites à Excel que le fichier est en UTF-8, il décode les mêmes octets avec la bonne table, et chaque caractère revient à lui-même, sans modification, sans recherche et remplacement, et sans saisie de données. Si votre fichier correspond à ce motif, sautez la section de sauvetage et passez directement au correctif par import. Vous n'avez pas un fichier endommagé. Vous avez un fichier mal lu.

Correctif 1 : importez le fichier et dites à Excel qu'il est en UTF-8

C'est le correctif à essayer en premier, parce qu'il ne change rien à votre système, rien au fichier, et il fonctionne sur n'importe quel CSV en UTF-8 quel que soit son délimiteur. Au lieu de double-cliquer sur le fichier, ouvrez d'abord Excel, puis importez le fichier par l'import guidé, où vous choisissez vous-même l'encodage. L'aperçu dans la boîte de dialogue d'import vous montre immédiatement si vous avez bien choisi : les caractères s'affichent correctement dans l'aperçu exactement comme ils apparaîtront sur la feuille. Si l'aperçu montre encore un texte déformé, vous n'avez encore rien changé, et vous pouvez essayer une autre origine de fichier avant de charger.

• ▸Dans Excel, allez dans Données, puis À partir d'un texte ou d'un CSV, et sélectionnez votre fichier.
• ▸Dans la boîte de dialogue d'aperçu, définissez l'origine du fichier sur 65001 : Unicode (UTF-8). Sur les anciennes versions d'Excel, la même option apparaît sous le nom Unicode (UTF-8) dans l'assistant Importation de texte.
• ▸Vérifiez l'aperçu. Si les caractères se lisent maintenant correctement, continuez. S'ils semblent encore erronés, le fichier n'est peut-être pas du tout en UTF-8, donc essayez les autres origines de la liste une par une en regardant l'aperçu.
• ▸Définissez le délimiteur sur le caractère utilisé par le fichier, virgule, point-virgule, tabulation ou barre verticale, et vérifiez que les colonnes se séparent correctement dans le même aperçu.
• ▸Cliquez sur Charger. Pour les colonnes qui doivent rester du texte, comme les codes avec des zéros initiaux, définissez ces colonnes sur Texte à l'étape d'import, avant le chargement.

Faites-en votre façon par défaut d'ouvrir les fichiers CSV, et pas seulement votre geste de secours. Le double-clic est une supposition à la fois sur le délimiteur et sur l'encodage. L'import est un choix sur les deux, et ce choix prend environ dix secondes de plus. Le même correctif fonctionne sur Mac, où la route par import est aussi la plus fiable : ouvrez un classeur vide, allez dans Données, puis À partir d'un texte, choisissez le fichier, choisissez Unicode (UTF-8) comme origine du fichier, et terminez. Google Sheets n'a besoin d'aucun correctif dans la plupart des cas, parce que Fichier, puis Importer détecte l'UTF-8 automatiquement, et c'est pourquoi un fichier qui semble cassé dans Excel semble souvent parfait dans Sheets. Cette différence est elle-même un diagnostic : si Sheets l'affiche bien et qu'Excel l'affiche mal, le fichier est correct et Excel a mal deviné.

Correctif 2 : ajoutez un BOM pour que le double-clic fonctionne

Si vous ouvrez le même type de fichier chaque jour, importer à chaque fois devient lassant, et le correctif durable consiste à donner à Excel l'indice dont il a besoin au double-clic. Cet indice est un BOM, une marque d'ordre des octets : trois octets invisibles tout au début du fichier qui disent que ce fichier est en UTF-8. Excel vérifie la présence d'un BOM avant de deviner, donc un fichier UTF-8 avec un BOM s'ouvre correctement au double-clic même sur un système Windows dont l'encodage par défaut est Windows-1252. Le BOM est invisible dans Excel et dans la plupart des éditeurs, et il ne change aucune ligne de données. Il ne concerne que les trois premiers octets du fichier.

La façon la plus simple d'en ajouter un ne demande aucun code. Ouvrez le fichier dans le Bloc-notes, allez dans Fichier, puis Enregistrer sous, et définissez la liste déroulante d'encodage sur UTF-8 avec BOM, puis enregistrez. Le fichier s'ouvre maintenant correctement au double-clic dans Excel. Si vous produisez des fichiers à partir d'un script, ajoutez le BOM au moment de l'écriture au lieu de corriger les fichiers après coup. En Python, cela tient en un mot : ouvrez le fichier avec l'encodage utf-8-sig au lieu de utf-8, et Python écrit le BOM pour vous. L'extrait ci-dessous le montre, et les octets qu'il produit ont été vérifiés : le fichier commence par les trois octets du BOM, suivis des données en UTF-8 brut.

with open("customers.csv", "w", encoding="utf-8-sig", newline="") as f:\n    f.write("name,city\n")\n    f.write("José García,München\n")\n# First bytes of the file: EF BB BF, then the UTF-8 data.\n# Excel now opens it correctly on double-click.

Deux précautions avant d'ajouter un BOM partout. D'abord, certains outils traitent un BOM comme des données, et non comme un marqueur. Un analyseur CSV strict peut lire le premier en-tête comme BOM plus nom au lieu de nom, ce qui casse une recherche d'en-tête. Le convertisseur de cette page télécharge délibérément sans BOM pour exactement cette raison : l'UTF-8 brut est correct pour les téléversements web, les bases de données et Python, et le BOM n'est qu'un confort pour le double-clic dans Excel. Ajoutez donc un BOM aux copies destinées à Excel, et non au fichier maître qui alimente d'autres outils. Ensuite, un BOM ne répare pas un fichier qui n'est pas en UTF-8. Si le fichier a été écrit en Windows-1252, ajouter un BOM par-dessus aggrave les choses, parce qu'Excel décodera alors des données à un seul octet comme de l'UTF-8 et produira un nouveau texte déformé. Ajoutez un BOM seulement à un fichier dont vous savez qu'il est en UTF-8, ce que vous pouvez confirmer avec le test de l'éditeur de texte de la section de diagnostic.

Sauvez un fichier déjà déformé

Jusqu'ici, chaque correctif supposait que le fichier sur le disque est toujours correct et que seul l'affichage est faux. Mais il arrive que la version déformée ait déjà été enregistrée, et la question devient alors de savoir si les caractères d'origine peuvent encore être récupérés à partir de la copie enregistrée. La réponse dépend exactement de ce que l'enregistrement a fait, et il faut distinguer deux cas. Dans le premier cas, le fichier sur le disque contient toujours les octets UTF-8 d'origine, et seul l'affichage dans Excel est faux. C'est le cas que le test de l'éditeur de texte détecte : l'éditeur affiche les caractères correctement, donc rien n'est perdu, et le correctif 1 répare l'affichage. Dans le deuxième cas, le fichier sur le disque contient maintenant les caractères erronés eux-mêmes, parce que quelqu'un l'a ouvert dans Excel, a vu le texte déformé, et l'a réenregistré en CSV, écrivant ainsi les caractères mal lus dans le fichier.

Le deuxième cas est souvent encore récupérable, et le test consiste à vérifier si le texte déformé suit le motif à de la section sur le décodage. Si le fichier enregistré contient littéralement les caractères é là où é devrait se trouver, la récupération est un réencodage : lisez le fichier comme s'il était en Windows-1252, ce qui récupère les octets UTF-8 d'origine, puis décodez ces octets en UTF-8, ce qui récupère les caractères d'origine. L'extrait ci-dessous fait exactement cela, et il a été vérifié sur un fichier réel : un nom écrit José, mal lu comme José, est revenu à José après l'aller-retour, octet par octet. Travaillez sur une copie, jamais sur la seule version, et vérifiez le résultat dans un éditeur de texte avant de l'ouvrir à nouveau dans Excel.

with open("mangled.csv", "r", encoding="cp1252") as f:\n    text = f.read()\n# Encode back to the bytes Excel misread, then decode as UTF-8.\nfixed = text.encode("cp1252").decode("utf-8")\nwith open("fixed.csv", "w", encoding="utf-8") as f:\n    f.write(fixed)\n# Verified: José -> José, München -> München.

L'astuce de réencodage a une limite stricte, et il est important de la respecter. Elle fonctionne seulement quand les caractères mal lus ont survécu à l'enregistrement intacts, sous la forme é et de ses compagnons. Si l'enregistrement a remplacé des caractères par des points d'interrogation, ou par le symbole losange noir de remplacement, l'information d'origine a disparu de cette copie. Aucun décodage ne peut récupérer un caractère qui a été remplacé par un espace réservé, parce que l'espace réservé ne porte aucune information sur le caractère qu'il a remplacé. Dans ce cas, arrêtez de réparer la copie et régénérez le fichier à partir de sa source : réexportez-le depuis la base de données, l'outil ou le JSON dont il provient, et cette fois ouvrez-le avec le correctif 1 ou donnez-lui un BOM avec le correctif 2. Et quoi que vous fassiez, gardez la copie abîmée de côté jusqu'à ce que le fichier régénéré soit vérifié. Supprimer la seule copie avant de vérifier le remplacement est la façon dont un problème récupérable devient un jeu de données perdu.

Ce que cela signifie pour les fichiers du convertisseur de cette page

Le convertisseur de cette page produit exactement le type de fichier dont parle ce guide, il vaut donc la peine d'énoncer son comportement clairement. Le téléchargement est de l'UTF-8 brut sans BOM. Cela a été vérifié sur le code réel, et non supposé : le téléchargement crée un Blob text/csv avec charset=utf-8 et n'écrit aucune marque initiale, et le moteur de conversion lui-même a été exécuté sur un échantillon contenant José García, München, François, Łódź, São Paulo, un montant en euros, Tokyo en japonais et des noms coréens, et il a produit chaque caractère de façon identique octet par octet, sans BOM au début de la sortie. Donc si votre fichier converti affiche des caractères bizarres dans Excel, la conversion n'a rien endommagé. Le fichier est de l'UTF-8 correct, et Excel a deviné le mauvais encodage au double-clic.

Cela vous donne deux options nettes pour les fichiers convertis. La première est la route par import : ouvrez le fichier téléchargé avec Données, puis À partir d'un texte ou d'un CSV, définissez l'origine du fichier sur 65001 : Unicode (UTF-8), et chargez. Les caractères se liront correctement, et vous n'avez rien changé au fichier, donc il reste valide pour tous les autres outils. La deuxième est la route par BOM : ouvrez le fichier téléchargé dans le Bloc-notes, enregistrez-le en UTF-8 avec BOM, et gardez cette copie pour Excel, tout en gardant le téléchargement d'origine pour tout le reste. Ne reconvertissez pas les données pour corriger un problème d'affichage d'encodage, et ne faites pas passer la sortie convertie par un tableur pour la réenregistrer, parce que cet aller-retour peut introduire exactement les décalages de délimiteur et d'encodage que ce guide existe pour prévenir. Corrigez l'ouverture, et non les données.

Un autre détail du convertisseur compte ici. Le convertisseur vous laisse choisir le délimiteur avant le téléchargement, et ce choix est indépendant de l'encodage. Un fichier peut avoir le bon délimiteur et un affichage d'encodage erroné en même temps, ou le bon encodage et le mauvais délimiteur, ou les deux erronés à la fois. Si votre fichier converti s'ouvre dans une seule colonne et que les caractères semblent erronés, corrigez les deux réglages dans le même import : choisissez le délimiteur que vous aviez choisi au moment de la conversion, et définissez l'origine du fichier sur 65001. Le guide compagnon sur le problème d'une seule colonne couvre la moitié délimiteur en détail, et il est lié dans les guides associés ci-dessous.

Liste de prévention : exportez correctement pour que personne n'ait à corriger

Les problèmes d'encodage sont un décalage entre l'auteur et le lecteur, donc la prévention consiste à faire en sorte que l'auteur déclare ce qu'il a écrit, d'une façon que le lecteur respectera. Passez en revue cette liste quand vous produisez un CSV, et la prochaine personne qui l'ouvrira n'aura pas besoin de ce guide. D'abord, connaissez votre encodage au moment de l'export. Si vos données contiennent quoi que ce soit au-delà de l'ASCII simple, exportez en UTF-8, et indiquez-le dans le nom du fichier ou dans la note qui voyage avec lui, parce qu'un fichier CSV ne peut pas le dire lui-même. Ensuite, si le public est Excel sous Windows, ajoutez un BOM à la copie Excel, ou exportez avec le format CSV UTF-8 depuis Enregistrer sous dans Excel, qui écrit un BOM pour vous. Troisièmement, si le fichier alimente aussi d'autres outils, gardez une copie en UTF-8 brut sans BOM pour eux, parce que certains analyseurs traitent un BOM comme une partie du premier en-tête.

Quatrièmement, ne réenregistrez jamais un fichier sauvé par-dessus l'original tant que vous n'avez pas vérifié le sauvetage dans un éditeur de texte. Un enregistrement depuis Excel réécrit à la fois le délimiteur et l'encodage avec les défauts propres à Excel, ce qui peut réintroduire le décalage pour le lecteur suivant, ou transformer un problème d'affichage en perte réelle de données. Cinquièmement, quand vous recevez un fichier, ouvrez-le d'abord dans un éditeur de texte si quoi que ce soit semble anormal, et confirmez l'encodage avant de laisser un tableur l'écraser. Et sixièmement, gardez les données sources. Un CSV est un instantané aplati, et non les données elles-mêmes, donc si un sauvetage tourne mal, la source vous permet d'exporter à nouveau proprement au lieu de réparer une copie abîmée. La plupart des histoires d'horreur d'encodage se terminent par quelqu'un qui découvre trop tard que le CSV abîmé était la seule copie. Ne laissez pas cela arriver à votre fichier.

Guides associés

• Votre CSV s'ouvre dans une seule colonne dans Excel : pourquoi et comment le corriger (Guide 2026) →
• Comment convertir un fichier JSON en CSV en ligne ? (Guide 2026) →
• Quelles sont les façons de convertir JSON en CSV localement ? 6 méthodes comparées (Guide 2026) →
• Pourquoi Excel supprime les zéros non significatifs de vos codes CSV, et comment les conserver (Guide 2026) →
• Pourquoi Excel change les dates de votre CSV, et comment les conserver (Guide 2026) →
• Pourquoi l'enregistrement de votre CSV dans Excel le modifie, et comment protéger l'original (Guide 2026) →
• Fichier CSV trop volumineux pour Excel : pourquoi Excel ne l'ouvre pas et que faire à la place (Guide 2026) →

Questions fréquentes