Cómo corregir la codificación de subtítulos SRT sin perder el texto original

Si tus subtítulos SRT muestran café en lugar de café, no guardes inmediatamente el archivo como UTF-8. Primero conserva una copia intacta de sus bytes, identifica una descodificación que genere las palabras correctas y escribe el texto verificado en un archivo independiente. Guardar los caracteres incorrectos con una nueva codificación solo fijará el texto erróneo.

La distinción clave radica en una codificación válida frente a un texto correcto. En el experimento original de dos subtítulos que se detalla abajo, un archivo dañado supera una validación estricta de UTF-8 y no contiene caracteres de reemplazo. Aun así, su texto en francés sigue siendo incorrecto. Otro archivo supera la misma comprobación después de que seis caracteres originales hayan sido sustituidos por �.

Esta guía ofrece una herramienta local de inspección y conversión en Python, archivos de origen descargables y una prueba reproducible. Abarca el diagnóstico a nivel de archivo y la conversión explícita; no promete una detección automática de codificación, sincronización de vídeo ni la recuperación mágica de letras perdidas.

Primero identifica qué es lo que realmente falla

Una extensión .srt identifica un formato de subtítulos, no una codificación garantizada. El formato SRT contiene números de subtítulo, marcas de tiempo, texto y separadores; el registro del formato SRT de la Biblioteca del Congreso de EE. UU. lo describe como texto plano sin un estándar único de codificación de caracteres.

Utiliza el síntoma visible como motivo para investigar, no como un diagnóstico definitivo por sí solo:

Los caracteres y las formas con las que se muestran son cosas distintas. La explicación sobre Unicode de Python distingue entre puntos de código y glifos renderizados por fuentes. Que el texto se vea bien en un editor sugiere que el problema podría estar en el reproductor, pero no demuestra que instalar una fuente concreta vaya a solucionarlo. Para este artículo no se probó ningún reproductor ni fuente en particular.

Haz una copia de seguridad de los bytes y luego inspecciona la decodificación

Descarga subtitle_encoding.py y colócalo junto al SRT que quieras investigar. Estos comandos requieren una instalación existente de Python 3 y no necesitan paquetes adicionales. Las comprobaciones locales se realizaron con Python 3.14.3 en macOS. Si tu instalación de Windows utiliza el launcher de Python, sustituye py -3 por python3; ese entorno no fue probado en este artículo.

Abre una terminal en esa carpeta. En estos ejemplos, sustituye input.srt por el nombre real de tu archivo. Mantén las comillas alrededor de las rutas que contengan espacios.

Haz una copia intacta

python3 subtitle_encoding.py backup "input.srt" "original-bytes.srt"

El destino no debe existir previamente. La herramienta copia los bytes sin decodificarlos, vuelve a leer la copia y muestra su hash SHA-256. También rechaza la ruta de origen como destino. Conserva esta copia de seguridad incluso después de obtener un subtítulo utilizable.

Comprueba UTF-8 sin guardar nada

python3 subtitle_encoding.py inspect "original-bytes.srt"

El informe incluye strict_utf8, utf8_bom, la decodificación seleccionada y, si dicha decodificación tiene éxito, una vista previa del texto y replacement_characters . Su vista de texto predeterminada usa utf-8-sig, que gestiona una firma UTF-8 inicial.

• strict_utf8: false significa que los bytes no superan la comprobación de UTF-8. Esto no te indica qué otra codificación es la correcta.
• strict_utf8: true significa que pueden decodificarse como UTF-8. Esto no significa que las palabras sean correctas.
• Un recuento de reemplazos distinto de cero significa que la decodificación seleccionada produjo caracteres U+FFFD. Investígalos antes de crear un nuevo archivo.

La inspección imprime JSON seguro para ASCII para que la fuente de la terminal no pueda ocultar la identidad del carácter: \u00e9 significa é, y \ufffd representa el carácter de reemplazo. Para examinar en detalle una línea sospechosa, solicita su número de línea física, no su número de subtítulo:

python3 subtitle_encoding.py inspect "original-bytes.srt" --encoding cp1252 --line 3

Esta es una prueba de solo lectura de Windows-1252, el códec cp1252 de Python. Úsalo cuando los ajustes de exportación o el historial de origen respalden esa elección, no solo porque este ejemplo contenga francés. El informe de la línea nombra cada carácter y muestra su punto de código; U+20AC es el símbolo del euro.

Elige la codificación basándote en pruebas, no en la primera vista previa correcta

Pregunta a quien creó el archivo por la codificación de exportación real, revisa los ajustes de la aplicación que lo exportó o compáralo con una transcripción original de confianza. Revisa nombres con tildes, signos de puntuación, símbolos de moneda y líneas representativas a lo largo de todo el archivo. Si no sabes leer el idioma, un decodificador exitoso no podrá hacer esa revisión por ti.

«ANSI» no es lo bastante preciso como para seleccionar el códec de origen. Tampoco Windows-1252 y Latin-1 son intercambiables. En el experimento proporcionado, el byte único 80 se decodifica como € con cp1252, pero como el carácter de control U+0080 con latin-1. Ambas operaciones tienen éxito. Solo conociendo el origen se puede saber cuál es la correcta.

Otros idiomas pueden usar codificaciones heredadas diferentes, pero el nombre de un idioma por sí solo no determina una concreta. Si se desconoce el historial y las posibles lecturas discrepan, detén el proceso antes de la conversión y consigue información más precisa sobre el archivo original.

Convierte solo cuando el texto de origen sea legible

Para un archivo de origen confirmado como Windows-1252, crea un archivo UTF-8 independiente:

python3 subtitle_encoding.py convert "original-bytes.srt" "repaired-utf8.srt" --from-encoding cp1252
python3 subtitle_encoding.py inspect "repaired-utf8.srt"

El convertidor decodifica el origen completo de forma estricta, codifica ese texto en UTF-8, comprueba que la decodificación de la salida devuelva el mismo texto y vuelve a leer los bytes escritos. No modifica los números de subtítulo, las marcas de tiempo, los diálogos, las etiquetas ni los saltos de línea. La nueva secuencia de bytes puede diferir aunque el texto decodificado permanezca idéntico.

Rechaza deliberadamente:

• sobrescribir un archivo de destino existente;
• continuar tras un error de decodificación estricta; o
• escribir texto que contenga U+FFFD, incluso si ese carácter era intencionado.

Esta última restricción es conservadora: la herramienta no puede decidir qué se suponía que representaba un carácter de reemplazo. Eliminarlo para forzar la ejecución del comando descartaría pruebas en lugar de restaurar el texto. La documentación sobre controladores de errores de Python explica por qué replace y ignore difieren de la decodificación estricta: sustituyen o descartan los datos problemáticos. Ninguno de los dos tiene cabida en este paso de conversión.

Si se produce un error de E/S, no utilices la salida generada. Podría quedar un archivo nuevo incompleto; conserva el original y utiliza un nombre de destino diferente para intentarlo de nuevo más adelante. Todos los detalles sobre el funcionamiento y el uso de la herramienta se encuentran en el README descargable.

¿Qué ocurre con UTF-8 con BOM?

Un BOM en UTF-8 es la secuencia de bytes inicial EF BB BF. El utf-8-sig códec de Python consume esa firma al decodificar y la añade al codificar.

Para un archivo de origen confirmado en UTF-8 con BOM, utiliza --from-encoding utf-8-sig. La herramienta suele escribir UTF-8 sin BOM; añade --with-bom únicamente cuando los requisitos de la aplicación receptora lo exijan. Modificar un BOM no puede convertir café en café. Este experimento no determina la compatibilidad con ningún reproductor, editor o plataforma de subida en particular.

Cinco pequeños archivos demuestran por qué la validez de UTF-8 no es suficiente

El experimento utiliza dos subtítulos en francés redactados desde cero. No proceden de ninguna película, cliente ni producto de traducción:

1
00:00:01,000 --> 00:00:04,000
Émile dit : « Le prix est de 12,50 €. »

2
00:00:05,000 --> 00:00:08,000
Le café est fermé.

El 13 de septiembre de 2026, un script basado en la biblioteca estándar de Python 3.14.3 generó cinco representaciones en bytes y las comparó con dicho origen conocido. Se trata de comprobaciones deterministas de bytes y cadenas de texto, no de una prueba de rendimiento sobre la calidad de traducción. Guarda en el disco los archivos enlazados en lugar de copiar la vista previa del navegador: la diferencia entre los bytes es el objetivo principal del experimento.

Cada copia conserva las mismas dos cadenas de marcas de tiempo. El archivo convertido correctamente es idéntico byte por byte al original en UTF-8. Los dos archivos UTF-8 dañados demuestran algo más acotado pero útil: ni una codificación válida ni unas marcas de tiempo intactas garantizan un texto de subtítulos correcto. Que las marcas de tiempo coincidan tampoco indica en absoluto si esta pista inventada encaja con un vídeo real.

Para reproducir los cinco archivos por su cuenta, descargue reproduce.py y ejecútelo indicando un nombre de directorio que no exista:

python3 reproduce.py encoding-experiment

El script genera los archivos de prueba y un results.json que contiene el texto completo, las transformaciones, los hashes, la versión del entorno de ejecución y las aserciones. Compárelo con los resultados registrados del experimento; la marca de tiempo de generación diferirá. Los scripts y los archivos didácticos originales incluyen una licencia MIT.

Las comprobaciones del conversor local también pusieron a prueba el rechazo de archivos de salida ya existentes, el rechazo de rutas de origen, los errores por códec incorrecto, el rechazo de U+FFFD, la preservación de CRLF y la salida explícita con BOM. Estas comprobaciones verifican el comportamiento de la herramienta con los archivos. No evalúan la renderización en reproductores, la sincronización con contenido multimedia real ni la traducción de BookTranslator.

Qué hacer si los caracteres dañados ya se han guardado

Mojibake guardado: investigue el historial exacto

Nuestra copia con mojibake siguió una cadena conocida: los bytes originales en UTF-8 se decodificaron como Windows-1252 y, a continuación, esos caracteres incorrectos se guardaron como UTF-8. El resultado incluye café y la secuencia dañada del euro €.

Dado que esta transformación en particular no perdió ningún byte, el script de reproducción puede revertirla: volver a codificar el texto erróneo mediante cp1252y, después, decodificar los bytes resultantes como UTF-8. El script compara el texto recuperado con el original para verificarlo.

Esto demuestra la validez para esta cadena conocida, pero no constituye una instrucción para aplicar una operación global de «reparar mojibake» a cualquier archivo SRT. Un archivo puede contener caracteres legítimos, historiales mixtos o texto ya alterado por un intento de reparación previo. Siempre es preferible utilizar la fuente intacta y la ruta de conversión estándar. Si solo conserva la versión con mojibake guardada, manténgala intacta y determine con certeza cómo se generó antes de intentar aplicar una transformación inversa sobre otra copia.

Caracteres de reemplazo guardados: la letra que falta no está codificada ahí

El archivo de prueba con pérdida se creó decodificando bytes de Windows-1252 como UTF-8 con el reemplazo habilitado y guardando luego el resultado. Caracteres originales distintos se convirtieron en el mismo marcador � . El marcador guardado no contiene suficiente información para identificar qué carácter original ocupaba esa posición.

No confunda esto con el simple hecho de verlo � en una aplicación. Si los bytes originales permanecen intactos, una decodificación correcta aún puede recuperar el texto, como ocurre con nuestra fuente Windows-1252. Inspeccione esa fuente antes de dar por hecho la pérdida.

Si la única copia que queda ha sustituido de forma definitiva el texto faltante por U+FFFD o por signos de interrogación literales, vuelva a exportar u obtener una fuente limpia, o coteje una transcripción manual con material fiable. Un signo de interrogación ordinario también puede ser puntuación legítima; su sola presencia no demuestra nada. La sustitución plausible que proponga un modelo es una conjetura, no datos recuperados del archivo.

Termine con una fuente legible, no solo con un comando ejecutado con éxito

Antes de dar por bueno el archivo reparado, compare palabras y símbolos representativos con la fuente fiable, confirme que las líneas de subtítulos y marcas de tiempo no hayan cambiado y abra el archivo nuevo en la aplicación que lo va a utilizar. El script conserva el texto decodificado; no es un validador de sintaxis SRT ni una prueba de aceptación para la reproducción.

Si ahora puede leer los subtítulos y no necesita ningún otro idioma, la tarea ha terminado. Si necesita una revisión visual sobre el vídeo o una edición más a fondo, la comparativa de programas para subtítulos explica el papel que desempeña cada herramienta.

Solo cuando el texto de origen sea fiable —y realmente necesite otro idioma— pase al traductor de subtítulos de BookTranslator y al flujo de trabajo de traducción de subtítulos con IA. Trate la reparación de la codificación, la traducción y la previsualización de la pista final como tareas independientes. Ninguna de ellas garantiza por sí sola que las demás hayan salido bien.