Rimuovere il BOM dai 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.
Il byte order mark è un carattere, U+FEFF, che sta davanti a tutto il resto in un file. Parecchi strumenti lo scrivono e parecchi strumenti non se lo aspettano, e quelli che non se lo aspettano lo mostrano come un breve blocco di simboli incollato all’inizio del primo blocco. Questa pagina lo toglie e lascia tutto il resto esattamente come l’ha trovato.
Rimuoverlo conta soprattutto dove il file smette di essere qualcosa che una persona legge e comincia a essere qualcosa che un programma interpreta: pipeline di build dei sottotitoli, script che leggono la prima riga di un file, e formati la cui specifica dice che i byte iniziali sono il primo carattere del primo blocco. Conta anche quando i file vengono concatenati, perché un segno in mezzo a un file unito è un carattere in mezzo a un blocco. E conta per la consegna: se la specifica a cui consegnate dice UTF-8 senza segno, un segno è una differenza che il verificatore troverà.
Ciò che la pagina non farà è decidere qualcos’altro per voi. Numeri dei blocchi, timecode, testo dei blocchi e interruzioni di riga tornano come sono entrati, compresi i CRLF, e un file che non aveva alcun segno torna byte per byte invece di essere riscritto in qualcosa di equivalente. Rimuovere un segno non è la stessa cosa che cambiare la codifica dei caratteri di un file, e le due cose vengono spesso confuse: questa pagina cambia il primo carattere del file e nulla di come il resto è codificato.
C’è un caso in cui il titolo di questa pagina e ciò che accade davvero si separano, e vale la pena saperlo prima di eseguirla. Un file UTF-16 ha bisogno del suo segno: senza di esso non c’è modo di distinguere i due ordini di byte, quindi un file UTF-16 scritto senza segno non può essere riletto. Fatene passare uno da questa pagina e il file scaricato porterà ancora un segno, perché l’alternativa sarebbe un file che nessuno può aprire. Se il vostro file è UTF-16 e il segno deve sparire, ciò che volete è una codifica diversa invece della stessa senza segno, e la pagina che converte le codifiche è collegata più sotto. Il segno viene rimosso dal file che scaricate, quindi i due riquadri possono sembrare identici: un carattere a larghezza zero è esattamente ciò che sembra un carattere invisibile. Controllate il risultato nell’indicatore di codifica dell’editor o in un visualizzatore esadecimale: un file senza segno comincia con il primo byte del suo primo blocco. Tutti e dodici i formati gestiti dal sito sono accettati, dall’SRT a una trascrizione in testo semplice, e nulla viene caricato: il file viene letto, modificato e scritto nel browser.
Esempi
Un file marcato, con il segno tolto
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.
L’input comincia con U+FEFF e l’output no: i due file differiscono esattamente di quel carattere, che è l’intera operazione. I file in questo stato escono di solito da un programma di sottotitoli Windows, e la ragione per cui la gente vuole il segno via è un passo di build o un interprete severo che guarda i byte iniziali invece dei blocchi.
Un file Windows, segno rimosso e ritorni a capo conservati
Ingresso
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Uscita
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Se ne va solo il segno. Ogni ritorno a capo è quello del file e questa pagina non ha opinioni al riguardo: chi vuole cambiarli entrambi vuole la pagina delle interruzioni di riga, e tenere le due cose separate è ciò che rende ciascuna sicura da eseguire su un file che non avete aperto. Il testo atteso conserva i suoi CRLF esattamente come li aveva l’input.
Un file senza segno, restituito byte per byte
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.
Non c’era nulla da rimuovere, quindi il file torna invariato, compresa l’assenza di un segno. È il caso che smaschera un’implementazione che scrive prima un segno e lo toglie dopo, o che normalizza il file al passaggio: la lettura onesta di «non c’era nulla da fare» è l’input stesso, byte per byte, e non una sua versione ripulita.
Domande frequenti
Come faccio a sapere se il mio file di sottotitoli ha un byte order mark?
Apritelo in un editor che mostra la codifica del file, e un file UTF-8 con segno è di solito etichettato UTF-8 with BOM o UTF-8 BOM invece che semplicemente UTF-8. In mancanza di questo, guardate i primi byte in un visualizzatore esadecimale: un file che comincia con EF BB BF ne porta uno e uno che comincia con il primo carattere del blocco no. Il blocco di simboli all’inizio della prima riga è la stessa cosa vista da un programma che ha letto il segno come tre caratteri ordinari.
Perché il segno resta su un file UTF-16 dopo averlo rimosso?
Perché un file UTF-16 ne ha bisogno. UTF-16 memorizza ogni carattere come due byte e i due ordini di byte si somigliano dall’esterno, quindi il segno è ciò che dice a un lettore in quale ordine si trova: un file UTF-16 senza segno non può essere riletto, né da questo sito né da qualsiasi altra cosa. La pagina che state usando lo conserva per questa ragione. Per ottenere un file senza alcun segno, cambiate invece la sua codifica in UTF-8 o Windows-1252, dove il segno è facoltativo.
Questa pagina danneggia un file di sottotitoli che non ha mai avuto un segno?
No. L’output di quel caso è l’input, byte per byte, e non viene riportato nulla. Eseguire la pagina su un file di cui non siete certi dello stato è sicuro per costruzione per la stessa ragione: senza segno da rimuovere non c’è nulla da scrivere, e con un segno c’è la più piccola modifica possibile. Un’esecuzione che non ha trovato nulla da fare non è un’esecuzione che ha fatto qualcosa.
Un file di sottotitoli può avere più di un byte order mark?
Sì, e succede ogni volta che uno strumento aggiunge un segno senza prima controllare che ce ne sia uno: il secondo segno crea un file che sembra del tutto normale in un editor pur differendo da un file normale nei byte iniziali. Questa pagina li rimuove tutti invece di uno solo, quindi un file con doppio segno viene ripulito in una passata e rieseguire la pagina non cambia nulla ulteriormente.
Rimuovere un segno cambia la codifica del mio file di sottotitoli?
Non nel senso che la gente intende di solito. Il testo del file è ancora gli stessi caratteri e il resto è ancora codificato allo stesso modo; ciò che cambia è che un lettore non ha più i byte iniziali del file a dirgli la codifica. Un file UTF-8 senza segno è UTF-8 ordinario, che è ciò che la maggior parte degli strumenti suppone comunque. Cambiare la codifica stessa è una pagina separata, collegata da qui.
Il segno tornerà quando scarico il file di sottotitoli?
No. Lo scaricamento è il momento in cui il file viene scritto, e un’esecuzione di questa pagina lo scrive senza segno, quindi ciò che ottenete è ciò che i due riquadri descrivono. La codifica con cui un file viene scritto è conservata da come è stato letto, con un’eccezione: un file che arriva come UTF-16 viene riscritto come UTF-16 e conserva il suo segno, perché quel segno è strutturale invece che decorativo.