Convertir la fin de ligne
Ou collez le texte d'un sous-titre
Options
Chaque ligne du fichier se termine par un caractère invisible (LF) ou deux (CRLF). Lecteurs, éditeurs et outils de sous-titres lisent les deux : ce n'est donc presque jamais la cause d'un mauvais comportement — les deux vraies causes sont une chaîne de compilation ou un analyseur strict qui rejette l'autre forme, et un outil de comparaison qui affiche chaque ligne comme modifiée parce que les fins diffèrent. LF est le choix par défaut ici parce que c'est ce qu'utilisent Unix, macOS et le web, et parce qu'un fichier qui l'a déjà reste intact. Choisir CRLF convertit les deux formes existantes : un fichier mixte ressort cohérent.
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 uniformise les fins de ligne d’un fichier de sous-titres : soit LF, le saut de ligne Unix, soit CRLF, la paire Windows. Les deux écritures ont le même effet à l’écran, mais un fichier qui mélange les deux se comporte différemment selon l’outil qui le lit : certains éditeurs ajoutent une ligne vide après chaque ligne, un script shell garde un retour chariot collé au dernier champ, et un contrôle de version voit tout le fichier comme modifié.
Le travail se fait en deux temps. La page commence par ramener le fichier à une seule convention — les fins mixtes, les CR isolés et les LF sont tous reconnus — puis écrit chaque fin dans la cible choisie. La ligne vide qui sépare deux blocs est une fin de ligne comme une autre : elle est convertie elle aussi, sinon un fichier SRT garderait un séparateur en LF au milieu d’un fichier CRLF, et le défaut resterait invisible jusqu’au prochain outil.
La différence entre les deux cibles se lit dans les exemples plutôt qu’à l’écran. Un fichier converti en CRLF porte deux caractères à chaque fin de ligne, et un fichier ramené en LF n’en porte qu’un. C’est un caractère par ligne qui change, pas le texte, les timecodes ni l’ordre des blocs.
Aucun fichier n’est envoyé et les douze formats sont reconnus à leur contenu. La page ne touche ni à l’encodage, ni au BOM, ni au contenu : un fichier touché par deux machines devient uniforme, et un fichier déjà uniforme revient identique à la cible près. Pour ajouter un BOM, il y a une page séparée, et c’est volontaire.
Exemples
Convertir un fichier Unix en fins Windows
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.
Chaque fin de ligne devient une paire CR LF, y compris la ligne vide entre les deux blocs — cette ligne vide est une fin de ligne comme les autres, et une conversion qui l’oublierait laisserait un séparateur en LF nu. La sortie montre les paires pour qu’on puisse les compter ; rien d’autre n’a bougé dans le fichier, ni les timecodes ni le texte.
Ramener un fichier Windows en fins Unix
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 sens qui a une conséquence visible : un fichier qui garde un retour chariot parasite s’affiche dans certains éditeurs avec une ligne vide après chaque ligne, et dans un pipeline shell avec un CR collé au dernier champ. La vidéo, les timecodes et le texte sont identiques dans les deux fichiers ; la différence est un caractère en fin de ligne, et c’est ce sens qui le retire.
Un fichier touché sur deux machines, rendu uniforme
Entrée
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Sortie
1
00:00:01,000 --> 00:00:02,000
Mixed endings.
2
00:00:03,000 --> 00:00:04,000
Second.
Le même fichier édité sur deux systèmes : certaines lignes finissent en CRLF, d’autres en LF, et un séparateur de blocs est écrit de chaque façon. La sortie est uniforme, ce qui est le but : le fichier ne signifie plus quelque chose de différent selon la ligne qu’on lit. Un rechercher-remplacer naïf se trompe dans les deux sens, en laissant les lignes LF ou en produisant un double CR.
Questions fréquentes
Quelle est la différence entre LF et CRLF dans un fichier de sous-titres ?
LF est un seul caractère, le saut de ligne des systèmes Unix et du web ; CRLF en est deux, le retour chariot suivi du saut de ligne des systèmes Windows. Les deux produisent le même affichage dans un lecteur vidéo, mais un fichier qui mélange les deux se comporte différemment dans les éditeurs, les scripts et les outils de version. La page choisit l’une des deux conventions et l’applique partout.
La ligne vide entre deux blocs est-elle convertie elle aussi ?
Oui, et c’est un des points que la page traite explicitement. Dans un SRT, la ligne vide sépare les blocs et se termine comme les autres lignes ; si elle restait en LF au milieu d’un fichier CRLF, le fichier serait encore mixte et le défaut ressortirait chez l’outil suivant. La conversion porte donc sur toutes les fins de ligne, visibles ou non.
Un fichier avec des fins de ligne mixtes est-il accepté ?
Oui. La page commence par reconnaître les trois formes — CRLF, LF et CR isolé — puis réécrit chaque fin dans la cible choisie. Un fichier édité sur deux machines ou passé par plusieurs outils n’a donc pas besoin d’être nettoyé avant : le résultat est uniforme, et c’est précisément le cas que l’exemple trois illustre. Aucune fin de ligne ne survit dans l’autre convention.
La conversion change-t-elle le texte ou les timecodes ?
Non. Seuls les caractères de fin de ligne changent : le texte de chaque bloc, les heures de début et de fin, les numéros et l’ordre restent identiques. C’est pourquoi la page est sûre sur un fichier qu’on vient de valider — si la synchronisation était bonne avant, elle l’est après, et le seul changement est un caractère en fin de ligne.
La page modifie-t-elle aussi l’encodage ou le BOM ?
Non, elle ne touche ni à l’un ni à l’autre : un fichier UTF-8 reste en UTF-8, un fichier UTF-16LE reste en UTF-16LE, et une marque présente reste en place. Cette séparation est volontaire, car les trois opérations — encodage, BOM, fin de ligne — se ressemblent dans un éditeur hexadécimal et se réparent séparément. Chacune a sa page pour cette raison.
Quels formats sont acceptés par la page des fins de ligne ?
Les douze formats du site : SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON, TXT et CSV. La fin de ligne appartient au fichier et non au format, donc elle se normalise sur n’importe quel texte de sous-titres. Un fichier vide ou un fichier binaire n’a pas de blocs à réécrire et n’est pas concerné ; les sous-titres en bitmap ont leurs propres pages.