Vidéo et sous-titres · Boîte à outils de sous-titres
Pourquoi é devient é dans les sous-titres : les encodages de texte et comment les navigateurs les décodent
· Comment ça marche
sous-titres codage de caractères traitement du navigateur
Mojibake dans les sous-titres est presque toujours une incompatibilité d'encodage. Cet article explique comment les octets deviennent des caractères, pourquoi UTF-8 et les anciennes pages de codes Windows ne sont pas d'accord et comment un outil basé sur un navigateur décode un fichier sans l'envoyer nulle part.
Les accents sont nuls mais le timing est parfait – comment les problèmes d'encodage se présentent
Le problème est que tout va bien, sauf les personnages. Les timings sont exacts, l'ordre des repères est correct, le fichier se charge et seules les lettres accentuées sont fausses. Cette combinaison exclut une erreur structurelle, car un analyseur qui n'aurait pas pu lire le fichier n'aurait pas produit des timings corrects. Ce qui n'a pas fonctionné s'est produit avant l'analyse, lorsqu'une séquence d'octets a été transformée en une séquence de caractères.
Cela explique également pourquoi le défaut apparaît souvent à mi-chemin d'un flux de travail plutôt qu'à la source. Le fichier qui semblait correct dans un éditeur peut paraître faux dans le suivant, sans que rien ne l'ait modifié entre les deux. Rien ne l'a modifié ; le deuxième programme a fait une hypothèse différente sur la signification des octets.
Octets par rapport aux caractères — pourquoi les mêmes octets peuvent être lus comme « é » ou « é » selon le décodeur
Un fichier sur le disque contient des octets. Les caractères n'existent que lorsque quelque chose applique un codage, qui est une table mappant des séquences d'octets aux caractères. UTF-8 représente une lettre latine accentuée telle que e-acute sur deux octets. Windows-1252 représente la même lettre sous la forme d'un seul octet et donne aux deux UTF-8 des significations entièrement différentes : le premier est un A majuscule avec un tilde et le second est un signe de droit d'auteur.
Ainsi, la paire tronquée familière n'est pas de la corruption. Il s'agit d'une lecture fidèle et sans perte des octets corrects sous la mauvaise table. Chaque octet a survécu ; seule l'interprétation a changé. C'est pourquoi les dommages sont généralement réversibles et pourquoi il vaut la peine d'identifier la direction dans laquelle la discordance est allée plutôt que d'éditer manuellement les caractères visibles.
UTF-8, Windows-1252 et amis — les fichiers de sous-titres d'encodage apparaissent en fait dans
Les fichiers de sous-titres apparaissent dans un petit nombre d'encodages. UTF-8 est la valeur par défaut moderne et la seule autorisée par WebVTT. Windows-1252 est courant dans les fichiers produits par des outils plus anciens d'Europe occidentale, et son proche parent ISO-8859-1 couvre une grande partie du même domaine. Les fichiers provenant de sources d'Europe centrale, cyrilliques ou grecques apparaissent dans les pages de codes Windows correspondantes, et les documents d'Asie de l'Est en ajoutent plusieurs autres.
Aucun de ces encodages n'enregistre sa propre identité dans le fichier. Un fichier SRT ne contient aucune déclaration de l'encodage utilisé pour l'écrire, ce qui est la racine de tout le problème : le lecteur doit décider, et il n'y a rien d'autoritaire à lire.
La marque d'ordre des octets : un indice utile pour certains joueurs et un problème visible chez d'autres.
Une marque d'ordre d'octet est la seule exception partielle. C'est un caractère spécifique au tout début d'un fichier qui, lorsqu'il est présent, signale l'encodage. Il aide certains joueurs et apparaît chez d'autres comme un caractère errant avant le premier index de sous-titres, c'est pourquoi les fichiers qui en contiennent peuvent échouer dans exactement un programme et fonctionner partout ailleurs.
L'analyseur le supprime avant de faire autre chose, car une marque laissée en place s'attache au premier numéro d'index et coûte le premier repère. La détection du format est également écrite pour le tolérer, donc un fichier WebVTT qui commence par une marque avant son en-tête est toujours reconnu comme WebVTT plutôt que d'être traité comme SRT.
Comment un navigateur décode un fichier localement - l'API TextDecoder et pourquoi la détection est une supposition lorsqu'aucun encodage n'est déclaré
Lorsque l'outil charge un fichier, il appelle la méthode texte de l'API File, et cette méthode est spécifiée pour décoder comme UTF-8. Il n'y a aucun paramètre d'encodage ni aucune négociation. Un fichier qui est réellement UTF-8 est lu correctement ; un fichier Windows-1252 contenant une lettre accentuée sur un seul octet présente un octet qui ne peut pas commencer une séquence UTF-8 valide, et le décodeur substitue un caractère de remplacement plutôt que de deviner.
Cela vaut la peine de le savoir car cela modifie le symptôme. La lecture d'un fichier UTF-8 avec une table héritée produit le brouhaha familier à deux caractères. La lecture d'un fichier hérité en tant que UTF-8 produit à la place des caractères de remplacement, des losanges noirs ou des cases vides. Le décodage comme quelque chose d'autre que UTF-8 nécessite de nommer explicitement l'encodage via l'API du décodeur du navigateur, et le nommer est la partie la plus difficile : sans déclaration dans le fichier, tout choix automatique est une inférence à partir de modèles d'octets, ce qui est une supposition qui est généralement juste et parfois fausse en toute confiance.
Exemple pratique : récupération d'un fichier Windows-1252 — identification de l'encodage source et réenregistrement sous UTF-8 avant la conversion
Pour récupérer un ancien fichier, effectuez la conversion avant le travail des sous-titres plutôt qu'après. Ouvrez-le dans un éditeur qui vous permet d'indiquer l'encodage des deux côtés, dites-lui de rouvrir le fichier sous Windows-1252 et confirmez que les caractères accentués apparaissent correctement. S’ils le font, l’hypothèse était juste. Enregistrez ensuite le fichier explicitement sous UTF-8.
Vérifiez sur une ligne que vous pouvez prédire plutôt que sur le fichier dans son ensemble. Choisissez un signal contenant un accent dont vous savez qu'il devrait être présent et vérifiez-le dans la sortie convertie. Faire cela en premier signifie que l'outil de sous-titres reçoit un fichier dont les octets correspondent déjà à l'encodage qu'il va supposer, et l'étape de conversion n'a plus rien à se tromper.
Ce que cela ne couvre pas : fichiers endommagés par deux cycles de conversion erronée, où les octets d'origine sont déjà perdus
Un fichier qui a subi deux conversions incorrectes est un problème différent. Si un fichier était mal lu puis enregistré dans cet état mal lu, les caractères incorrects étaient écrits comme de vrais caractères et les octets d'origine n'existaient plus nulle part. À ce stade, il n’y a rien à réinterpréter, car le fichier contient désormais véritablement le texte tronqué.
Ces cas sont parfois récupérables en inversant la séquence exacte des codages erronés, mais uniquement lorsque chaque étape est connue et qu'aucune étape n'a perdu d'informations. Un octet qui est devenu un caractère de remplacement disparaît définitivement : le remplacement est un caractère unique remplaçant un octet que le décodeur n'a pas pu utiliser, et il n'enregistre pas ce qu'était l'octet. La solution fiable consiste à revenir au fichier d’origine.
À retenir : standardisez sur UTF-8 avant de convertir - comment la boîte à outils de sous-titres fonctionne sur votre fichier dans le navigateur et pourquoi la sortie WebVTT est UTF-8 par définition
Standardisez sur UTF-8 avant de convertir quoi que ce soit. Le fichier lui-même ne contient aucune déclaration sur son encodage, donc chaque programme qui l'ouvre fait une hypothèse, et la façon d'arrêter les hypothèses en désaccord est de les rendre toutes correctes. WebVTT supprime l'ambiguïté par définition, puisque le format nécessite UTF-8, ce qui est une raison pratique de convertir SRT en WebVTT pour la diffusion sur le Web.
La conversion s'exécute sur le fichier dans l'onglet du navigateur. Vérifiez le résultat sur une ligne dont vous pouvez prédire les accents plutôt que de rechercher tout ce qui semble faux, car un fichier contenant une poignée de mots accentués dans neuf cents indices est facile à signer sans avoir examiné la partie qui échouerait.