Corriger l'encodage des caractères
Ou collez le texte d'un sous-titre
Options
Ceci change la façon dont le fichier est lu, pas ce qui est écrit. Normalement l'encodage est déduit des premiers octets : une marque d'ordre des octets s'il y en a une, UTF-8 si le fichier est un UTF-8 valide, et Windows-1252 sinon. Cela marche pour les fichiers d'Europe occidentale et se trompe pour tous les autres : un fichier japonais, chinois, coréen ou cyrillique arrive comme un écran d'accents sans queue ni tête. Nommez l'encodage ici et la devinette est ignorée. Détection automatique est le choix par défaut et ne fait rien du tout, ce qui le rend sûr à laisser tel quel. Notez que le résultat est réécrit en UTF-8 : les navigateurs ne savent produire qu'une poignée d'encodages, et aucun de ceux de cette liste n'en fait partie. C'est justement l'intérêt de la page — le texte ressort correct et dans une forme que tout outil peut lire.
La fréquence d'images dans laquelle les temps sont comptés. Sur les pages de format, c'est ce dont MicroDVD a besoin, car il stocke les temps sous forme de numéros d'image. Sur les pages de fréquence d'images, c'est la cadence à laquelle le fichier a été minuté — la version pour laquelle les sous-titres ont été faits — et le second cadre de la page prend la cadence de la vidéo avec laquelle vous allez les utiliser. 23,976, 24, 25, 29,97, 30, 50, 59,94 et 60 sont les valeurs courantes. Se tromper décale toute la chronologie et, sur les pages de fréquence d'images, ce décalage est un rapport, pas un montant fixe.
Cette page corrige un fichier de sous-titres dont le texte s’affiche en charabia. Le problème est presque toujours le même : les octets du fichier sont justes, mais ils ont été lus dans le mauvais encodage, et chaque caractère accentué ou non latin est devenu une suite d’autres caractères. La page relit le fichier dans l’encodage choisi avant de l’analyser, puis l’écrit dans le format qu’il avait déjà.
Deux réglages existent. « Automatique » ne nomme aucun encodage : c’est le comportement d’avant cette page, et c’est le choix à reprendre quand un essai précis a aggravé les choses. Les encodages nommés — Shift-JIS, GBK, Big5, EUC-KR, Windows-1251 et ISO-8859-1 — servent quand la devinette se trompe, ce qui arrive surtout sur les fichiers d’Europe occidentale dont les octets forment par hasard une séquence UTF-8 valide : le navigateur devine UTF-8 et rend des caractères qui ne sont pas ceux du fichier.
Le choix s’applique avant l’analyse du sous-titre, pas après. Il n’y a donc aucun moment où les mauvais caractères sont à l’écran et les bons ne le sont pas : la page lit les octets avec l’encodage demandé, obtient le texte réel, puis travaille dessus. C’est aussi pourquoi un fichier réparé est réécrit en UTF-8 : le problème de lecture est résolu, et la sortie ne le reproduira pas.
Rien n’est envoyé, et les douze formats sont reconnus à leur contenu. Un mauvais choix n’abîme pas le fichier : il produit d’autres caractères, et il suffit de relancer avec le bon encodage. C’est la page à essayer avant de déclarer un fichier perdu.
Exemples
Détection automatique sur un fichier déjà correct
Entrée
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Sortie
1
00:00:01,000 --> 00:00:02,000
The room is dark.
2
00:00:03,000 --> 00:00:04,000
A cold night.
Le réglage par défaut, et le seul qui ne demande rien : avec « Automatique », aucun encodage n’est nommé, donc le fichier est lu exactement comme avant l’existence de cette page. C’est ce qui permet de l’ouvrir sur un fichier douteux sans risque : si rien n’était cassé, rien ne se passe, et c’est le réglage vers lequel revenir quand un choix précis a empiré les choses.
Le même fichier lu en Shift-JIS
Entrée
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Sortie
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Le même fichier lu de deux façons. Ce que le volet contient une fois les octets lus en Shift-JIS, c’est le japonais qu’ils disaient depuis le début ; lus comme du texte occidental, ces mêmes octets donnent une ligne de lettres accentuées sans rapport, et c’est cet état qui fait chercher cette page. Les deux volets montrent la version lisible, parce que la relecture a lieu avant l’analyse : il n’y a pas d’étape où les mauvais caractères sont affichés. La sortie est réécrite en UTF-8.
Un fichier occidental que la détection lit en UTF-8
Entrée
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Sortie
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Le cas difficile, et le seul où « Automatique » et un encodage nommé se contredisent dans un navigateur. Les octets du fichier forment par hasard une séquence UTF-8 valide, donc la devinette dit UTF-8 et les caractères remis ne sont pas ceux du fichier. Nommer ISO-8859-1 force la lecture européenne. C’est la même table de codes dans les deux cas, et c’est ce qui est facile à comprendre de travers : le choix ne change pas la table, il passe outre la devinette.
Questions fréquentes
Comment savoir quel encodage choisir pour un fichier illisible ?
Le symptôme oriente : des suites comme « é » à la place de « é » indiquent un fichier européen lu en UTF-8, tandis que des caractères japonais, chinois, coréens ou cyrilliques remplacés par des symboles indiquent une page de codes asiatique ou Windows-1251. Essayez l’encodage de la langue du texte, puis un autre ; un mauvais choix ne détruit rien, il produit d’autres caractères, et vous pouvez relancer. Le réglage automatique reste le point de départ sûr.
La page répare-t-elle le fichier ou seulement l’affichage ?
Les deux, dans cet ordre : elle relit les octets avec l’encodage choisi, obtient le texte réel, puis réécrit le fichier en UTF-8. La réparation n’est donc pas un filtre d’affichage qui disparaîtrait au téléchargement ; c’est le fichier qui change. C’est aussi la limite : si le fichier a déjà été enregistré dans le mauvais encodage par un autre outil, les octets d’origine ne sont plus là et aucune page ne peut les retrouver.
Pourquoi « Automatique » choisit-il UTF-8 pour un fichier européen ?
Parce qu’un fichier en ISO-8859-1 peut former une séquence valide en UTF-8 : les octets des lettres accentuées sont alors lus comme deux caractères, ce qui donne les suites familières « é » ou « è ». La devinette du navigateur suit les règles du web et privilégie UTF-8. Nommer ISO-8859-1 passe outre cette devinette et force la lecture européenne ; c’est le seul cas de cette page où le réglage manuel est indispensable.
Que devient un fichier réparé : garde-t-il son encodage d’origine ?
Non, il est écrit en UTF-8, comme tous les fichiers de ce site. C’est délibéré : l’encodage d’origine est précisément ce qui posait problème, et le conserver reproduirait la panne chez le prochain lecteur. Un fichier japonais lu en Shift-JIS ressort donc en UTF-8 lisible. Si une cible précise est exigée en aval, la page de conversion d’encodage permet de choisir UTF-16LE ou Windows-1252 ensuite.
Un mauvais choix d’encodage peut-il abîmer définitivement mon fichier ?
Non. La page lit le fichier déposé et écrit un nouveau fichier ; elle ne modifie jamais l’original. Un mauvais choix donne un texte différent, parfois aussi illisible, et il suffit de relancer avec un autre encodage. La seule chose à ne pas faire est de télécharger le résultat d’un mauvais essai et de le redonner ensuite à la page : là, les octets d’origine ont déjà été remplacés.
Quels encodages la page sait-elle relire ?
Automatique, puis Shift-JIS, GBK, Big5, EUC-KR, Windows-1251 et ISO-8859-1. Cette liste couvre le japonais, le chinois simplifié et traditionnel, le coréen, le cyrillique et l’Europe occidentale, c’est-à-dire les fichiers que les outils de sous-titrage produisent le plus souvent. Un encodage absent de la liste peut parfois être traité en convertissant d’abord le fichier avec un autre outil, puis en le déposant ici.