Off Cloud by Design
Guides pratiques

Convertir un fichier Windows-1252 en UTF-8 en conservant les fins de ligne

Un exemple octet par octet pour préserver accents, symbole euro et CRLF lors d’une conversion locale en UTF-8.

Partir du fichier original

L’inspecteur d’encodage et convertisseur UTF-8 lit les octets du fichier avant leur interprétation. Choisissez l’export d’origine plutôt que de copier un texte déjà abîmé depuis un éditeur. Des octets UTF-8 valides ne prouvent pas que cet encodage était celui voulu.

Un exemple exact à reproduire

Cliquez sur Charger un exemple Windows-1252. Le fichier fictif contient exactement huit octets : 43 61 66 E9 20 80 0D 0A. Windows-1252 est choisi explicitement. Le texte Unicode attendu est Café €\r\n : la notation finale représente un vrai CR suivi d’un LF, pas quatre caractères littéraux.

Les points de code sont U+0043 U+0061 U+0066 U+00E9 U+0020 U+20AC U+000D U+000A. Ce fichier n’est pas un UTF-8 strict valide : E9 n’est pas suivi des octets de continuation nécessaires. Cela impose de vérifier l’encodage source ; cela ne prouve pas que tout fichier semblable est en Windows-1252.

  1. Gardez Windows-1252 puis cliquez sur Prévisualiser la conversion.
  2. Vérifiez Café € dans l’aperçu, un CRLF dans les détails et la présence du saut de ligne final.
  3. Laissez le BOM de sortie décoché, sauf demande explicite du logiciel destinataire.
  4. Téléchargez le résultat : ses onze octets sont 43 61 66 C3 A9 20 E2 82 AC 0D 0A.
  5. Si vous cochez le BOM, prévisualisez de nouveau : le fichier compte quatorze octets, avec EF BB BF avant les onze précédents.

Pourquoi « ANSI » ne suffit pas

L’étiquette « ANSI » d’un logiciel est ambiguë. Windows-1252 associe 80 au symbole euro ; ISO-8859-1 l’associe à U+0080, un contrôle C1 refusé par cet outil. Les octets 81, 8D, 8F, 90 et 9D sont non définis dans sa correspondance stricte Windows-1252 : ils arrêtent la conversion. Demandez l’encodage exact au producteur de l’export, au lieu de choisir simplement un aperçu plausible.

BOM, UTF-16 et fin de fichier incomplète

FF FE 41 00 0D 00 0A 00 représente un exemple UTF-16LE avec BOM. En UTF-8 sans BOM, il devient 41 0D 0A : A suivi de CRLF. Sans BOM, sélectionnez UTF-16 explicitement. Un dernier octet isolé ou une paire de substituts incorrecte bloque la conversion, même après la partie affichée. Un BOM UTF-32 est reconnu, mais ce format est refusé.

Ce qui reste intact, ce qui ne se répare pas

Les espaces, tabulations, fins de ligne CRLF/LF/CR mélangées, présence ou absence de saut final et caractères Unicode composés ou combinés restent intacts. Seul le BOM initial de la source est retiré ; celui de sortie dépend de votre choix. Un U+FFFD déjà présent est conservé. Convertir « Café » déjà corrompu ne reconstitue pas les octets initiaux.

Limite : 5 Mio (5 242 880 octets). L’aperçu est limité à 16 000 unités de code UTF-16, mais validation et export portent sur tout le fichier. Les signatures binaires reconnues et contrôles NUL/C0/C1, hors tabulation, CR et LF, sont refusés. Cette précaution peut écarter un texte légitime inhabituel. Le téléchargement est en texte brut .utf8.txt ; l’original n’est pas écrasé.

Pour un CSV, convertissez d’abord l’encodage, puis utilisez le convertisseur CSV vers JSON pour changer sa structure. L’inspecteur ne modifie pas les séparateurs et n’analyse pas le CSV. Le traitement se fait en mémoire, sans requête réseau ni stockage de l’outil ; le site charge toujours ses ressources. Retrouvez l’inspecteur d’encodage pour essayer l’exemple.