Correggere la codifica dei sottotitoli
Oppure incollare il testo dei sottotitoli
Opzioni
Questo cambia il modo in cui il file viene letto, non ciò che viene scritto. Normalmente la codifica si ricava dai primi byte: una BOM se c’è, UTF-8 se il file è UTF-8 valido, altrimenti Windows-1252. Così i file dell’Europa occidentale vengono letti bene e tutto il resto male: un file giapponese, cinese, coreano o cirillico arriva come una schermata di caratteri accentati senza senso. Indicando qui la codifica, la stima viene saltata. Rilevamento automatico è il valore predefinito e non fa nulla, ed è per questo che è sicuro lasciarlo stare. Nota che il risultato viene riscritto come UTF-8: i browser sanno produrre solo una manciata di codifiche, e nessuna di quelle in questo elenco è tra loro. È proprio il punto della pagina: il testo esce corretto e in una forma che ogni strumento sa leggere.
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.
Alcuni file di sottotitoli arrivano come una schermata di simboli che non appartengono ad alcuna lingua. Il file non è danneggiato e il testo non è sparito: il programma che lo legge ha applicato la regola sbagliata ai byte, e i caratteri usciti sono ciò che quei byte significano sotto una regola diversa. Questa pagina vi lascia dire quale regola usare, e la applica prima che accada qualsiasi altra cosa al file.
La ragione per cui deve essere una vostra scelta è che di solito i byte non lo dicono. Un programma che apre un file di sottotitoli indovina: un segno in testa risolve la questione, un UTF-8 valido la risolve, e altrimenti ricade su qualcosa — comunemente la codepage locale di chi esegue lo strumento invece di quella di chi ha scritto il file. I file di sottotitoli giapponesi, coreani e cinesi sono i casi in cui l’indovinello sbaglia più spesso, perché quelle codifiche erano il valore predefinito sulle macchine che li hanno prodotti e i loro byte non sono UTF-8 valido. Chi sa quale programma ha scritto il file ne sa più dell’indovino, ed è qui che quella conoscenza va messa.
Automatico è il valore predefinito e significa che l’indovinello gira esattamente come è sempre girato, quindi aprire questa pagina su un file che si legge già correttamente non cambia nulla. Scegliete una codifica specifica e il file viene letto in quel modo, prima che il sottotitolo venga interpretato: ecco perché questa pagina non ha un passo di «applica» separato nel senso abituale, e perché un file che si legge correttamente può uscire con gli stessi blocchi, gli stessi timecode e le stesse interruzioni di riga e un insieme di caratteri completamente diverso. Ciò che state scegliendo è la lettura, non una modifica.
Due cose sull’esito vale la pena saperle in anticipo, e la pagina le riporta entrambe. La prima è che una scelta sbagliata sembra una scelta sbagliata: i simboli cambiano in altri simboli invece che in testo, e provare non danneggia nulla. La seconda è un vero limite del browser: le codifiche che il browser sa leggere non le sa tutte scrivere. Un file riparato come Shift-JIS, GBK, Big5 o EUC-KR viene quindi riscritto come UTF-8, che si legge correttamente ovunque ed è ciò che gli strumenti moderni si aspettano, ma non è la codifica che avete nominato; se un sistema a valle insiste su quella originale, convertite il file con uno strumento desktop dopo averlo riparato qui. Una voce dell’elenco merita una parola propria: ISO-8859-1 e automatico raggiungono la stessa tabella di codice in un browser, perché lo standard dice che quell’etichetta significa quella dell’Europa occidentale, ma nominarla fa qualcosa che automatico non può: sovrascrive l’indovinello. Tutti e dodici i formati sono accettati, e nulla viene caricato: il file viene letto e scritto nel browser.
Esempi
Riconoscimento automatico su un file che si legge già bene
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.
L’impostazione predefinita, e l’unica che non chiede nulla: con automatico selezionato nessuna codifica viene nominata, quindi il file viene letto esattamente come prima che questa pagina esistesse. Questo la rende sicura da aprire su un file di cui non siete certi — se nulla era sbagliato, nulla accade — ed è l’impostazione su cui tornare quando una scelta specifica ha peggiorato le cose.
Lo stesso file letto come Shift-JIS
Ingresso
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Uscita
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Lo stesso file letto in due modi. Ciò che il riquadro contiene una volta che i byte sono stati letti come Shift-JIS è il giapponese che dicevano fin dall’inizio; letti come testo occidentale, quegli stessi byte sono una riga di lettere accentate senza relazione, ed è lo stato che manda la gente a cercare questa pagina. Entrambi i riquadri mostrano la versione leggibile, perché la rilettura avviene prima che il sottotitolo sia interpretato: non c’è un passo della pagina in cui i caratteri sbagliati siano sullo schermo e quelli giusti no.
Un file occidentale che il riconoscimento automatico legge come UTF-8
Ingresso
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Uscita
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Il caso difficile, e l’unico in cui automatico e una codifica nominata sono in disaccordo in un browser. I byte del file formano per caso una sequenza UTF-8 valida, quindi l’indovinello è UTF-8 e i caratteri consegnati non sono quelli del file. Nominare ISO-8859-1 forza invece la lettura dell’Europa occidentale. È la stessa tabella di codice in entrambi i casi, che è la parte facile da sbagliare leggendo documentazione vecchia: ciò che la scelta fa è sovrascrivere l’indovinello.
Domande frequenti
Perché il mio file di sottotitoli mostra caratteri strani invece del testo giusto?
Perché i byte sono stati letti sotto la regola sbagliata. Il file contiene testo giapponese, coreano o cirillico memorizzato nella codifica usata dal programma che l’ha scritto, e il programma che lo legge ha supposto qualcos’altro, molto spesso la codepage locale della macchina invece del file. Nulla è danneggiato: gli stessi byte sotto la regola giusta danno il testo giusto, che è ciò che fa nominare una codifica su questa pagina.
Come faccio a scoprire in quale codifica è davvero un file di sottotitoli?
Di solito da ciò che l’ha prodotto. Un file giapponese da uno strumento Windows giapponese è molto probabilmente Shift-JIS, uno cinese dalla Cina continentale è GBK e da Taiwan Big5, il coreano è EUC-KR, e il cirillico è Windows-1251 la maggior parte delle volte. In mancanza di questo, provatele: la scelta sbagliata dà simboli e quella giusta dà testo, quindi un file si identifica in pochi secondi senza sapere nulla di lui.
Che cosa succede se scelgo la codifica sbagliata per il mio file di sottotitoli?
I caratteri cambiano in un altro insieme di caratteri sbagliati, e non succede altro: il file originale sul disco è intatto, e nulla viene caricato o salvato da nessuna parte. Riprovare è gratis. L’unico esito da tenere d’occhio è un file che si legge correttamente ma mostra una riga di simboli sospettosamente lunga in cima, il che significa che porta anche un segno che la codifica scelta ha letto come caratteri.
Perché il mio file riparato viene scritto come UTF-8 quando ho scelto Shift-JIS?
Perché il browser sa leggere quella codifica ma non sa scriverla. Un file letto come Shift-JIS, GBK, Big5 o EUC-KR viene riscritto come UTF-8, che contiene ogni carattere che il file ha ed è ciò che quasi tutto il software attuale si aspetta. Il testo dei sottotitoli è esattamente quello che vedete nel riquadro; è cambiato solo il contenitore. Se un sistema a valle richiede la codifica originale, convertite il file riparato con uno strumento desktop.
Riparare la codifica modifica il testo dei miei sottotitoli?
No. I byte del file non vengono alterati, e nessun carattere viene aggiunto, rimosso o sostituito; ciò che cambia è la regola usata per trasformare quei byte in testo, e tutto ciò che viene dopo quel passo lavora con il testo corretto. I numeri dei blocchi, i timecode e le interruzioni di riga sono quelli del file, esattamente come su ogni altra pagina di operazioni di questo sito.
Il riconoscimento automatico è abbastanza buono, o dovrei impostare sempre la codifica?
Automatico è giusto per la grande maggioranza dei file, ed è il valore predefinito perché un file che si legge correttamente non dovrebbe richiedere che diciate nulla. Impostate la codifica quando il testo è visibilmente sbagliato, quando sapete che cosa ha prodotto il file, o quando un lotto proviene da un’unica fonte e va letto in un unico modo. Un caso in cui non aiuterà: un file in una codifica per cui il browser non ha alcun decodificatore, che resterà sbagliato qualunque opzione scegliate.