Ajouter un BOM aux sous-titres
Ou collez le texte d'un sous-titre
Options
Une BOM est constituée de trois octets au tout début du fichier qui indiquent son encodage. Elle est invisible dans tous les éditeurs et lecteurs, n'occupe aucune place à l'écran, et rien dans les sous-titres ne change quand on l'ajoute ou qu'on la retire. Deux sortes d'outils s'y intéressent : les programmes Windows qui écrivent des sous-titres, qui en mettent une par défaut, et les analyseurs stricts des chaînes de compilation, qui rejettent un fichier commençant par une BOM. Cette page ouvre le cadre dans l'état que son titre nomme, pour que vous puissiez l'inverser si votre fichier s'avère être dans l'autre cas. Un fichier en UTF-16 porte toujours une BOM, car c'est ainsi qu'un lecteur sait lequel des deux ordres d'octets il lit — demander sa suppression dans ce cas la laisse en place.
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 place un BOM UTF-8 en tête d’un fichier de sous-titres. Le BOM est le caractère U+FEFF, écrit en trois octets EF BB BF : il ne s’affiche pas, il ne ressemble à rien, et la plupart des éditeurs ne le montrent jamais. Sa raison d’être est qu’un programme en aval puisse reconnaître l’encodage en lisant les premiers octets au lieu de deviner.
Le geste est plus petit qu’il n’y paraît, et c’est exactement pour cela qu’il a sa page. La page commence par retirer un BOM déjà présent, puis en écrit un seul. Un fichier déjà marqué revient donc octet pour octet au lieu de porter deux marques, une situation invisible dans tous les éditeurs et différente pour tout ce qui lit l’ouverture du fichier. Le BOM est idempotent par construction.
Le reste du fichier n’est pas touché. Les fins de ligne d’un fichier Windows restent en CRLF, les timecodes restent à leur place, l’ordre des blocs ne change pas. C’est volontaire : un BOM et des fins de ligne CRLF sont deux choses que les outils Windows écrivent ensemble, mais elles sont séparées, et une page qui reformaterait les fins de ligne en même temps modifierait silencieusement chaque fichier qu’on lui donne.
Rien n’est envoyé. Les douze formats sont reconnus à leur contenu. Une conversion de format ne transporte pas le BOM : si un fichier doit finir en SRT avec un BOM, convertissez d’abord, puis passez-le ici. Et si le fichier est déjà en UTF-8 sans BOM, la sortie est identique à trois octets près, ce qui ne se voit que dans un éditeur qui affiche l’encodage.
Exemples
Un fichier ASCII, avec une marque devant
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.
Les deux volets se ressemblent et ce n’est pas un défaut d’affichage : la différence tient en trois octets, dont aucun n’a de forme. Téléchargez le résultat et ouvrez-le dans un éditeur qui montre l’encodage, ou regardez les premiers octets dans un visualiseur hexadécimal : la marque est la première chose visible. La taille du fichier augmente de trois octets, pas d’un caractère apparent.
Un fichier Windows, marque ajoutée et retours chariot conservés
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 BOM est ajouté devant la première ligne, et chaque CR LF reste celui du fichier. C’est la distinction à retenir : la marque et les fins de ligne se ressemblent dans un fichier Windows, mais cette page n’écrit que la première. Un outil qui uniformiserait aussi les fins de ligne modifierait tous les fichiers qu’on lui confie ; pour cela, il y a la page des fins de ligne.
Un fichier qui porte déjà une marque
Entrée
1
00:00:01,000 --> 00:00:02,000
Already marked.
Sortie
1
00:00:01,000 --> 00:00:02,000
Already marked.
La sortie est l’entrée octet pour octet : le fichier garde exactement une marque. La version naïve de cette page, qui colle une marque sans retirer celle qui est là, en produit deux, et une double marque est invisible partout tout en étant un fichier différent pour ce qui lit les premiers octets. Relancer la page sur un fichier déjà marqué doit être une chose qu’on fait sans y penser.
Questions fréquentes
À quoi sert un BOM au début d’un fichier de sous-titres ?
À signaler l’encodage sans ambiguïté : les trois octets EF BB BF disent « ce fichier est en UTF-8 » à un programme qui lit l’ouverture plutôt que de deviner. Certains outils Windows et certains analyseurs stricts le demandent, et c’est aussi la raison pour laquelle un fichier marqué peut être refusé par un outil qui n’en veut pas. Le BOM ne change ni le texte, ni les timecodes, ni l’affichage.
Le BOM sera-t-il visible dans le fichier téléchargé ?
Non, et aucun éditeur de texte ne l’affiche comme un caractère. Il se voit dans un éditeur qui montre l’encodage — souvent noté « UTF-8 with BOM » ou « UTF-8-BOM » — ou dans un visualiseur hexadécimal, où EF BB BF précède le premier octet du texte. La taille du fichier augmente de trois octets ; c’est la seule mesure visible depuis un gestionnaire de fichiers.
La page touche-t-elle aux fins de ligne d’un fichier CRLF ?
Non. Le BOM est écrit avant la première ligne et les retours chariot du fichier restent tels quels : un fichier Windows reste un fichier Windows. Cette séparation est délibérée, car les deux changements sont faciles à confondre et un outil qui les ferait ensemble modifierait chaque fichier qu’on lui donne. Si c’est la fin de ligne qu’il faut changer, la page dédiée s’en occupe séparément.
Que se passe-t-il si le fichier a déjà un BOM ?
La page le retire puis en écrit un seul, donc le fichier revient identique octet pour octet. C’est ce qui rend l’opération sûre à relancer : aucun risque d’accumuler deux marques, situation que personne ne voit à l’écran mais qui change le fichier pour tout lecteur des premiers octets. Le résultat d’un second passage est le même fichier que celui du premier.
Le BOM survit-il à une conversion de format ?
Pas forcément : une conversion réécrit le fichier dans le nouveau format et le BOM n’est pas un élément du format de sous-titres. L’ordre correct est donc de convertir d’abord, puis d’ajouter la marque sur le fichier final. Si vous ajoutez la marque avant, le fichier converti peut la perdre sans que rien ne le signale, et il faudra repasser par cette page.
Quels formats acceptent un BOM sur cette page ?
Les douze formats du site : SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON, TXT et CSV. Le BOM est une propriété du fichier et non du format, donc il se place devant n’importe quel texte. Un fichier binaire, un vidéo ou un sous-titre en bitmap n’entre pas ici : ce sont d’autres pages, avec leurs propres limites.