Convertir l'encodage des caractères
Ou collez le texte d'un sous-titre
Options
Ceci change les octets, pas les sous-titres. Chaque caractère du fichier est écrit dans l'encodage choisi, pour qu'un lecteur ou un script exigeant un encodage donné reçoive un fichier lisible. UTF-8 est ce que tout outil moderne attend et ce que ce site écrit partout ailleurs. UTF-8 avec BOM, ce sont les mêmes octets précédés de la marque de trois octets. UTF-16 LE est ce que les programmes Windows appellent Unicode, pour environ deux fois la taille. Windows-1252 est l'ancien encodage d'Europe occidentale, un octet par caractère, et c'est celui avec lequel il faut faire attention : il n'a aucune place pour le chinois, le japonais, le coréen, le cyrillique, le grec ou les emoji, donc chaque caractère qu'il ne peut pas écrire ressort en point d'interrogation et est compté dans le rapport ci-dessus. Rien d'autre dans le fichier ne change.
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 réécrit un fichier de sous-titres dans un autre encodage de caractères. Quatre cibles sont proposées : UTF-8, qui est la valeur par défaut et l’encodage de tout le reste du site ; UTF-8 avec BOM, pour les outils qui lisent l’ouverture du fichier ; UTF-16LE, que les programmes Windows appellent simplement Unicode ; et Windows-1252, la page de codes d’Europe occidentale.
Ce qui change est le codage des caractères, pas le texte. Les deux volets de la page montrent les mêmes caractères et paraissent identiques, même quand le fichier passe de un à deux octets par caractère : c’est dans le gestionnaire de fichiers, dans l’éditeur et dans les octets que la différence se lit. Un fichier UTF-16 fait environ deux fois le poids du fichier UTF-8 d’origine ; un fichier Windows-1252 est plus petit, mais il ne peut pas écrire tout ce que l’UTF-8 écrit.
La page dit franchement ce qui ne passe pas. Un caractère absent de la cible est écrit comme un point d’interrogation et compté dans le rapport de pertes : cinq kana dans un fichier Windows-1252 donnent cinq remplacements, pas une erreur. Le choix est fait à l’écriture du fichier, pas à la lecture, donc vous voyez toujours ce que le fichier disait et, dans le rapport, ce que vous accepteriez de perdre en l’écrivant ainsi.
Choisir un encodage ne normalise rien d’autre : un bloc ne perd pas ses fins de ligne, ne gagne pas de marque et ne change pas d’heure parce que vous êtes passé par cette page. Aucun fichier n’est envoyé, et les douze formats sont reconnus à leur contenu. Pour deviner l’encodage d’un fichier illisible, c’est la page de correction qu’il faut, pas celle-ci.
Exemples
Un fichier anglais écrit en UTF-8
Entrée
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Sortie
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Le cas par défaut, et l’encodage que toutes les autres pages du site écrivent. La sortie égale l’entrée parce que le fichier était déjà en UTF-8. Ce que fixe cet exemple est la négative : choisir un encodage ne normalise rien d’autre, donc un bloc ne perd ni ses fins de ligne, ni son absence de marque, ni ses timecodes.
Le même fichier écrit en UTF-16LE
Entrée
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Sortie
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Les programmes Windows appellent cela Unicode, et c’est la cible qui change le plus visiblement le fichier : chaque caractère occupe deux octets, une marque est écrite devant, et le résultat fait environ deux fois la taille. Rien de cela n’est visible dans les volets, qui contiennent des caractères : c’est la taille du fichier et l’encodage affiché par l’éditeur qui le montrent. La compatibilité de l’outil en aval se vérifie avant, pas après.
Des sous-titres japonais écrits en Windows-1252
Entrée
1
00:00:01,000 --> 00:00:02,000
こんにちは
Sortie
1
00:00:01,000 --> 00:00:02,000
こんにちは
Cinq kana et une cible qui n’a de place pour aucun d’eux : le rapport de pertes de ce passage compte cinq caractères devenus des points d’interrogation. Les volets montrent encore les kana, parce que la substitution a lieu à l’écriture du fichier et non à sa lecture. Cette séparation est voulue : vous voyez ce que le fichier dit, et le rapport vous dit ce que cette écriture coûterait.
Questions fréquentes
Quelle est la différence entre UTF-8 et UTF-8 avec BOM ?
Les deux écrivent les mêmes caractères et le même texte ; le second ajoute trois octets EF BB BF devant le fichier. Ces octets servent à un programme qui lit l’ouverture pour connaître l’encodage, et ils dérangent un outil qui attend que le premier caractère soit le début du texte. Choisissez UTF-8 par défaut, et UTF-8 avec BOM seulement si l’outil en aval le réclame.
Que deviennent les caractères qui n’existent pas dans l’encodage cible ?
Ils sont écrits comme des points d’interrogation et comptés dans le rapport de pertes, avec le nombre exact de remplacements. La page ne refuse pas le passage et ne bascule pas silencieusement vers un autre encodage : vous demandez Windows-1252, vous obtenez du Windows-1252, et le rapport vous dit ce que cela coûte. C’est la seule façon de prendre la décision en connaissance de cause.
Pourquoi mon fichier UTF-16 est-il deux fois plus gros ?
Parce qu’en UTF-16 chaque caractère occupe deux octets, même une lettre latine qui tient sur un seul en UTF-8, et que le fichier commence par une marque d’ordre des octets. Le texte est identique, les timecodes et les blocs aussi ; seule la représentation change. C’est le prix d’un format que certains outils Windows lisent sans réglage, et il se vérifie dans la taille du fichier plutôt qu’à l’écran.
La page peut-elle écrire en UTF-16BE ou dans un autre encodage ancien ?
Non, la liste est volontairement courte : UTF-8, UTF-8 avec BOM, UTF-16LE et Windows-1252. Ces quatre cibles couvrent le web, les outils Windows et l’Europe occidentale. Un fichier déjà en UTF-16BE ou dans une page de codes asiatique n’est pas converti ici ; il peut être lu correctement par la page de correction, qui connaît Shift-JIS, GBK, Big5, EUC-KR et Windows-1251.
L’encodage choisi est-il conservé quand je laisse la valeur par défaut ?
Oui. Sans choix explicite, la page garde l’encodage du fichier d’entrée, qu’il soit déjà en UTF-8, en UTF-16LE ou dans une autre page de codes reconnue. C’est le comportement utile pour un passage de nettoyage : vous ne modifiez pas l’encodage par accident, et vous ne le changez que lorsque vous le demandez. Le fichier ressort alors identique octet pour octet.
Les timecodes et les blocs sont-ils modifiés par le changement d’encodage ?
Non. La page réécrit chaque caractère dans la cible sans toucher à la structure : les heures de début et de fin, les numéros de bloc, l’ordre et les retours à la ligne sont ceux du fichier. Une conversion d’encodage n’est pas une conversion de format ; si le format doit changer aussi, utilisez la page de conversion, puis revenez ici pour l’encodage final.