Why a Text File Opens as Rows of Nonsense Characters

You open a .txt book and every accented letter has become a question mark. Or worse: the whole file is a wall of symbols with no recognisable words at all, in a language you can read perfectly well.

The file is not damaged. The characters are all there. They are being interpreted with the wrong key.

What is actually happening

A text file contains bytes, and nothing that says what those bytes mean. Whether 0xE9 is “é” or something else entirely depends on which encoding was used to write the file — and that choice is not recorded anywhere inside it.

So every program that opens a text file is guessing. When it guesses right, you get your book. When it guesses wrong, you get mojibake: a real word, encoded correctly, decoded with the wrong table.

Modern files use UTF-8, which covers every script and is the sane default. Older files use whatever was normal in that region at the time:

Encoding	Files you meet it in
Shift_JIS	Japanese plain text, including Aozora Bunko’s 18,000-plus works
GBK, GB18030	Simplified Chinese
Big5	Traditional Chinese
TIS-620, CP874	Thai
CP1251, KOI8-R	Russian and other Cyrillic
CP1254	Turkish
ISO-8859-1, CP1252	Western European, older Windows files

If your book came from an archive, a forum post from 2004, or a national digital library, there is a good chance it is not UTF-8.

What Aurora Reader does, and does not do

Worth stating plainly rather than leaving you to work out: the reader tries UTF-8 first, and falls back to Latin-1 if that fails. It does not detect Shift_JIS, GBK, Big5, TIS-620 or CP1251, and it has no encoding picker.

Latin-1 is the reason a wrongly-encoded file produces symbols instead of an error. Every possible byte is a valid Latin-1 character, so the fallback always succeeds — it just succeeds at producing the wrong text. Nothing fails, so nothing is reported.

That behaviour is tracked as a bug rather than defended. Until it changes, the fix is to convert the file.

Converting to UTF-8

This is done on a computer, in about a minute.

Windows. Open the file in Notepad++. The Encoding menu shows the current guess. Use Encoding → Character sets to pick the correct source encoding until the text reads properly, then Encoding → Convert to UTF-8, and save.

macOS or Linux. iconv does it in one line:

iconv -f SHIFT_JIS -t UTF-8 book.txt > book-utf8.txt

Replace SHIFT_JIS with the encoding your file actually uses.

Anywhere. Most decent text editors — VS Code, Sublime, Kate — can reopen a file with a chosen encoding and save it as UTF-8.

Work on a copy. If you guess the source encoding wrong and save, the damage becomes permanent.

Guessing the source encoding

You usually do not have to guess blind. The language narrows it to one or two candidates from the table above, and trying the top candidate is right most of the time.

The tell that you have it right is not that some characters look plausible; it is that all of them do. A partially-readable result means a near-miss encoding, and near-misses corrupt quietly — a handful of characters wrong in the middle of a book you will not notice until you quote one.

What this is not

Not a font problem. A missing font shows boxes or blank squares in an otherwise correct sentence. Wrong encoding produces the wrong letters, and no font change fixes it. If you are seeing boxes rather than nonsense, that is font coverage.

Not corruption. A corrupt file usually fails to open at all, or stops partway. If the whole book renders, consistently, in the wrong characters, the bytes are intact. How to tell if a file is actually corrupted covers the difference.

Not solvable by renaming. Changing the extension changes nothing about the bytes. This is the same misconception behind renaming .acsm files, which also does not work.

Avoiding it next time

If a source offers the same book as EPUB, take the EPUB. It declares its own encoding internally, so this class of problem does not arise. Where plain text is the only option — which for a great deal of public-domain literature it is — convert once on the computer, keep the UTF-8 copy, and read from that.