Manatee

Subtitles that show strange characters on a Mac

· 6 min read

The subtitle file loads, the timing is perfect, and every accented letter has turned into something like é or ü or a black diamond with a question mark. The words are not damaged. The file is being read with the wrong character encoding, and rewriting it as UTF-8 fixes every occurrence at once.

This takes one Terminal command to diagnose and one to fix, and the same explanation covers CSV exports and plain text files that arrive looking the same way.

What you are actually looking at

Text files store numbers, and an encoding is the agreement about which number means which letter. Trouble starts because the file does not reliably say which agreement it used.

Two distinct symptoms, with two different meanings:

  • é, è, ’,  and similar pairs. The file is UTF-8 and something is reading it as a single-byte encoding such as Windows-1252. UTF-8 stores é as two bytes, and each byte is being shown as its own character. This is the common case and it is fully reversible.
  • Black diamonds with question marks, or empty boxes. The opposite: a single-byte file being read as UTF-8, producing byte sequences that are not valid UTF-8 at all. Also usually reversible, as long as you can work out which single-byte encoding was intended.

Subtitle files are especially prone to this because they travel widely, get edited on every kind of machine, and carry no encoding declaration in the SRT format at all. A .srt file is just timings and lines of text, with no header to say what the bytes mean.

Check the encoding in Terminal

Open Terminal, type file -I with a trailing space, drag the subtitle file into the window, and press Return:

file -I movie.srt

You will get something like:

movie.srt: text/plain; charset=utf-8

or charset=iso-8859-1, or charset=unknown-8bit. That last one means the file contains bytes that are not valid UTF-8, which confirms a single-byte encoding and points at the second symptom above.

To see the damage in context without opening an editor:

head -40 movie.srt

Terminal itself expects UTF-8, so a file that looks correct here and wrong in your player is a player problem, and a file that looks wrong in both is a file problem. That single comparison tells you which half of this article you need.

Rewrite the file as UTF-8

iconv is built into macOS and converts between encodings. Work to a new filename so the original stays available if you guess the source encoding wrong:

iconv -f WINDOWS-1252 -t UTF-8 movie.srt > movie-utf8.srt

For subtitles from central or eastern Europe, try WINDOWS-1250. For Cyrillic, WINDOWS-1251. For Greek, WINDOWS-1253. For Turkish, WINDOWS-1254. Western European languages, including French, Spanish, German, Portuguese and the Nordic languages, are almost always WINDOWS-1252 or its close relative ISO-8859-1.

If the command reports an illegal input sequence, the source encoding guess was wrong. Try the next candidate. You cannot damage anything, because you are writing to a new file each time.

Check the result before trusting it:

head -40 movie-utf8.srt

Accented characters should now read correctly in Terminal. If they do, the file is fixed for every player and every machine, since UTF-8 is what everything modern expects.

For the reverse case, where a UTF-8 file is being misread and you need to satisfy old software that insists on a single-byte encoding:

iconv -f UTF-8 -t WINDOWS-1252//TRANSLIT movie.srt > movie-1252.srt

//TRANSLIT substitutes the nearest available character rather than failing when something has no equivalent, which is the honest tradeoff: a curly quote may become a straight one, and a character with no counterpart at all is lost.

When the player is at fault, not the file

If file -I says utf-8 and Terminal displays the text correctly, the file is fine and something downstream is misreading it.

Check these in order:

  1. The subtitle track selection. Some players fall back to an internal track rather than your external file. Select the external one explicitly.
  2. A forced encoding setting. Many players have a subtitle encoding preference, sometimes defaulting to a regional value rather than UTF-8. Set it to UTF-8 or automatic.
  3. A byte order mark. A UTF-8 file that starts with a BOM can confuse older parsers, which sometimes show three stray characters at the very start of the first line. LC_ALL=C sed '1s/^\xEF\xBB\xBF//' movie.srt > clean.srt removes it.
  4. The filename. A subtitle file has to match the video’s name to be picked up automatically by most players. A mismatch can mean you are watching a completely different subtitle file than the one you just fixed.

Converting the file while you are in there

Encoding trouble often arrives alongside a format that the player does not want anyway. If you have an ASS or SSA file full of styling, a WebVTT file from a browser download, or an SBV export, converting to plain SRT removes a whole class of problems at once, because SRT is the format nearly everything accepts.

Manatee converts subtitles to SRT among its conversion targets, on the Mac, writing a new file alongside the original rather than changing it. The step by step versions are converting VTT subtitles to SRT and converting ASS or SSA subtitles to SRT. Run the encoding fix first, then convert, so the accented characters are already correct going in.

The same problem in other files

Nothing about this is specific to subtitles. A CSV export that opens with á scattered through the names, a .txt file from an old machine, a log file from a Windows server: all the same mismatch, all fixed by the same iconv command.

Word documents look similar but are not the same thing at all. A DOCX showing strange symbols is usually structural damage rather than an encoding mismatch, which is covered in a Word document that opens full of strange symbols.

Questions

Can I fix this without Terminal? Yes, if you have a text editor that lets you choose an encoding when opening and when saving. Open the file as Windows-1252, confirm the accents look right, and save as UTF-8. TextEdit can do this through the Plain Text encoding options in its Open and Save dialogs.

Will fixing the encoding break the timings? No. Timings are plain digits, colons and commas, which are identical in every encoding involved. Only the letters change.

Why do some subtitles work and others do not, from the same download? Because they were made by different people on different machines, and SRT carries no encoding declaration. It is normal for one file in a set to be UTF-8 and the next to be Windows-1252.

Is UTF-8 always the right target? For anything current, yes. Every modern player, browser and operating system reads UTF-8. Only genuinely old software needs a single-byte encoding, and that choice costs you any character outside the one region it covers.