Vídeo y subtítulos · Kit de herramientas de subtítulos
Por qué é se convierte en é en los subtítulos: codificaciones de texto y cómo los decodifican los navegadores
· Cómo funciona
subtítulos codificación de caracteres procesamiento del navegador
Mojibake en los subtítulos casi siempre tiene una codificación que no coincide. Esta publicación explica cómo los bytes se convierten en caracteres, por qué UTF-8 y las páginas de códigos heredadas de Windows no están de acuerdo y cómo una herramienta basada en navegador decodifica un archivo sin enviarlo a ninguna parte.
Los acentos son basura pero el momento es perfecto: cómo se presentan los problemas de codificación
La señal es que todo, excepto los personajes, está bien. Los tiempos son exactos, el orden de las señales es correcto, el archivo se carga y sólo las letras acentuadas son incorrectas. Esa combinación descarta una falla estructural, porque un analizador que no pudiera leer el archivo no habría producido los tiempos correctos. Lo que salió mal ocurrió antes del análisis, cuando una secuencia de bytes se convirtió en una secuencia de caracteres.
Esto también explica por qué el error suele aparecer en la mitad del flujo de trabajo y no en el origen. El archivo que parecía correcto en un editor puede verse mal en el siguiente, sin nada de por medio haberlo modificado. Nada lo modificó; el segundo programa hizo una suposición diferente sobre lo que significaban los bytes.
Bytes frente a caracteres: por qué los mismos bytes se pueden leer como 'é' o 'é' según el decodificador
Un archivo en el disco es bytes. Los caracteres solo existen una vez que algo aplica una codificación, que es una tabla que asigna secuencias de bytes a caracteres. UTF-8 representa una letra latina acentuada como e-acute en dos bytes. Windows-1252 representa la misma letra que un solo byte y les da a los dos UTF-8 significados completamente diferentes: el primero es una A mayúscula con tilde y el segundo es un signo de copyright.
Entonces, el familiar par confuso no es corrupción. Es una lectura fiel y sin pérdidas de los bytes correctos bajo la tabla incorrecta. Cada byte sobrevivió; sólo cambió la interpretación. Es por eso que el daño suele ser reversible y por eso vale la pena identificar en qué dirección se produjo la falta de coincidencia en lugar de editar manualmente los caracteres visibles.
UTF-8, Windows-1252 y amigos: los archivos de subtítulos codificados en realidad aparecen en
Los archivos de subtítulos aparecen en una pequeña cantidad de codificaciones. UTF-8 es el valor predeterminado moderno y el único que permite WebVTT. Windows-1252 es común en archivos producidos por herramientas más antiguas de Europa occidental, y su pariente cercano ISO-8859-1 cubre gran parte del mismo terreno. Los archivos de fuentes de Europa Central, cirílico o griego aparecen en las correspondientes páginas de códigos de Windows, y el material de Asia Oriental añade varios más.
Ninguna de estas codificaciones registra su propia identidad dentro del archivo. Un archivo SRT no contiene ninguna declaración de la codificación utilizada para escribirlo, lo cual es la raíz de todo el problema: el lector tiene que decidir y no hay nada autorizado para leer.
La marca de orden de bytes: una sugerencia útil para algunos jugadores y un error visible en otros
Una marca de orden de bytes es la única excepción parcial. Es un carácter específico al comienzo de un archivo que, cuando está presente, indica la codificación. Ayuda a algunos reproductores y aparece en otros como un personaje perdido antes del primer índice de subtítulos, razón por la cual los archivos que contienen uno pueden fallar exactamente en un programa y funcionar en todos los demás.
El analizador lo elimina antes de hacer cualquier otra cosa, porque una marca que se deja en su lugar se adhiere al primer número de índice y cuesta la primera señal. La detección de formato también está escrita para tolerarlo, por lo que un archivo WebVTT que comienza con una marca antes de su encabezado aún se reconoce como WebVTT en lugar de tratarse como SRT.
Cómo un navegador decodifica un archivo localmente: la API TextDecoder y por qué la detección es una suposición cuando no se declara ninguna codificación
Cuando la herramienta carga un archivo, llama al método de texto File API y ese método se especifica para decodificar como UTF-8. No hay ningún parámetro de codificación ni negociación. Un archivo que realmente es UTF-8 se lee correctamente; un archivo Windows-1252 que contiene una letra acentuada de un solo byte presenta un byte que no puede comenzar una secuencia UTF-8 válida y el decodificador lo sustituye por un carácter de reemplazo en lugar de adivinar.
Vale la pena saber esto porque cambia el síntoma. La lectura de un archivo UTF-8 con una tabla heredada produce la familiar confusión de dos caracteres. Leer un archivo heredado como UTF-8 produce caracteres de reemplazo, diamantes negros o cuadros vacíos. La decodificación como algo distinto a UTF-8 requiere nombrar la codificación explícitamente a través de la API del descodificador del navegador, y nombrarla es la parte difícil: sin ninguna declaración en el archivo, cualquier elección automática es una inferencia a partir de patrones de bytes, lo cual es una suposición que generalmente es correcta y ocasionalmente incorrecta.
Ejemplo resuelto: rescatar un archivo Windows-1252: identificar la codificación de origen y volver a guardarla como UTF-8 antes de la conversión
Para rescatar un archivo heredado, realice la conversión antes de los subtítulos en lugar de después. Ábralo en un editor que le permita indicar la codificación en ambos lados, dígale que vuelva a abrir el archivo como Windows-1252 y confirme que los caracteres acentuados aparecen correctamente. Si lo hacen, la suposición era correcta. Luego guarde el archivo explícitamente como UTF-8.
Verifique en una línea que pueda predecir en lugar de en el archivo en su conjunto. Elige una señal que contenga un acento que sabes que debería estar ahí y compruébalo en la salida convertida. Hacer esto primero significa que la herramienta de subtítulos recibe un archivo cuyos bytes ya coinciden con la codificación que va a asumir, y el paso de conversión no tiene nada que hacer mal.
Lo que esto no cubre: archivos dañados por dos rondas de conversión incorrecta, donde los bytes originales ya se han perdido
Un archivo que ha pasado por dos conversiones incorrectas es un problema diferente. Si un archivo se leyó mal y luego se guardó en ese estado de lectura incorrecta, los caracteres incorrectos se escribieron como caracteres reales y los bytes originales ya no existen en ninguna parte del mismo. En ese momento no hay nada que reinterpretar, porque el archivo ahora realmente contiene texto confuso.
Esos casos a veces se pueden recuperar invirtiendo la secuencia exacta de codificaciones erróneas, pero solo cuando se conoce cada paso y no se pierde información de ningún paso. Un byte que se convirtió en un carácter de reemplazo desaparece permanentemente: el reemplazo es un carácter único que reemplaza un byte que el decodificador no pudo usar y no registra cuál era el byte. La solución fiable es volver al archivo original.
Conclusión: estandarice en UTF-8 antes de convertir: cómo funciona Subtitle Toolkit en su archivo en el navegador y por qué la salida WebVTT es UTF-8 por definición
Estandarice el UTF-8 antes de convertir cualquier cosa. El archivo en sí no contiene ninguna declaración sobre su codificación, por lo que cada programa que lo abre hace una suposición, y la forma de evitar que las suposiciones no estén de acuerdo es hacer que todas sean correctas. WebVTT elimina la ambigüedad por definición, ya que el formato requiere UTF-8, lo cual es una razón práctica para convertir SRT a WebVTT para entrega web.
La conversión se ejecuta en el archivo en la pestaña del navegador. Verifique el resultado en una línea cuyos acentos pueda predecir en lugar de buscar cualquier cosa que parezca incorrecta, porque es fácil cerrar sesión en un archivo con un puñado de palabras acentuadas en novecientas pistas sin haber examinado la parte que fallaría.