Aggiungere il BOM ai sottotitoli
Oppure incollare il testo dei sottotitoli
Opzioni
Una BOM è composta da tre byte all’inizio del file che dichiarano in quale codifica si trova. È invisibile in ogni editor e lettore, non occupa spazio sullo schermo e nulla nei sottotitoli cambia quando viene aggiunta o rimossa. Due tipi di strumenti se ne occupano: i programmi Windows che scrivono sottotitoli, che ne inseriscono una per impostazione predefinita, e gli analizzatori severi delle pipeline di build, che rifiutano un file che inizia con una BOM. Questa pagina apre il riquadro nello stato che il suo titolo nomina, così è possibile invertirlo se il file risulta essere nell’altro. Un file in UTF-16 porta sempre una BOM, perché è così che un lettore sa quale dei due ordini di byte sta leggendo: chiederne la rimozione in quel caso la lascia al suo posto.
La frequenza dei fotogrammi in cui sono contati i tempi. Nelle pagine di formato è quella che serve a MicroDVD, perché memorizza i tempi come numeri di fotogramma. Nelle pagine della frequenza dei fotogrammi è la cadenza con cui è stato temporizzato il file — la versione per cui sono stati creati i sottotitoli — e il secondo riquadro della pagina accetta la frequenza del video con cui verranno usati. 23,976, 24, 25, 29,97, 30, 50, 59,94 e 60 sono quelle comuni. Sbagliarla sposta l’intera timeline, e nelle pagine della frequenza dei fotogrammi la sposta di un rapporto anziché di un importo fisso.
Un byte order mark è un carattere — U+FEFF — che sta davanti a tutto il resto del file. In UTF-8 sono tre byte, EF BB BF, ed è la prima cosa che un lettore vede. Nulla nell’output di questa pagina sembra diverso: gli stessi blocchi, gli stessi timecode, le stesse interruzioni di riga, e un segno davanti al primo di essi.
Perché qualcuno lo voglia lì è che il segno è il modo in cui un file dice «sono UTF-8» senza dirlo. Un programma che apre un file di sottotitoli deve indovinare in quale codifica si trova, e molti di essi — lettori Windows più vecchi, strumenti di authoring per dischi, script che leggono la prima riga — decidono guardando i primi byte invece di provare a interpretare l’intero file. Date loro il segno e un nome accentato, una virgoletta tipografica o una lettera greca escono come se stesse. Toglietelo e lo stesso file può essere letto con la codepage locale del sistema, dove quei caratteri diventano qualcos’altro del tutto.
L’altra direzione è quella che si incontra di solito per prima: un file che ha un segno, aperto da uno strumento che non se lo aspetta. Quello strumento legge i tre byte come tre caratteri e li mostra all’inizio della prima riga, ed è da lì che viene il piccolo blocco di simboli in cima al file di sottotitoli di qualcuno. Se è quello che vedete, questa è la pagina sbagliata: il segno va rimosso invece che aggiunto, e la pagina che lo fa è collegata più sotto.
Ciò che la pagina non farà è riformattare il file al passaggio. Non tocca le interruzioni di riga CRLF, i numeri dei blocchi, gli orari o il testo di alcun blocco, e non decide per voi la codifica del file: un file che non è UTF-8 è un problema diverso, e c’è una pagina anche per quello. Ciò che fa è aggiungere un carattere in testa, e se il carattere è già presente lascia il file in pace invece di aggiungerne un secondo, quindi eseguire la pagina due volte dà lo stesso file che eseguirla una. Il segno viene aggiunto al file che scaricate, quindi i due riquadri possono essere identici all’occhio — un carattere invisibile è esattamente ciò che sembra un carattere invisibile — e il modo onesto di controllare il risultato è guardare i primi tre byte in un visualizzatore esadecimale o la codifica nella barra di stato dell’editor. Tutti e dodici i formati che il sito gestisce possono portare un segno, perché un segno è una proprietà dei byte iniziali e non sa nulla dei blocchi. Nulla viene caricato: il file viene letto, modificato e scritto dentro il browser.
Esempi
Un file di sottotitoli ASCII, con un segno davanti
Ingresso
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.
Uscita
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.
Il testo atteso comincia con un carattere invisibile: U+FEFF, i tre byte EF BB BF, prima dell’1 del primo numero di blocco. I due riquadri vi sembreranno uguali e non è un difetto di resa: la differenza tra questi file è lunga tre byte e nessuno di essi ha una forma. Scaricate il risultato e apritelo in un editor che mostra la codifica, oppure guardate i primi byte in un visualizzatore esadecimale, ed è la prima cosa che vedete.
Un file Windows, segno aggiunto e ritorni a capo conservati
Ingresso
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Uscita
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Le due cose che uno strumento Windows scrive sono un segno e interruzioni di riga CRLF, ed è per questo che vengono confuse — ma sono separate, e questa pagina scrive solo la prima. Ogni ritorno a capo nel file atteso è quello del file di partenza, e il segno viene aggiunto davanti a essi. Una pagina che riscrivesse anche le interruzioni di riga riformatterebbe in silenzio ogni file ricevuto, che è esattamente il tipo di modifica che nessuno nota finché uno strumento a valle non se ne occupa.
Un file che porta già un segno
Ingresso
1
00:00:01,000 --> 00:00:02,000
Already marked.
Uscita
1
00:00:01,000 --> 00:00:02,000
Already marked.
L’input ha già un segno, quindi l’output è l’input byte per byte: il file ne conserva esattamente uno. La versione ingenua di questa pagina, che incolla un segno senza prima togliere quello che c’è, ne produce due, e un segno raddoppiato è invisibile in ogni editor pur essendo un file diverso per qualsiasi cosa legga i byte iniziali. Eseguire la pagina su un file già marcato dovrebbe essere qualcosa che potete fare senza pensarci.
Domande frequenti
Che cosa cambia davvero aggiungere un byte order mark a un file di sottotitoli?
Un carattere in testa al file: U+FEFF, scritto come i tre byte EF BB BF in UTF-8. Nessun blocco viene aggiunto, rimosso o modificato, nessun timecode si sposta, i numeri dei blocchi e le interruzioni di riga escono come sono entrati, e il testo di ogni riga è intatto. Se confrontate i due file, l’unica riga che differisce è la prima, e differisce di tre byte al suo inizio.
Perché i due riquadri di questa pagina sembrano identici?
Perché il carattere che viene aggiunto non ha forma. U+FEFF è uno spazio unificatore a larghezza zero, quindi un riquadro che rende il testo come farebbe il vostro lettore mostra la stessa cosa prima e dopo. Il cambiamento è reale ed è nel file che scaricate: la differenza sono i primi tre byte. L’indicatore di codifica del vostro editor, o un visualizzatore esadecimale che mostra EF BB BF all’inizio, è dove guardare invece che nel testo.
È sicuro eseguire due volte lo strumento che aggiunge il BOM allo stesso file?
Sì. La pagina rimuove qualsiasi segno già presente prima di scrivere il proprio, quindi un file che ne porta già uno torna invariato e un file che non ne ha riceve esattamente uno. Due esecuzioni danno lo stesso file di una. Questo significa anche che un file passato da questa pagina e poi da uno strumento che ha aggiunto un secondo segno può essere ripulito facendolo passare ancora una volta, perché ne sopravvive uno solo.
Il segno viene conservato se poi converto il file in un altro formato?
Non dalle pagine di conversione di questo sito, che scrivono UTF-8 semplice senza segno, quindi un segno aggiunto qui non sopravvive a un cambio di formato. Ordinate il lavoro di conseguenza: convertite prima, poi aggiungete il segno come ultimo passo prima della consegna. È anche l’ordine più sensato in generale, dato che il segno è una proprietà del file finito invece che del contenuto dei sottotitoli.
Aggiungere un segno cambia le interruzioni di riga del file?
No. Un segno UTF-8 è un carattere posto prima del primo byte del file e non ha effetto su ciò che segue. Un file Windows pieno di CRLF resta pieno di CRLF, un file Unix resta su LF, e un file con interruzioni miste esce con la stessa mescolanza con cui è arrivato. Cambiare le interruzioni di riga è una pagina diversa, ed è una cattiva idea avere una sola pagina che faccia in silenzio entrambe le cose.
Quali formati di sottotitoli possono ricevere un byte order mark?
Tutti e dodici che il sito gestisce: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON e CSV. Il segno riguarda i byte iniziali del file piuttosto che il formato dei sottotitoli, quindi non c’è nulla di specifico del formato da azzeccare: anche una trascrizione in testo semplice, che non ha alcuna linea temporale, può portarlo.