Subtitle character encoding
Character encoding specifies how subtitle bytes become characters, and incorrect decoding can produce mojibake before font rendering begins.
Character encoding defines the relationship between stored bytes and text characters. An incorrectly decoded subtitle can show é where é was intended even when its timestamps and basic punctuation remain readable.
That is a text-decoding problem. Font selection happens later and cannot reinterpret the original bytes once the decoder has produced the wrong characters.
The same word can use different bytes
For the composed spelling café:
| Encoding | Bytes in hexadecimal |
|---|---|
| UTF-8 | 63 61 66 C3 A9 |
| Windows-1252 | 63 61 66 E9 |
In UTF-8, C3 A9 together encode U+00E9. In Windows-1252, E9 represents that character directly.
If the UTF-8 bytes are decoded as Windows-1252, C3 and A9 become two different characters, producing the familiar café. If the single E9 byte is decoded as though it begins a complete UTF-8 character, that incomplete/invalid sequence needs an error policy.
ASCII digits and timing separators have the same familiar byte values in these two encodings. The timing header can therefore look correct while the dialogue is wrong.
A label or signature supplies evidence
Some formats prescribe an encoding: WebVTT is UTF-8. XML can describe its encoding under XML's rules. Existing SRT collections can contain legacy encodings, so the extension alone is insufficient evidence.
A byte-order mark can identify a Unicode encoding signature:
| Leading bytes | Common signature |
|---|---|
| EF BB BF | UTF-8 BOM |
| FF FE | UTF-16 little-endian BOM |
| FE FF | UTF-16 big-endian BOM |
A UTF-8 BOM is not required for all UTF-8 text. Absence of a BOM does not make a file a legacy code page. The format's rules and any valid metadata determine which interpretation should be used.
A signature is also not visible caption content. Leaving U+FEFF where the applicable parser treats it as a signature and displaying it as a letter are different actions.
Replacement can lose information
A decoder can reject invalid data or insert a replacement character, U+FFFD. If the resulting replacement text is saved over the source, the original byte sequence may no longer be available to reconstruct the intended wording.
The replacement character is not a font's missing-glyph box. One comes from the text decoding/error policy; the other comes from a renderer unable to draw a character that is already known.
For an Emby subtitle investigation, inspect the resource actually delivered and the interpretation used at the decoding stage. A file on disk can be correct while a conversion reads it with another encoding; a client cannot recover the original byte meaning from already corrupted text alone.
Conversion preserves characters through a new encoding
A correct Windows-1252-to-UTF-8 conversion first decodes E9 as U+00E9, then encodes U+00E9 as C3 A9. It changes the stored bytes while preserving the character.
Saving an already misdecoded é string as UTF-8 encodes those wrong characters faithfully. It is not the same operation.
The encoding conversion should therefore begin with a verified source interpretation. The resulting character sequence, not a successful “save as UTF-8” message, establishes whether the wording survived.