Så diagnostiserar du förvanskade emoji i en exporterad dagboksfil

Titta noga på en berörd dagboksanteckning. En följd oväntade tecken som 😀 där 😀 borde finnas kan tyda på att UTF-8-bytes tolkades med en annan teckenkodning. Det kallas ofta mojibake: de visade tecknen är fel eftersom byten avkodades utifrån fel antaganden. Det är en ledtråd, inte ett bevis på vilken teckenkodning som skapade filen.

Ett synligt � är något annat. Det är U+FFFD, Unicode-ersättningstecknet, som används i stället för ett tecken som inte kan tolkas. Unicode-ordlistan glossary skiljer det från en ersättningsglyf: ett teckensnitt eller en renderare kan visa en ruta när den inte kan rita ett tecken, medan det underliggande tecknet fortfarande kan vara intakt. Om bara vissa emoji visas som rutor bör du kontrollera dem i en annan aktuell app eller med ett annat teckensnitt innan du ändrar filens teckenkodning.

Skapa en kopia av exporten och låt originalet vara oförändrat. Anteckna filändelsen, appen som exporterade den och hur en berörd fras ser ut. Om möjligt kan du jämföra en emoji från dagboken med samma anteckning i källappen eller en tidigare export. Undvik att öppna och spara den enda kopian upprepade gånger: en textredigerare kan skriva tillbaka nyavkodad text som byte, så att ett reversibelt visningsexperiment blir permanent.

Öppna kopian som vanlig text i en redigerare där du kan välja teckenkodning. Prova först den teckenkodning som dagboksappen anger. Om den är okänd och filen är en typisk modern textexport är UTF-8 en rimlig kandidat att undersöka, men anta inte att den är rätt när du sparar över originalet. Jämför den berörda texten och den omgivande vanliga texten med varje alternativ. Ett sammanhängande resultat i hela filen är starkare belägg än en emoji som råkar se rätt ut.

Om den märkliga teckenföljden blir den förväntade emojin när du ändrar redigerarens kodningsvisning, och den omgivande texten också blir läsbar, kan exporten innehålla intakta byte som har tolkats fel. Bekräfta genom att stänga kopian utan att spara och öppna den igen med den lovande inställningen. Kontrollera sedan om dagboksappens import- eller öppningsflöde erbjuder ett dokumenterat val av teckenkodning. Använd det flödet vid eventuell återimport.

Unicode UTF FAQ förklarar att felaktigt formade UTF-8-bytesekvenser kan utlösa ett fel eller hanteras med en markör som U+FFFD. Det innebär att en avkodare redan kan ha ersatt ogiltiga indata när de visades eller importerades. Att byta teckenkodning efter det steget återställer inte nödvändigtvis originalbyten. Använd inte reparations- eller konverteringsalternativ som tyst ersätter tecken som inte kan avkodas i din enda kopia.

Om emojin visas korrekt i ett annat visningsprogram bör du spara den jämförelsen som belägg innan du ändrar filen. Skriv inte om exporten bara för att ändra hur den ser ut.

Om samma position innehåller U+FFFD eller ett bokstavligt frågetecken i flera visningsprogram bör du jämföra med källdagboken eller en tidigare export. En ersättning som sparats i filen kan inte återställas genom att byta teckensnitt. Det går bara att återställa tecknet om det finns kvar i en annan kopia.

Filändelsen .csv avslöjar inte vilken teckenkodning som använts, och kalkylbladsprogram kan tillämpa importinställningar. För skrivbordsversionen av Excel dokumenterar Microsoft import av text via Data > From Text/CSV och Text Import Wizard i sin guide till text- och CSV-import och -export. Granska förhandsvisningen innan du läser in filen: kontrollera emojin, rad- och kolumngränserna samt intilliggande text. En korrekt förhandsvisning visar att den valda importvägen läser filen som avsett; det är inte ett skäl att skriva över källfilen.

Bevara JSON-filen och använd en JSON-medveten importfunktion i stället för att behandla den som CSV. JSON-specifikationen RFC 8259 kräver UTF-8 för JSON som utbyts mellan system utanför ett slutet ekosystem. Den förklarar också att JSON-strängar kan representera tecken direkt eller med escape-sekvenser. Att se en escape-sekvens som \u263A innebär inte automatiskt att filen är skadad; en JSON-parser ska tolka giltiga escape-sekvenser. Om JSON-filen är ogiltig eller importfunktionen rapporterar ett tolkningsfel ska du avbryta och behålla den exakta filen i stället för att gissa dig fram när du redigerar skiljetecken eller byte.

Följ den här ordningen: (1) jämför källdagboken med exporten; (2) granska en dubblett med den förväntade teckenkodningen och en UTF-8-visning om det är lämpligt; (3) kontrollera ett annat visningsprogram för att se om glyfer saknas; (4) förhandsgranska filen med rätt CSV- eller JSON-importfunktion; och (5) försök exportera igen med en dokumenterad teckenkodning om emojin fortfarande visas korrekt i källan. Ändra en sak i taget och spara resultaten separat.

Om ingen visning eller importfunktion visar originaltecknet och filen bara innehåller ersättningstecken eller annan ersatt data ska du inte utlova att omkodning kan återställa det. Ändrade avkodningsinställningar kan inte avgöra vilken emoji som kastades bort. Leta efter en annan export, en säkerhetskopia eller den intakta dagboksanteckningen. Exportera sedan till en ny fil och kontrollera förhandsvisningen innan du förlitar dig på den.