Emoji-verminking in een geëxporteerd dagboekbestand opsporen

Bekijk één getroffen dagboeknotitie goed. Een reeks onverwachte tekens, zoals 😀 op de plek van 😀, kan erop wijzen dat UTF-8-bytes met een andere tekencodering zijn geïnterpreteerd. Dit wordt vaak mojibake genoemd: de weergegeven tekens zijn verkeerd omdat de bytes op basis van verkeerde aannames zijn gedecodeerd. Het is een aanwijzing, maar bewijst niet welke tekencodering voor het bestand is gebruikt.

Een zichtbare � is iets anders. Dat is U+FFFD, het vervangingsteken van Unicode, dat wordt gebruikt als vervanging voor een teken dat niet kan worden geïnterpreteerd. De woordenlijst van Unicode maakt onderscheid met een vervangingsglyph: een lettertype of renderer kan een vakje weergeven als een teken niet kan worden getekend, terwijl het onderliggende teken intact kan zijn. Als slechts enkele emoji als vakjes verschijnen, controleer dan eerst een andere actuele app of een ander lettertype voordat je de tekencodering van het bestand wijzigt.

Maak een kopie van de export en laat het origineel ongewijzigd. Noteer de bestandsextensie, de app waarmee het bestand is geëxporteerd en wat je ziet bij één getroffen zin. Vergelijk indien mogelijk een bekende emoji in het dagboek met dezelfde notitie in de bronapp of in een eerdere export. Open en bewaar niet steeds opnieuw het enige exemplaar: een teksteditor kan de opnieuw gedecodeerde tekst als bytes opslaan, waardoor een omkeerbare weergavetest permanent wordt.

Open de kopie als platte tekst in een editor waarin je de tekencodering kunt kiezen. Probeer eerst de tekencodering die de dagboekapp documenteert. Als die onbekend is en het om een gangbare moderne tekstexport gaat, is UTF-8 een redelijke optie om te bekijken, maar geen aanname om over het origineel heen op te slaan. Vergelijk de getroffen tekst en de gewone tekens eromheen bij elke kandidaat. Een samenhangend resultaat in het hele bestand is sterker bewijs dan een emoji die er toevallig goed uitziet.

Als de vreemde tekenreeks in de weergave van de editor verandert in de verwachte emoji wanneer je de tekencodering wijzigt, en de omliggende tekst ook leesbaar wordt, kan het zijn dat de export intacte bytes bevat die verkeerd zijn geïnterpreteerd. Bevestig dit door de kopie te sluiten zonder op te slaan en opnieuw te openen met de veelbelovende instelling. Controleer daarna of de import- of openprocedure van de dagboekapp een gedocumenteerde keuze voor de tekencodering biedt. Gebruik die procedure voor een eventuele daadwerkelijke herimport.

De Unicode UTF FAQ legt uit dat ongeldige UTF-8-bytereeksen een fout kunnen veroorzaken of kunnen worden afgehandeld met een markering zoals U+FFFD. Dat betekent dat een decoder ongeldige invoer mogelijk al heeft vervangen tijdens het weergeven of importeren. De tekencodering daarna omschakelen herstelt de oorspronkelijke bytes niet noodzakelijkerwijs. Gebruik op je enige kopie geen opties voor reparatie of conversie die onleesbare tekens stilzwijgend vervangen.

Als de emoji in een andere weergave correct verschijnt, bewaar die vergelijking dan als bewijs voordat je het bestand wijzigt. Herschrijf de export niet alleen om het uiterlijk ervan aan te passen.

Als op dezelfde plek in verschillende weergaven U+FFFD of een letterlijk vraagteken staat, vergelijk dit dan met het brondagboek of een eerdere export. Een vervangingsteken dat in het bestand is opgeslagen, kan niet met een ander lettertype worden hersteld. Herstel is afhankelijk van een andere kopie waarin het teken nog staat.

De extensie .csv vertelt niet welke tekencodering is gebruikt, en spreadsheetprogramma’s kunnen importinstellingen toepassen. Voor de desktopversie van Excel documenteert Microsoft het importeren van tekst via Data > From Text/CSV en de wizard Tekst importeren in de handleiding voor het importeren en exporteren van tekst en CSV. Controleer het voorbeeld voordat je het bestand laadt: verifieer de emoji, de grenzen van rijen en kolommen en de omliggende tekst. Een correct voorbeeld is bewijs dat de gekozen importmethode het bestand naar verwachting leest, maar geen reden om de bron te overschrijven.

Bewaar JSON-bestanden en gebruik een JSON-bewuste importfunctie in plaats van ze als CSV te behandelen. De JSON-specificatie RFC 8259 schrijft UTF-8 voor voor JSON die wordt uitgewisseld tussen systemen buiten een gesloten ecosysteem. De specificatie legt ook uit dat JSON-tekenreeksen tekens rechtstreeks of met escape-reeksen kunnen weergeven. Een escape-reeks zoals \u263A is niet automatisch een teken van beschadiging; een JSON-parser hoort geldige escape-reeksen te interpreteren. Als de JSON ongeldig is of de importfunctie een parsefout meldt, stop dan en bewaar het exacte bestand in plaats van op goed geluk leestekens of bytes te bewerken.

Volg deze stappen: (1) vergelijk het brondagboek met de export; (2) inspecteer een duplicaat met de verwachte tekencodering en, indien van toepassing, een UTF-8-weergave; (3) controleer in een andere weergave of er sprake is van ontbrekende glyphs; (4) bekijk het voorbeeld via de juiste CSV- of JSON-importfunctie; en (5) probeer de export opnieuw met een gedocumenteerde tekencodering als de emoji in de bron nog steeds correct wordt weergegeven. Wijzig telkens één variabele en bewaar elk resultaat afzonderlijk.

Als geen enkele weergave of importfunctie het oorspronkelijke teken zichtbaar maakt en het bestand alleen vervangingstekens of andere vervangende gegevens bevat, beloof dan geen herstel door de tekencodering te wijzigen. Andere decodeerinstellingen kunnen niet achterhalen welke emoji verloren is gegaan. Zoek naar een andere export, een back-up of de intacte dagboeknotitie. Exporteer het bestand daarna opnieuw naar een nieuw bestand en controleer het voorbeeld voordat je erop vertrouwt.