Le fichier est intact, il a été mal lu
Ce que stocke un fichier de sous-titres, ce sont des octets. Transformer des octets en caractères exige de savoir dans quel encodage ils ont été écrits : se tromper là-dessus donne des caractères illisibles. Il ne manque pas un seul octet au fichier ; relisez-le avec le bon encodage et les caractères reviennent.
Cela coupe le travail en deux : trouver avec quel encodage il a commencé et l'enregistrer dans un encodage que votre lecteur détecte. Le premier vient d'essais de décodage notés, le second d'un nouvel enregistrement. Ils résolvent deux problèmes différents.
Cinq aspects, cinq causes
Les caractères illisibles n'apparaissent pas au hasard : leur aspect trahit la cause :
- Des blocs de lettres accentuées (`ä½ å¥½`) : du chinois en UTF-8 lu comme un encodage à un octet — en UTF-8, un caractère chinois occupe trois octets, et lire octet par octet transforme chaque octet en sa propre lettre
- Des suites de caractères CJK sans un seul caractère courant : de l'UTF-8 lu comme du GBK — les octets sont regroupés par paires et chaque paire tombe sur un caractère rare
- Un tas de symboles monétaires et mathématiques : les octets ont atterri dans la zone des symboles, typique d'une lecture en Mac Roman ou en variante Latin-1
- Des caractères de contrôle mélangés : les octets ont atterri dans la zone de contrôle invisible et s'affichent en blancs ou en carrés
- Le point d'interrogation encadré `�` : c'est le caractère de remplacement, pas du texte illisible — il signifie « il y avait un caractère ici, et il était déjà perdu à la lecture »
Pourquoi le caractère de remplacement ne se répare pas
Le caractère de remplacement est la ligne de partage. Un `�` signifie que les octets ont déjà été jetés à une étape antérieure (en général un programme qui a lu le fichier et l'a réenregistré), et rien n'a été consigné de ce qui a disparu. Là, il n'y a rien d'où déduire quoi que ce soit : personne ne peut réparer.
C'est pourquoi la page de réparation traite deux cas différemment. Envoyez un fichier et les octets d'origine restent intacts, ce qui permet d'essayer chaque encodage ; si le texte collé contient déjà le caractère de remplacement, elle l'annonce clairement : « impossible à réparer, envoyez le fichier d'origine ».
Il y a aussi le cas inverse : le contenu se lit parfaitement, mais votre lecteur affiche encore n'importe quoi. La faute n'est pas au fichier : le lecteur a choisi le mauvais encodage. Modifier le texte ne sert à rien ; enregistrez une copie en UTF-8 avec BOM ou en GBK et donnez-la-lui.
Ce qui est comparé pendant la réparation
L'outil essaye tous les encodages plausibles, puis note chaque résultat : part de caractères courants, présence de suites d'accents, de suites de symboles, caractères CJK formant des murs de caractères rares. Le résultat le mieux noté remonte en tête de liste.
Si aucun score n'est nettement meilleur, rien n'est recommandé : mieux vaut vous dire « cela se lit bien tel quel » que de vous refiler un résultat qui ne ressemble que vaguement à une langue. Un texte abîmé deux fois reçoit une passe supplémentaire de résolution inverse sur les premiers candidats.
Enregistrer le bon encodage termine le travail
Le texte réparé doit encore être enregistré dans un encodage que votre lecteur reconnaît. Les lecteurs sous Windows se fient généralement au BOM pour détecter l'encodage, donc l'UTF-8 avec BOM est le moins compliqué ; les vieux appareils et certains lecteurs régionaux réclament du GBK. Vous pouvez choisir UTF-8, UTF-8 (avec BOM), GBK, Big5, Shift_JIS ou EUC-KR, et vous serez invité à en prendre un autre si quelque chose n'y tient pas (le GBK ne peut pas contenir du coréen).
Outils et guides liés
La marche à suivre complète : Réparer des sous-titres illisibles ; ce que contient réellement un fichier SRT : Ce que contient un fichier SRT ; l'encodage est bon mais le contenu est sale (filigranes, pub, indications pour malentendants) : Nettoyage de sous-titres.