Nettoyer un CSV des problèmes Windows-1251 et de BOM avant de l'importer

Un fichier peut paraître normal tout en ayant le mauvais encodage

Un fichier CSV exporté depuis un ancien logiciel de comptabilité ou de base de données n’est bien souvent pas du tout en UTF-8. Windows-1251 pour le texte cyrillique et Windows-1252 pour les caractères accentués d’Europe de l’Ouest restent des formats de sortie fréquents dans des systèmes conçus il y a des années. Un tableur affichera souvent ce type de fichier sans se plaindre, car il applique automatiquement sa propre estimation d’encodage. Le fichier a donc l’air normal jusqu’au moment où il est lu par quelque chose de moins tolérant, comme un script, un pipeline d’import ou un chargeur de base de données, qui suppose de l’UTF-8 et reçoit à la place un bloc de caractères illisibles au lieu du texte attendu.

Un marqueur de trois octets au début du fichier peut bloquer un parseur strict

Un marqueur d’ordre des octets UTF-8 (BOM) est un indicateur invisible, trois octets seulement, placé tout au début d’un fichier pour signaler que le texte qui suit est en Unicode. Il est utile pour un programme comme Excel qui le recherche. Il devient un problème dès que la destination est un importeur JSON strict ou un script qui ne s’y attend pas. Ces octets supplémentaires se retrouvent accrochés au premier caractère du premier en-tête de colonne, si bien qu’une colonne censée s’appeler « id » ne correspond plus à ce nom partout ailleurs dans le code. Détecter et retirer ce marqueur avant la conversion, au lieu de le laisser dans le fichier obtenu, évite un décalage difficile à diagnostiquer après coup.

Obtenir automatiquement le bon encodage, sans liste d’options

Une détection fiable de l’encodage, celle que lance CSV en JSON avant de lire la moindre ligne, commence par chercher un marqueur d’ordre des octets, puis tente de valider strictement le reste des octets comme de l’UTF-8, et ne revient à Windows-1251 ou Windows-1252, en fonction de la répartition des octets de valeur élevée, que si cette validation stricte échoue. Cet ordre est important. Un fichier déjà en UTF-8 n’est jamais réinterprété à tort comme autre chose, tandis qu’un fichier qui n’est pas en UTF-8 est correctement identifié au lieu d’être forcé en UTF-8 et transformé en texte brouillé au passage. La même détection précède CSV en Excel, pour les cas où la destination est une feuille de calcul et non un script.

Les types de données comptent autant que l’encodage des caractères

Corriger l’encodage des caractères ne résout qu’une partie de ce qui casse lors d’une conversion CSV vers JSON. L’autre partie consiste à décider quelles valeurs doivent devenir des nombres ou des booléens JSON et lesquelles doivent rester du texte brut. Une valeur comme 00123 transformée en nombre 123 perd définitivement son zéro initial au moment de la conversion, et un identifiant de plus d’une quinzaine de chiffres est arrondi dès qu’il devient un nombre à virgule flottante standard au lieu de rester du texte. Ces deux valeurs devraient rester des chaînes de caractères, car les convertir modifie les données elles-mêmes, pas seulement leur format ou leur apparence.

Un en-tête dupliqué perturbe l’import autrement qu’un mauvais encodage

Les objets JSON ne peuvent pas contenir deux propriétés avec la même clé. Un fichier source avec deux colonnes qui partagent par hasard le même nom d’en-tête, ce qui est fréquent dans des exports assemblés à partir de plus d’un système source, demande donc que ces doublons soient renommés en quelque chose de distinct pendant la conversion. Sinon, les données de la deuxième colonne écrasent celles de la première dans chaque objet obtenu, sans aucun avertissement. C’est un mode de défaillance différent de l’encodage ou du typage, mais il peut tout autant corrompre un import de façon silencieuse. Il vaut la peine de vérifier qu’un outil de conversion signale ce cas plutôt que de résoudre le conflit de manière invisible, et passer le résultat dans Formateur JSON montre d’un coup d’œil les clés renommées.

Pas à pas : vérifier le fichier avant qu’il n’entre dans l’import

Convertissez l’export une première fois dans CSV en JSON avec le délimiteur et l’encodage en détection automatique, puis vérifiez ces deux estimations : passez le résultat à Formateur JSON, l’une des étapes suivantes que propose la page, et lisez les premiers enregistrements. Du cyrillique illisible ou des accents cassés signalent une erreur d’encodage ; une seule longue clé qui contient encore les séparateurs signale une erreur de délimiteur. Corrigez à la main celui qui s’est trompé, puis convertissez de nouveau : le menu d’encodage propose Windows-1251, Windows-1252, UTF-8 avec ou sans BOM et UTF-16 LE, celui du délimiteur la virgule, le point-virgule, la tabulation, la barre verticale ou un caractère de votre choix. Un fichier dont le séparateur ou l’encodage reste incompréhensible est refusé avec un message au lieu d’être converti en charabia.

Décidez ensuite du typage des valeurs : par défaut, l’outil garde déjà en texte les valeurs à zéro initial et les identifiants longs, et pour un fichier fait de codes, de numéros de téléphone ou de numéros de compte, passer les types de valeurs sur tout conserver en texte ne convertit plus rien. Le résultat ouvert dans Formateur JSON, cherchez deux traces d’une source mal tenue : deux colonnes intitulées id ressortent en id et id_2, et une ligne qui a plus de champs que l’en-tête range son surplus sous une clé __extra. Les deux se corrigent à moindre coût dans le fichier source plutôt que dans le système qui finirait par s’étrangler dessus. Jusqu’à vingt fichiers, 300 Mo au total, passent en un seul lot sans quitter l’onglet du navigateur.