How to Diagnose Garbled Emoji in an Exported Diary File
If emoji look wrong in an exported diary, first determine whether the characters were decoded with the wrong encoding, replaced during export, or decoded correctly but cannot be displayed by the app or font. Work on a duplicate file, preserve the original bytes, and compare the same text in a plain-text editor and the diary importer. Changing an encoding setting can fix a decoding mismatch; it cannot restore information already replaced or removed.
Identify what “garbled” looks like
Look closely at one affected entry. A string of unexpected characters such as `😀` where 😀 belongs can indicate that UTF-8 bytes were interpreted using a different encoding. This is commonly called mojibake: the displayed characters are wrong because the bytes were decoded under the wrong assumptions. It is a clue, not proof of which encoding produced the file.
A visible `�` is different. That is U+FFFD, Unicode’s replacement character, used as a substitute for a character that cannot be interpreted. Unicode’s [glossary](https://www.unicode.org/glossary/#replacement_character) distinguishes it from a replacement glyph: a font or renderer may show a box when it cannot draw a character, while the underlying character may still be intact. If only some emoji appear as boxes, check another current app or font before changing the file’s encoding.
Preserve a baseline before troubleshooting
Make a copy of the export and keep the original unchanged. Record the filename extension, the app that exported it, and what you see for one affected phrase. If possible, compare a known emoji from the diary with the same entry in the source app or a prior export. Avoid repeatedly opening and saving the only copy: a text editor may write newly decoded text back as bytes, making a reversible display experiment permanent.
Open the copy as plain text in an editor that lets you choose an encoding. First try the encoding documented by the diary app; if it is unknown and the file is a typical modern text export, UTF-8 is a reasonable candidate to inspect, not an assumption to save over the original. Compare the affected text and surrounding ordinary characters under each candidate. A coherent result across the file is stronger evidence than an emoji that happens to look right.
Test decoding without rewriting
When changing the editor’s encoding view makes the strange sequence become the expected emoji and the surrounding text also becomes readable, the export may contain intact bytes that were interpreted incorrectly. Confirm by closing the copy without saving and reopening it with the promising setting. Then check whether the diary app’s import or open workflow offers a documented encoding choice; prefer that workflow for any actual re-import.
The [Unicode UTF FAQ](https://www.unicode.org/faq/utf_bom.html) explains that ill-formed UTF-8 byte sequences may trigger an error or be handled with a marker such as U+FFFD. That means a decoder may already have replaced invalid input when displaying or importing it. Switching the encoding after that step will not necessarily recover the original bytes. Do not use “repair” or conversion options that silently replace undecodable characters on your only copy.
Separate encoding problems from missing glyphs
If the emoji appears correctly in another viewer, keep that comparison as evidence before changing the file. Avoid rewriting the export simply to change its appearance.
If the same position contains U+FFFD or a literal question mark across viewers, compare against the source diary or an earlier export. A substitute stored in the file cannot be restored by changing the font. Recovery depends on another copy retaining the character.
Treat CSV and JSON as different import paths
A `.csv` extension does not tell you which character encoding was used, and spreadsheet programs may apply import settings. For Excel desktop, Microsoft documents importing text through **Data > From Text/CSV** and the Text Import Wizard in its [text and CSV import/export guide](https://support.microsoft.com/en-us/excel/get-started/import-or-export-text-txt-or-csv-files). Use the preview before loading: verify the emoji, row and column boundaries, and adjacent text. A correct preview is evidence the selected import path reads the file as intended; it is not a reason to overwrite the source.
For JSON, preserve the file and use a JSON-aware importer rather than treating it as CSV. The [RFC 8259 JSON specification](https://www.rfc-editor.org/rfc/rfc8259#section-8.1) requires UTF-8 for JSON exchanged between systems outside a closed ecosystem. It also explains that JSON strings can represent characters directly or with escapes. Seeing an escape such as `\u263A` is not automatically corruption; a JSON parser should interpret valid escapes. If the JSON is invalid or the importer reports a parse error, stop and retain the exact file rather than editing punctuation or bytes by guesswork.
Decide whether to retry, re-export, or stop
Use this sequence: (1) compare the source diary with the export; (2) inspect a duplicate using the expected encoding and a UTF-8 view if appropriate; (3) check another viewer for missing-glyph behavior; (4) preview the file through the correct CSV or JSON importer; and (5) retry export with a documented text encoding if the source still displays the emoji correctly. Change one variable at a time and keep each result separate.
If no view or importer reveals the original character, and the file contains only replacement characters or other substituted data, do not promise recovery by recoding. Changing decoding settings cannot infer which emoji was discarded. Look for another export, a backup, or the intact diary entry, then export again to a new file and verify its preview before relying on it.