Convertisseur d'encodage

À propos du Convertisseur d'encodage

Vous ouvrez un fichier et, au lieu de mots, vous voyez Café, 버그, 文字化ã ou une file de points d'interrogation. Le texte n'est pas abîmé — il est simplement lu avec le mauvais encodage. Cet outil le lit avec le bon et le réenregistre en UTF-8, pour que tous les programmes suivants l'affichent correctement.

C'est le travail que fait chcp dans l'invite de commandes Windows, et *Enregistrer sous → Encodage* dans le Bloc-notes. Ici, deux clics suffisent, et le fichier reste sur votre appareil : c'est votre navigateur qui décode.

Deux problèmes courants qu'il règle

• Un fichier venant d'un vieux logiciel — un CSV, un fichier de sous-titres ou un .txt enregistré dans l'ancien jeu de caractères de votre pays (Windows-1252, EUC-KR, Shift_JIS, GBK, Big5, Windows-1251…). Choisissez ce jeu sous Lire le fichier comme, puis enregistrez en UTF-8.
• Le mojibake — du texte déjà en Unicode qui affiche é là où il devrait y avoir é, parce que des octets UTF-8 ont été lus comme du Windows-1252 quelque part en chemin. Cochez Réparer et tout est remis d'aplomb.

Ce que vous pouvez faire

• Convertir de l'ANSI en UTF-8 pour qu'un fichier s'ouvre correctement partout
• Ajouter un BOM UTF-8 pour qu'Excel cesse de massacrer les accents en ouvrant votre CSV
• Retirer un BOM qui gêne un programme ou une page web
• Réparer un fichier de sous-titres (.srt, .vtt) dont les accents ou le hangul sortent en symboles
• Convertir des fichiers coréens EUC-KR, japonais Shift_JIS, chinois GBK ou Big5 en UTF-8
• Changer les fins de ligne entre Windows (CRLF) et Mac/Linux (LF) au passage

Fonctionnalités

• Détection automatique — BOM, UTF-16 et UTF-8 valide sont repérés pour vous, et l'estimation est affichée
• Plus de 20 encodages en lecture — UTF-8, UTF-16 LE/BE, la famille Windows-125x, ISO-8859, EUC-KR, Shift_JIS, EUC-JP, GBK, GB18030, Big5, KOI8-R et Mac Roman
• Six formats d'enregistrement — UTF-8, UTF-8 avec BOM, UTF-16 LE, UTF-16 BE, Windows-1252 et ISO-8859-1
• Réparation du mojibake pour le cas classique de l'UTF-8 lu en 1252
• Contrôle des fins de ligne — conserver, CRLF ou LF
• Aperçu en direct pour vérifier avant de télécharger
• Un avertissement si des caractères seraient perdus en enregistrant dans un petit jeu de caractères
• Mode collage pour un bout de texte abîmé, quand vous n'avez pas de fichier
• 100 % dans votre navigateur — rien n'est envoyé

Quelle est la fiabilité de la détection ? Pourquoi ce champ « Lire le fichier comme » ?

Un fichier texte brut n'est que des octets — il ne consigne son encodage nulle part. C'est précisément pour cela que le HTML a besoin de <meta charset> et l'e-mail d'un en-tête charset= : sans eux, l'encodage doit être déduit des octets.

Et les mêmes octets sont valides dans de nombreux encodages. Les deux octets B0 A1 sont valides dans tous ceux-ci :

| Lu comme | Vous obtenez |

|---|---|

| EUC-KR | 가 |

| GB18030 | 啊 |

| Big5 | 陛 |

| Windows-1252 | °¡ |

| Windows-1251 | °Ў |

Une vérification stricte ne tranche pas non plus : du vrai texte coréen se décode sans la moindre erreur en Shift_JIS, Big5, GB18030 et Windows-1251 également. L'outil juge donc le *résultat* : il décode avec chaque candidat et garde celui qui produit une écriture cohérente avec une proportion sensée de caractères non anglais.

Ce que cela donne en pratique :

• UTF-8, UTF-16 et tout fichier avec un BOM — identifiés avec certitude.
• Du texte anglais simple — certain, et tous les encodages proposés ici le lisent à l'identique.
• Un ancien jeu de caractères — l'outil nomme le plus probable et affiche les suivants sous forme de boutons cliquables. Le coréen, le japonais et le cyrillique sont généralement identifiés exactement.
• Chinois simplifié / traditionnel / kanji japonais, et Windows-1252 / 1258, peuvent être réellement indiscernables : les motifs d'octets se recouvrent. C'est là que vous utilisez Lire le fichier comme et laissez l'aperçu décider.

Ce champ est un recours, pas une étape. Laissez-le sur Détecter pour moi tant que l'aperçu est correct.

Pourquoi mon fichier n'a-t-il pas changé ?

C'est la surprise la plus fréquente, et ce n'est pas un défaut. Si votre texte n'utilise que des lettres anglaises, des chiffres et de la ponctuation (ce qu'on appelle l'ASCII), alors UTF-8, Windows-1252 et ISO-8859-1 le stockent avec exactement les mêmes octets. Il n'y a rien à convertir : le fichier enregistré est identique et n'importe quel outil de vérification annonce encore UTF-8.

L'outil vous le signale désormais. Si vous voulez que les octets diffèrent vraiment, choisissez UTF-16 LE / BE ou UTF-8 avec BOM — ceux-là changent toujours le fichier. Les encodages ne commencent à diverger qu'une fois que votre texte contient des accents, du hangul, des kanji, du cyrillique ou d'autres caractères non anglais.

Comment l'utiliser

• Déposez votre fichier texte — l'outil devine l'encodage et vous montre le texte
• Regardez l'aperçu. S'il se lit correctement, c'est terminé ; sinon, changez Lire le fichier comme pour le jeu de caractères d'origine, ou cochez Réparer en cas de dégâts du type é
• Choisissez le format d'enregistrement — UTF-8 (sans BOM) est la bonne réponse presque à tous les coups. Prenez UTF-8 avec BOM si le fichier est un CSV que vous ouvrirez dans Excel
• (Facultatif) réglez les fins de ligne souhaitées
• Cliquez sur Télécharger pour enregistrer le fichier corrigé. L'encodage est inscrit dans le nom du fichier — notes-ANSI-1252-AppAndTools.txt, notes-UTF-8-AppAndTools.txt — pour que deux versions du même fichier restent toujours distinguables