Aller au contenu principal
SubtitleMatrix

Convertir SRT en JSON

Ou collez le texte d'un sous-titre

Ce que cette conversion change

Rien n'est perdu dans ce sens — chaque fonctionnalité du format source a un équivalent dans le format cible.

Ce rapport de pertes vient de la matrice de capacités de ces deux formats, pas du fichier particulier que vous avez chargé. Un fichier précis peut perdre davantage s'il utilise des fonctionnalités que le format autorise mais que la matrice ne modélise pas.

Cette page transforme un fichier de sous-titres en données structurées : un document JSON qui énumère chaque bloc avec son début, sa fin et son texte. Le schéma est celui de ce site, volontairement petit — un numéro de version et un tableau de blocs, avec des temps en millisecondes entières plutôt qu'en codes temporels. Rien n'y dépend d'une bibliothèque particulière et rien n'y est deviné.

Les millisecondes évitent toute analyse de chaîne : la résolution la plus fine de tous les formats de ce site est la milliseconde, et un entier ne se trompe ni de virgule ni de point. Une ligne sans mise en forme reste une chaîne ; une ligne qui porte de l'italique, du gras ou une couleur devient un objet avec le texte et les balises qui le couvrent, chacune indiquant son type et l'intervalle de caractères concerné.

Le résultat se charge dans un script, se compare ou entre dans un système de versions, et la conversion inverse redonne les sous-titres. Le travail se fait dans le navigateur.

Exemples

Un fichier SRT typique, converti en JSON

Entrée

1
00:00:01,000 --> 00:00:03,500
Hello there.

2
00:00:03,500 --> 00:00:06,000
<i>Whispering</i> now.
And a second line.

3
00:00:06,000 --> 00:00:09,250
<b>Bold</b> statement.

Sortie

{
  "version": 1,
  "cues": [
    {
      "id": "1",
      "start": 1000,
      "end": 3500,
      "lines": [
        "Hello there."
      ]
    },
    {
      "id": "2",
      "start": 3500,
      "end": 6000,
      "lines": [
        {
          "text": "Whispering now.",
          "tags": [
            {
              "kind": "italic",
              "start": 0,
              "end": 10
            }
          ]
        },
        "And a second line."
      ]
    },
    {
      "id": "3",
      "start": 6000,
      "end": 9250,
      "lines": [
        {
          "text": "Bold statement.",
          "tags": [
            {
              "kind": "bold",
              "start": 0,
              "end": 4
            }
          ]
        }
      ]
    }
  ]
}

Aucune perte ici : les deux colonnes se comparent ligne par ligne.

La même conversion sur une entrée mal formée

Entrée

1
0:00:01,00 --> 0:00:03,500
<B>Bold</B> and <I>italic</I>.


2
00:00:03,500 --> 00:00:06,000


3
00:00:08,000 --> 00:00:09,000
Last one.

Sortie

{
  "version": 1,
  "cues": [
    {
      "id": "1",
      "start": 1000,
      "end": 3500,
      "lines": [
        {
          "text": "Bold and italic.",
          "tags": [
            {
              "kind": "bold",
              "start": 0,
              "end": 4
            },
            {
              "kind": "italic",
              "start": 9,
              "end": 15
            }
          ]
        }
      ]
    },
    {
      "id": "2",
      "start": 3500,
      "end": 6000,
      "lines": []
    },
    {
      "id": "3",
      "start": 8000,
      "end": 9000,
      "lines": [
        "Last one."
      ]
    }
  ]
}

C'est le genre de dégâts que portent les vrais fichiers : fins de ligne mélangées, espaces parasites, champs vides. Comparez avec l'exemple propre ci-dessus pour voir ce que l'analyseur pardonne.

Questions fréquentes

Quel schéma suit le JSON produit à partir d'un SRT ?

Celui de ce site : un numéro de version, puis un tableau de blocs. Chaque bloc porte un identifiant, un début et une fin en millisecondes, et une liste de lignes ; l'exemple affiché plus haut montre la forme exacte, sans métadonnée cachée.

Pourquoi des millisecondes plutôt que des codes temporels SRT ?

Pour que le fichier serve sans être reparsé : additionner, comparer ou trier des temps devient une opération sur des entiers, alors qu'une chaîne comme 00:00:01,000 doit d'abord être décodée, avec le risque de se tromper de séparateur.

Comment l'italique et le gras d'un SRT sont-ils représentés dans le JSON ?

Une ligne simple reste une chaîne ; une ligne balisée devient un objet avec son texte et un tableau de balises, chacune indiquant son type et ses positions de début et de fin. Le retour vers le SRT réécrit ensuite les balises d'origine.

Un bloc SRT sur deux lignes donne-t-il deux entrées JSON ?

Non : il donne deux éléments dans la liste de lignes du même bloc. La paire reste un seul sous-titre, avec un seul début et une seule fin, ce qui préserve la synchronisation.

Le JSON est-il modifiable à la main ?

Oui, et la conversion inverse sert de contrôle : si le fichier s'analyse, les blocs ressortent avec les temps fournis. Un aller-retour par le convertisseur est donc un moyen rapide de repérer une faute de syntaxe.

Les numéros de blocs SRT sont-ils conservés comme identifiants ?

Ils sont recopiés dans le champ id de chaque bloc. Contrairement au SRT, où le compteur doit rester numérique, le schéma JSON accepte un identifiant libre, mais il ne réinterprète pas les nombres d'origine.

Que se passe-t-il pour les fichiers SRT volumineux ?

Ils sont traités dans le navigateur, sans téléversement ; au-delà de 10 Mo, le travail passe par un Worker pour ne pas bloquer l'interface. Le résultat est identique, seule la manière de calculer change.

Outils associés