Comment diagnostiquer les emojis illisibles dans un fichier de journal intime exporté
Si les emojis s'affichent mal dans un journal exporté, déterminez d'abord si les caractères ont été décodés avec le mauvais encodage, remplacés lors de l'exportation, ou décodés correctement mais impossibles à afficher par l'application ou la police. Travaillez sur une copie du fichier, préservez les octets d'origine et comparez le même texte dans un éditeur de texte brut et dans l'outil d'importation du journal. Modifier un paramètre d'encodage peut corriger une erreur de décodage ; cela ne peut pas restaurer des informations déjà remplacées ou supprimées.
Identifier à quoi ressemble un texte « corrompu »
Examinez attentivement une entrée concernée. Une suite de caractères inattendus tels que `😀` là où devrait se trouver 😀 peut indiquer que des octets UTF-8 ont été interprétés avec un encodage différent. C'est ce qu'on appelle communément le mojibake : les caractères affichés sont erronés parce que les octets ont été décodés selon de mauvaises hypothèses. C'est un indice, pas une preuve de l'encodage utilisé pour générer le fichier.
Un `` visible est différent. Il s'agit de U+FFFD, le caractère de remplacement d'Unicode, utilisé pour se substituer à un caractère qui ne peut pas être interprété. Le [glossaire](https://www.unicode.org/glossary/#replacement_character) d'Unicode le distingue d'un glyphe de remplacement : une police ou un moteur de rendu peut afficher un carré lorsqu'il ne peut pas dessiner un caractère, alors que le caractère sous-jacent peut être intact. Si seuls certains emojis apparaissent sous forme de carrés, testez une autre application récente ou une autre police avant de modifier l'encodage du fichier.
Préserver une base de référence avant le dépannage
Faites une copie de l'export et conservez l'original intact. Notez l'extension du nom de fichier, l'application qui l'a exporté et ce que vous observez pour une phrase affectée. Si possible, comparez un emoji connu du journal avec la même entrée dans l'application source ou dans un export antérieur. Évitez d'ouvrir et d'enregistrer répétitivement l'unique copie : un éditeur de texte peut réécrire le texte nouvellement décodé sous forme d'octets, rendant définitive une simple expérience d'affichage réversible.
Ouvrez la copie sous forme de texte brut dans un éditeur qui vous permet de choisir un encodage. Essayez d'abord l'encodage documenté par l'application de journal ; s'il est inconnu et que le fichier est un export de texte moderne classique, l'UTF-8 est un bon candidat à examiner, et non une certitude à enregistrer par-dessus l'original. Comparez le texte affecté et les caractères ordinaires environnants avec chaque candidat. Un résultat cohérent sur l'ensemble du fichier constitue une preuve plus solide qu'un emoji qui semble simplement correct par hasard.
Tester le décodage sans réécrire
Lorsque la modification du mode d'encodage de l'éditeur transforme la séquence étrange en l'emoji attendu et que le texte environnant redevient également lisible, l'export contient peut-être des octets intacts qui étaient simplement mal interprétés. Confirmez en fermant la copie sans enregistrer et en la rouvrant avec le réglage prometteur. Vérifiez ensuite si le processus d'importation ou d'ouverture de l'application de journal propose un choix d'encodage documenté ; privilégiez ce processus pour toute réimportation réelle.
La [FAQ Unicode sur l'UTF](https://www.unicode.org/faq/utf_bom.html) explique que les séquences d'octets UTF-8 mal formées peuvent déclencher une erreur ou être traitées avec un marqueur tel que U+FFFD. Cela signifie qu'un décodeur a peut-être déjà remplacé une entrée invalide lors de son affichage ou de son importation. Changer d'encodage après cette étape ne permettra pas nécessairement de récupérer les octets d'origine. N'utilisez pas d'options de « réparation » ou de conversion qui remplacent silencieusement les caractères indécodables sur votre unique copie.
Distinguer les problèmes d'encodage des glyphes manquants
Si l'emoji s'affiche correctement dans une autre visionneuse, gardez cette comparaison comme preuve avant de modifier le fichier. Évitez de réécrire l'export simplement pour modifier son apparence.
Si la même position contient U+FFFD ou un point d'interrogation littéral dans toutes les visionneuses, comparez avec le journal d'origine ou un export plus ancien. Un caractère de remplacement stocké dans le fichier ne peut pas être restauré en changeant de police. La récupération dépend de l'existence d'une autre copie ayant conservé le caractère.
Traiter CSV et JSON comme des parcours d'importation différents
Une extension `.csv` n'indique pas quel encodage de caractères a été utilisé, et les tableurs peuvent appliquer des paramètres d'importation automatiques. Pour Excel sur ordinateur, Microsoft documente l'importation de texte via **Données > À partir d'un fichier texte/CSV** et l'Assistant Importation de texte dans son [guide d'importation/exportation de fichiers texte et CSV](https://support.microsoft.com/en-us/excel/get-started/import-or-export-text-txt-or-csv-files). Utilisez l'aperçu avant de charger : vérifiez les emojis, les délimitations de lignes et de colonnes, ainsi que le texte adjacent. Un aperçu correct prouve que le chemin d'importation sélectionné lit le fichier comme prévu ; ce n'est pas une raison pour écraser le fichier source.
Pour le JSON, préservez le fichier et utilisez un outil d'importation prenant en charge le JSON plutôt que de le traiter comme un CSV. La [spécification JSON RFC 8259](https://www.rfc-editor.org/rfc/rfc8259#section-8.1) impose l'UTF-8 pour le JSON échangé entre des systèmes en dehors d'un écosystème fermé. Elle explique également que les chaînes JSON peuvent représenter les caractères directement ou avec des séquences d'échappement. Voir un échappement tel que `\\u263A` n'est pas automatiquement une corruption ; un analyseur JSON doit interpréter les échappements valides. Si le JSON est invalide ou si l'outil d'importation signale une erreur d'analyse, arrêtez-vous et conservez le fichier exact plutôt que de modifier la ponctuation ou les octets au hasard.
Décider s'il faut réessayer, réexporter ou s'arrêter
Suivez cette séquence : (1) comparez le journal source avec l'export ; (2) inspectez un double en utilisant l'encodage attendu et un affichage en UTF-8 si approprié ; (3) vérifiez dans une autre visionneuse s'il s'agit d'un problème de glyphe manquant ; (4) prévisualisez le fichier via l'importateur CSV ou JSON approprié ; et (5) réessayez d'exporter avec un encodage de texte documenté si la source affiche toujours l'emoji correctement. Modifiez une seule variable à la fois et conservez chaque résultat séparément.
Si aucun affichage ni importateur ne révèle le caractère d'origine, et que le fichier ne contient que des caractères de remplacement ou d'autres données substituées, ne promettez pas une récupération par réencodage. Modifier les paramètres de décodage ne peut pas deviner quel emoji a été écarté. Recherchez un autre export, une sauvegarde ou l'entrée de journal intacte, puis exportez à nouveau vers un nouveau fichier et vérifiez son aperçu avant de vous y fier.