Corriger l'encodage des sous-titres SRT sans perdre le texte d'origine

Si vos sous-titres SRT affichent café au lieu de café, ne réenregistrez pas immédiatement le fichier en UTF-8. Conservez d'abord une copie intacte de ses octets, identifiez un décodage qui restitue les mots corrects, puis écrivez le texte vérifié dans un fichier distinct. Réenregistrer des caractères erronés dans un nouvel encodage ne fait que figer l'erreur.

La distinction fondamentale réside dans la différence entre un encodage valide et un texte correct. Dans l'expérience originale à deux répliques ci-dessous, un fichier corrompu passe avec succès une vérification stricte en UTF-8 et ne contient aucun caractère de remplacement. Pourtant, son texte en français reste faux. Un autre réussit le même test alors que six caractères d'origine ont été remplacés par �.

Ce guide propose un outil Python local d'inspection et de conversion, des fichiers sources téléchargeables ainsi qu'un test reproductible. Il prend en charge le diagnostic à l'échelle du fichier et la conversion explicite — sans détection automatique d'encodage, synchronisation vidéo ni promesse de restaurer des lettres définitivement perdues.

Identifiez d'abord ce qui est réellement corrompu

Une extension .srt identifie un format de sous-titres, et non un encodage garanti. Le format SRT contient des numéros de répliques, des horodatages, du texte et des séparateurs ; la notice descriptive du format SRT de la Bibliothèque du Congrès le qualifie de texte brut sans standard unique d'encodage de caractères.

Considérez le symptôme visible comme une incitation à investiguer, et non comme un diagnostic en soi :

Les caractères et les formes affichées à l'écran sont deux choses distinctes. La documentation Python sur Unicode fait bien la distinction entre les points de code et les glyphes restitués par une police. Un texte correct dans un éditeur rend plausible un problème côté lecteur ; cela ne prouve pas pour autant que l'installation d'une police spécifique le résoudra. Aucune police ni aucun lecteur n'ont été testés dans le cadre de cet article.

Sauvegarder les octets, puis inspecter un décodage

Téléchargez subtitle_encoding.py et placez-le aux côtés du fichier SRT que vous souhaitez examiner. Ces commandes nécessitent une installation existante de Python 3, sans aucun paquet supplémentaire. Les vérifications locales effectuées ici ont utilisé Python 3.14.3 sur macOS. Si votre installation sous Windows utilise le lanceur Python, remplacez py -3 par python3; cet environnement n'a pas été testé ici.

Ouvrez un terminal dans ce dossier. Dans ces exemples, remplacez input.srt par le nom réel de votre fichier. Conservez les guillemets autour des chemins contenant des espaces.

Faire une copie intacte

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

Le fichier de destination ne doit pas déjà exister. L'outil copie les octets sans les décoder, relit la copie et affiche son empreinte SHA-256. Il refuse également d'utiliser le chemin source comme destination. Conservez cette sauvegarde même après avoir généré un sous-titre utilisable.

Vérifier l'UTF-8 sans rien enregistrer

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

Le rapport indique strict_utf8, utf8_bom, le décodage sélectionné et, si le décodage réussit, un aperçu du texte ainsi que replacement_characters . Sa vue textuelle par défaut utilise utf-8-sig, qui gère une signature UTF-8 initiale.

• strict_utf8: false signifie que les octets échouent au contrôle UTF-8. Cela n'indique pas quel autre encodage est le bon.
• strict_utf8: true signifie qu'ils peuvent être décodés en UTF-8. Cela ne signifie pas que les mots sont corrects.
• Un nombre de remplacements non nul signifie que le décodage sélectionné a produit des caractères U+FFFD. Examinez-les avant de créer un nouveau fichier.

L'inspection affiche du JSON compatible ASCII afin que la police du terminal ne masque pas l'identité des caractères : \u00e9 correspond à é, et \ufffd représente le caractère de remplacement. Pour examiner une ligne suspecte en détail, indiquez son numéro de ligne physique, et non son numéro de sous-titre :

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

Il s'agit d'un test en lecture seule de Windows-1252, le codec cp1252 de Python. Utilisez-le lorsque les paramètres d'exportation ou l'historique du fichier source justifient ce choix, et non pas simplement parce que cet exemple utilise par hasard du français. Le rapport de ligne nomme chaque caractère et affiche son point de code ; U+20AC est le symbole de l'euro.

Choisissez l'encodage d'après des faits, pas selon le premier aperçu qui s'affiche

Demandez au créateur du fichier l'encodage réel utilisé lors de l'exportation, vérifiez les paramètres du logiciel d'exportation ou comparez avec une transcription d'origine fiable. Vérifiez les noms accentués, la ponctuation, les symboles monétaires et un échantillon représentatif de répliques dans tout le fichier. Si vous ne lisez pas la langue, aucun décodeur ne pourra effectuer cette vérification à votre place, même s'il ne signale aucune erreur.

Le terme « ANSI » n'est pas assez précis pour choisir le bon codec source. De même, Windows-1252 et Latin-1 ne sont pas interchangeables. Dans l'expérience présentée, l'octet unique 80 donne € sous cp1252, mais correspond au caractère de contrôle U+0080 sous latin-1. Les deux opérations réussissent. Seule la source connue permet de savoir laquelle est voulue.

D'autres langues peuvent utiliser des encodages hérités différents, mais le nom d'une langue ne suffit pas à en déterminer un. Si l'historique est inconnu et que les lectures envisagées se contredisent, arrêtez-vous avant la conversion et obtenez de meilleures preuves sur la source.

Ne convertissez qu'une fois le texte source lisible

Pour une source confirmée en Windows-1252, créez un fichier UTF-8 distinct :

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

Le convertisseur décode la source complète de manière stricte, encode ce texte en UTF-8, vérifie que le décodage de la sortie renvoie le même texte et relit les octets écrits. Il ne modifie ni les numéros de sous-titre, ni les horodatages, ni les dialogues, ni les balises, ni les sauts de ligne. La nouvelle séquence d'octets peut différer même si le texte décodé reste identique.

Il refuse délibérément de :

• écraser une destination existante ;
• continuer après une erreur de décodage strict ; ou
• écrire un texte contenant U+FFFD, même si ce caractère était intentionnel.

Cette dernière restriction est prudente : cet outil ne peut pas deviner ce qu'un caractère de remplacement était censé représenter. Le supprimer pour que la commande aboutisse reviendrait à effacer des preuves, non à restaurer le texte. La documentation de Python sur les gestionnaires d'erreurs explique pourquoi replace et ignore diffèrent d'un décodage strict : ils remplacent ou éliminent les données problématiques. Aucun des deux n'a sa place dans cette étape de conversion.

En cas d'erreur d'E/S, n'utilisez pas le fichier généré. Un nouveau fichier partiel peut subsister ; conservez l'original et choisissez un nom de destination inédit pour une tentative ultérieure. Le comportement complet de l'outil et ses instructions d'utilisation figurent dans le README téléchargeable.

Qu'en est-il de l'UTF-8 avec BOM ?

Un BOM UTF-8 est la séquence d'octets initiale EF BB BF. Le codec utf-8-sig de Python absorbe cette signature lors du décodage et l'ajoute lors de l'encodage.

Pour une source UTF-8 confirmée comportant un BOM, utilisez --from-encoding utf-8-sig. L’outil écrit normalement de l’UTF-8 sans BOM ; n'ajoutez --with-bom que si les spécifications de l’application de destination l’exigent. Modifier un BOM ne peut pas transformer café en café. Cette expérience n’établit aucune compatibilité avec un lecteur, un éditeur ou une plateforme de mise en ligne en particulier.

Cinq petits fichiers illustrent pourquoi la validité UTF-8 ne suffit pas

L'expérience utilise deux répliques de sous-titres en français entièrement rédigées par nos soins. Elles ne proviennent ni d'un film, ni d'un client, ni d'un outil de traduction :

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é.

Le 13 septembre 2026, un script Python 3.14.3 s'appuyant sur la bibliothèque standard a généré cinq représentations d'octets et a comparé chacune d'elles à cette source connue. Il s'agit de vérifications déterministes d'octets et de chaînes de caractères, et non d'un banc d'essai de qualité de traduction. Enregistrez les fichiers liés sur votre disque plutôt que de copier leur aperçu dans le navigateur : ces octets distincts constituent tout l'enjeu de l'expérience.

Chaque copie conserve exactement les deux mêmes chaînes d'horodatage. Le fichier correctement converti est identique au fichier UTF-8 d'origine, à l'octet près. Les deux fichiers UTF-8 corrompus démontrent une nuance plus précise mais précieuse : ni un encodage valide ni des horodatages inchangés ne garantissent l'exactitude du texte des sous-titres. Des horodatages identiques n'indiquent pas non plus si cette piste fictive est synchronisée avec une véritable vidéo.

Pour reproduire vous-même les cinq fichiers, téléchargez reproduce.py et exécutez-le en spécifiant un nom de dossier qui n'existe pas encore :

python3 reproduce.py encoding-experiment

Le script génère les fichiers de test ainsi qu'un fichier results.json contenant le texte intégral, les transformations, les hachages, la version d'exécution et les assertions. Comparez-le avec les résultats de l'expérience enregistrée; seul l'horodatage de génération sera différent. Les scripts et les fichiers pédagogiques d'origine sont sous licence MIT.

Les vérifications du convertisseur local ont également porté sur le refus d'écraser un fichier de sortie existant, le rejet du chemin source, l'échec en cas de codec incorrect, le refus du caractère U+FFFD, la préservation des fins de ligne CRLF et la génération explicite d'un BOM. Ces tests valident le comportement de l'outil vis-à-vis des fichiers. Ils n'évaluent pas le rendu dans un lecteur multimédia, la synchronisation vidéo réelle ou la traduction dans BookTranslator.

Si les caractères corrompus ont déjà été enregistrés

Mojibake enregistré : identifier précisément l'historique

Notre copie corrompue par mojibake résulte d'une chaîne bien connue : les octets UTF-8 d'origine ont été décodés en Windows-1252, puis ces mauvais caractères ont été réenregistrés en UTF-8. Le résultat contient notamment café ainsi que la séquence altérée de l'euro €.

Comme cette transformation spécifique n'a perdu aucun octet, le script de reproduction peut l'inverser : réencoder le mauvais texte en cp1252, puis décoder les octets obtenus en UTF-8. Il valide ensuite le texte récupéré en le comparant à l'original.

Cette approche est valable pour cette séquence précise, et ne constitue pas une règle universelle de « réparation du mojibake » applicable à tous les fichiers SRT. Un fichier peut renfermer des caractères légitimes, un historique d'encodages mixte ou du texte déjà altéré par une tentative de réparation antérieure. Privilégiez toujours la source intacte et le processus de conversion standard. S'il ne vous reste que le mojibake enregistré, conservez-le précieusement et déterminez sa méthode exacte de génération avant d'essayer d'appliquer une transformation inverse sur une autre copie.

Caractères de remplacement enregistrés : la lettre manquante n'y est pas encodée

Le fichier de test avec perte a été créé en décodant des octets Windows-1252 en UTF-8 avec le remplacement activé, puis en enregistrant le résultat. Différents caractères d'origine sont tous devenus le même marqueur � . Le marqueur enregistré ne contient pas suffisamment d'informations pour identifier quel caractère d'origine occupait cette position.

Ne confondez pas cela avec le simple fait de voir � dans une application. Si les octets d'origine restent intacts, un décodage correct peut encore récupérer le texte — comme c'est le cas pour notre source Windows-1252. Inspectez cette source avant de conclure à une perte définitive.

Si la seule copie restante a réellement remplacé le texte manquant par U+FFFD ou des points d'interrogation littéraux, réexportez ou réacquérir une source propre, ou vérifiez une transcription manuelle par rapport à un document fiable. Un point d'interrogation ordinaire peut aussi être une ponctuation légitime ; sa seule présence ne prouve rien. Le remplacement plausible généré par un modèle reste une supposition, et non des données de fichier récupérées.

Obtenez une source lisible — pas seulement une commande exécutée avec succès

Avant d'accepter le fichier réparé, comparez des mots et des symboles représentatifs avec la source fiable, confirmez que les lignes de repères et d'horodatages n'ont pas changé, puis ouvrez le nouveau fichier dans l'application qui l'utilisera. Le script préserve le texte décodé ; il ne s'agit pas d'un validateur de syntaxe SRT ni d'un test de recette pour la lecture.

Si vous pouvez désormais lire les sous-titres et n'avez pas besoin d'une autre langue, le travail est terminé. Si vous avez besoin d'une révision vidéo directe ou d'autres modifications, le comparatif des logiciels de sous-titrage détaille le rôle de chaque outil.

Ce n'est qu'une fois le texte source fiable — et si vous avez réellement besoin d'une autre langue — que vous pourrez passer au Traducteur de sous-titres de BookTranslator et au processus de traduction de sous-titres par IA. Considérez la réparation de l'encodage, la traduction et le visionnage de la piste finale comme des étapes distinctes. Aucune ne garantit à elle seule la réussite des autres.