El archivo está bien, se leyó mal
Lo que guarda un archivo de subtítulos son bytes. Convertir bytes en caracteres exige saber en qué codificación se escribieron: si te equivocas, salen caracteres ilegibles. No falta ni un byte del archivo; léelo otra vez con la codificación correcta y los caracteres vuelven.
Eso parte el trabajo en dos: averiguar con qué codificación empezó y guardarlo en una codificación que tu reproductor detecte. Lo primero sale de decodificar probando y puntuar, lo segundo de guardar una copia. Resuelven problemas distintos.
Cinco aspectos, cinco causas
Los caracteres ilegibles no salen al azar: su aspecto delata la causa:
- Bloques de letras acentuadas (`ä½ å¥½`): chino en UTF-8 leído como codificación de un byte — el chino ocupa tres bytes por carácter en UTF-8, y leer de un byte en un byte convierte cada byte en su propia letra
- Hileras de caracteres CJK sin uno solo común: UTF-8 leído como GBK — los bytes se reagrupan en parejas y cada pareja cae en algún carácter raro
- Un montón de símbolos de moneda y matemáticos: los bytes cayeron en la zona de símbolos, típico de leerse como Mac Roman o alguna variante de Latin-1
- Caracteres de control mezclados: los bytes cayeron en la zona de control invisible y en pantalla salen como huecos o cajas
- El signo de interrogación en una caja `�`: ese es el carácter de reemplazo, no texto ilegible — significa «aquí había un carácter y ya se perdió al leerlo»
Por qué el carácter de reemplazo no se puede reparar
El carácter de reemplazo es la línea divisoria. Un `�` significa que los bytes ya se tiraron en un paso anterior (normalmente algún programa que leyó el archivo y lo volvió a guardar), y no quedó registro de lo que se perdió. Entonces no hay nada de dónde deducir: nadie puede repararlo.
Por eso la página de reparación trata dos casos de forma distinta. Si subes un archivo, los bytes originales siguen intactos y puede probar cada codificación; si el texto pegado ya contiene el carácter de reemplazo, lo dice claro: «no se puede reparar, sube el archivo original».
Y está el caso inverso: el contenido se lee perfectamente, pero tu reproductor sigue mostrando basura. El archivo no tiene la culpa: el reproductor eligió mal la codificación. Editar el texto no sirve de nada; guarda una copia en UTF-8 con BOM o GBK y dale esa.
Qué se está comparando al reparar
La herramienta prueba todas las codificaciones plausibles y puntúa cada resultado: cuánto hay de caracteres comunes, si hay hileras de acentos, hileras de símbolos, si las hileras CJK son muros de caracteres raros. El resultado con mejor puntuación sube al principio de la lista.
Si ninguna puntuación es claramente mejor, no se recomienda nada: mejor decirte «esto se lee bien tal cual» que endosarte algo que solo se parece vagamente a un idioma. El texto estropeado dos veces (guardado mal una vez y reparado mal otra) recibe una vuelta extra de deducción inversa sobre los primeros candidatos.
Guardar la codificación correcta termina el trabajo
El texto reparado todavía hay que guardarlo en una codificación que tu reproductor reconozca. Los reproductores de Windows suelen fiarse del BOM para detectar la codificación, así que UTF-8 con BOM es lo que menos complica; el hardware antiguo y algunos reproductores regionales quieren GBK. Puedes elegir UTF-8, UTF-8 (con BOM), GBK, Big5, Shift_JIS o EUC-KR, y se te avisará si algo no cabe (GBK no admite coreano).
Herramientas y guías relacionadas
El recorrido completo, en Cómo reparar subtítulos con caracteres ilegibles; qué guarda realmente un archivo SRT, en Qué hay dentro de un archivo SRT; la codificación está bien pero el contenido está sucio (marcas de agua, anuncios, indicaciones para sordos), Limpieza de subtítulos.