Données et feuilles de calcul · CSV Nettoyeur
Comment UTF-8 et Windows-1252 se confondent : réparer une exportation Mojibake CSV
· Comment ça marche
csv codage data-cleaning
Lorsque 'José' devient 'José', les octets sont bons et l'interprétation est fausse. Cet article explique comment les deux encodages les plus courants entrent en collision, comment reconnaître les symptômes et comment le redécodage les répare.
Noms accentués et guillemets bouclés transformés en soupe de symboles : les modèles révélateurs d'un fichier UTF-8 se lisent comme Windows-1252, et inversement
Un nom de client qui devient des diamants de remplacement après le chargement ne constitue pas une preuve que CSV Cleaner a détecté la mauvaise page de codes héritée. La configuration dit le contraire : seul UTF-8 est compris, et un fichier Windows-1252 ou Shift-JIS est lu comme UTF-8. Les séquences d'octets invalides peuvent donc déjà être remplacées avant que l'analyseur CSV ne voie les caractères.
Le plan est centré sur des mojibake familiers tels que José, mais le chemin de lecture du navigateur utilise `File.text()` et ne fournit aucun sélecteur d'encodage. Cet article corrige cette promesse. Le symptôme exploitable dans cet outil est le remplacement de caractères ou de texte autrement endommagé, les octets du fichier d'origine étant conservés pour une récupération ailleurs.
Un fichier non-UTF-8 atteint cet outil en tant que caractères de remplacement, et non un modèle Mojibake vérifié.
Un fichier délimité représente des octets sur le disque, tandis que l'analyseur opère sur une chaîne JavaScript. Un encodage définit le mappage entre ces couches. La syntaxe CSV nomme les virgules, les guillemets et les limites d'enregistrement, mais ne contient aucune déclaration fiable sur le disque indiquant à `File.text()` quel mappage hérité a créé chaque octet non-ASCII.
Une fois que le décodage a produit des caractères de remplacement U+FFFD, les opérations CSV ultérieures reçoivent ces espaces réservés sous forme de texte ordinaire. Le découpage ou l'exportation ne peuvent pas déduire quelle séquence d'octets ou quel caractère d'origine y appartenait. C'est pourquoi la source intacte compte plus qu'une liste de recherche et de remplacement assemblée à partir de l'écran endommagé.
Les deux suspects habituels : les séquences multi-octets de UTF-8 et les octets uniques de Windows-1252, et pourquoi elles produisent des déchets prévisibles lorsqu'elles sont échangées
UTF-8 représente des caractères non-ASCII avec des séquences multi-octets. Windows-1252 attribue de nombreux caractères occidentaux à des valeurs d'octet individuelles. La lecture d'une convention sous une autre peut échouer ou créer un texte trompeur, mais cette voie ne teste pas les décodeurs alternatifs, n'évalue pas le langage plausible et n'offre pas de sélection Windows-1252.
Le seul comportement de l'analyseur spécifique au codage est la suppression d'une marque d'ordre d'octet U+FEFF UTF-8 en tête après le décodage du texte. Cela empêche le marqueur de rejoindre le premier en-tête. Il ne s'agit pas d'une détection de codage générale et ne fournit aucune prise en charge de Shift-JIS, UTF-16 ou des pages de codes régionales mentionnées nulle part dans l'implémentation.
ToolAcre accepte le texte UTF-8 et ne compare pas les candidats Windows-1252
Les caractères de remplacement indiquent que le décodeur de texte n'a pas pu mapper certains octets d'entrée selon l'interprétation choisie. Des points d'interrogation peuvent avoir été insérés lors d'une exportation antérieure avec perte, auquel cas le caractère original pourrait déjà être indisponible. Une séquence à reconnaissable peut apparaître dans d'autres flux de travail, mais cette page ne diagnostique pas son historique.
Ne décidez pas du codage source à partir d'un seul nom de famille. Vérifiez les paramètres de l'application d'exportation, la provenance du fichier et un inspecteur prenant en compte les octets qui laisse la source intacte. Les avertissements des lignes du nettoyeur concernent la fermeture des citations et la largeur des colonnes ; ils ne constituent pas une preuve que le codage des caractères est correct.
Re-décodage, pas rechercher et remplacer - pourquoi le correctif consiste à lire les octets avec le bon encodage et à écrire UTF-8, plutôt que de corriger les caractères un par un
La réparation fiable consiste à revenir aux octets d'origine et à les décoder une fois avec le codage source documenté, puis à écrire UTF-8. Cette opération doit être effectuée avant l'ouverture via un chemin de texte uniquement UTF-8. Le remplacement de fragments de déchets visibles après le décodage peut corrompre les occurrences légitimes et ne peut pas distinguer plusieurs caractères originaux réduits à un seul espace réservé.
CSV Cleaner n'a pas de contrôle de recodage au niveau des octets, il ne peut donc pas effectuer la conversion promise du plan. Utilisez une méthode de conversion fiable prenant en compte la source, comparez les noms représentatifs avec le système source, puis apportez le résultat UTF-8 ici pour le délimiteur, les guillemets, les espaces et le travail en double.
Récupérer à partir des octets d'origine en dehors de cet outil ; le remplacement des personnages ici ne peut pas les restaurer
Pour une démonstration en toute sécurité, créez un petit fichier codé hérité contenant un nom accentué et conservez une copie hexadécimale. Chargez-le dans l'outil et observez si des caractères de remplacement apparaissent. Cette observation établit la limite UTF-8 ; il n'établit pas la page de codes d'origine simplement parce que le nom attendu est connu.
Convertissez ensuite les octets intacts avec un décodeur explicitement sélectionné en dehors de ToolAcre, enregistrez UTF-8 et chargez ce résultat. Le nom devrait maintenant arriver intact tandis que l'analyseur CSV gère normalement les séparateurs. La comparaison de ces deux chemins donne la bonne leçon sans prétendre que le nettoyeur a effectué lui-même la récupération.
Exemple concret : démontrer la limite UTF-8 sans réclamer une réparation non prise en charge
Un fichier doublement codé peut nécessiter la reconstruction d'une transformation antérieure, et les données déjà enregistrées avec des points d'interrogation littéraux peuvent être irrécupérables sans une autre source. Cet article ne prescrit pas d'inversion universelle car l'implémentation ne contient aucun historique de codage ni fonction de récupération préservant les octets.
Cela évite également de revendiquer la prise en charge de UTF-16, des encodages d'Asie de l'Est ou des formulaires de normalisation. Si cela est important, choisissez un convertisseur qui les nomme et les teste. Une analyse CSV réussie prouve uniquement que la machine à états de délimiteur a trouvé les lignes ; cela ne dit rien sur la fidélité du décodage des caractères avant cette étape.
Corrigez l'interprétation une fois - comment la réparation de l'encodage de ToolAcre CSV Cleaner re-décode et ré-encode l'exportation sur votre appareil
ToolAcre peut supprimer une nomenclature UTF-8 principale et sérialiser la chaîne résultante sous le nom UTF-8 CSV via le chemin de téléchargement du navigateur. Il ne peut pas transformer des octets arbitraires en Unicode correct, car ces octets ont déjà franchi la limite fixe de lecture de texte du navigateur sans décodeur sélectionné par l'utilisateur.
Traitez les marques de remplacement comme un signal d'arrêt. Préservez la source, identifiez son encodage auprès du producteur, convertissez-la une fois avec un outil prenant en charge les octets approprié et vérifiez les noms importants. Alors seulement, utilisez CSV Cleaner pour les tâches structurelles que sa configuration promet réellement.