Video e sottotitoli · Toolkit sottotitoli
Perché é diventa é nei sottotitoli: codifiche dei testi e come i browser li decodificano
· Come funziona
sottotitoli codifica dei caratteri elaborazione del browser
Mojibake nei sottotitoli è quasi sempre una mancata corrispondenza della codifica. Questo post spiega come i byte diventano caratteri, perché UTF-8 e le code page di Windows legacy non sono d'accordo e come uno strumento basato su browser decodifica un file senza inviarlo da nessuna parte.
Gli accenti sono spazzatura ma il tempismo è perfetto: come si presentano i problemi di codifica
Il fatto è che tutto, tranne i personaggi, va bene. I tempi sono esatti, l'ordine dei segnali è corretto, il file viene caricato e solo le lettere accentate sono sbagliate. Questa combinazione esclude un errore strutturale, perché un parser che non potesse leggere il file non avrebbe prodotto i tempi corretti. Ciò che è andato storto è accaduto prima dell'analisi, quando una sequenza di byte è stata trasformata in una sequenza di caratteri.
Ciò spiega anche perché l’errore spesso si manifesta a metà del flusso di lavoro anziché alla fonte. Il file che sembrava corretto in un editor può sembrare sbagliato in quello successivo, senza che nulla lo abbia modificato. Niente lo ha modificato; il secondo programma presupponeva diversamente il significato dei byte.
Byte contro caratteri: perché gli stessi byte possono essere letti come 'é' o 'é' a seconda del decodificatore
Un file su disco è di byte. I caratteri esistono solo quando qualcosa applica una codifica, che è una tabella che mappa sequenze di byte in caratteri. UTF-8 rappresenta una lettera latina accentata come e-acute come due byte. Windows-1252 rappresenta la stessa lettera di un singolo byte e attribuisce ai due byte UTF-8 significati completamente diversi: il primo è una A maiuscola con tilde e il secondo è un segno di copyright.
Quindi la familiare coppia confusa non è corruzione. È una lettura fedele e senza perdite dei byte corretti nella tabella sbagliata. Ogni byte è sopravvissuto; è cambiata solo l'interpretazione. Questo è il motivo per cui il danno è solitamente reversibile e perché vale la pena identificare la direzione in cui è andata la mancata corrispondenza piuttosto che modificare manualmente i caratteri visibili.
UTF-8, Windows-1252 e amici: le codifiche dei file dei sottotitoli vengono effettivamente visualizzati
I file dei sottotitoli vengono visualizzati in un numero limitato di codifiche. UTF-8 è l'impostazione predefinita moderna e l'unica consentita da WebVTT. Windows-1252 è comune nei file prodotti dai vecchi strumenti dell'Europa occidentale e il suo parente stretto ISO-8859-1 copre gran parte dello stesso terreno. I file provenienti da fonti dell'Europa centrale, cirillica o greca vengono visualizzati nelle corrispondenti tabelle codici di Windows e il materiale dell'Asia orientale ne aggiunge molti altri.
Nessuna di queste codifiche registra la propria identità all'interno del file. Un file SRT non contiene alcuna dichiarazione della codifica utilizzata per scriverlo, che è la radice di tutto il problema: deve decidere il lettore e non c'è nulla di autorevole da leggere.
Il segno dell'ordine dei byte: un suggerimento utile per alcuni giocatori e un problema tecnico visibile per altri
Un contrassegno dell'ordine dei byte è l'unica eccezione parziale. È un carattere specifico all'inizio di un file che, quando presente, segnala la codifica. Aiuta alcuni giocatori e si presenta in altri come un personaggio randagio prima del primo indice dei sottotitoli, motivo per cui i file che ne contengono uno possono fallire esattamente in un programma e funzionare ovunque.
Il parser lo rimuove prima di fare qualsiasi altra cosa, perché un segno lasciato sul posto si attacca al primo numero di indice e costa la prima cue. Anche il rilevamento del formato è scritto per tollerarlo, quindi un file WebVTT che inizia con un segno prima dell'intestazione viene comunque riconosciuto come WebVTT anziché essere trattato come SRT.
Come un browser decodifica un file localmente: il TextDecoder API, e perché il rilevamento è un'ipotesi quando non viene dichiarata alcuna codifica
Quando lo strumento carica un file, chiama il metodo di testo File API e tale metodo viene specificato per essere decodificato come UTF-8. Non esiste alcun parametro di codifica e nessuna negoziazione. Un file che realmente è UTF-8 viene letto correttamente; un file Windows-1252 contenente una lettera accentata a byte singolo presenta un byte che non può iniziare una sequenza UTF-8 valida e il decodificatore sostituisce un carattere sostitutivo anziché indovinare.
Vale la pena saperlo perché cambia il sintomo. La lettura di un file UTF-8 con una tabella legacy produce il familiare errore di due caratteri. La lettura di un file legacy come UTF-8 produce invece caratteri sostitutivi, i diamanti neri o le caselle vuote. La decodifica come qualcosa di diverso da UTF-8 richiede di nominare esplicitamente la codifica tramite il decodificatore del browser API, e nominarla è la parte difficile: senza alcuna dichiarazione nel file, qualsiasi scelta automatica è un'inferenza dai modelli di byte, che è un'ipotesi che di solito è giusta e occasionalmente sbagliata.
Esempio realizzato: salvataggio di un file Windows-1252: identificazione della codifica sorgente e salvataggio successivo come UTF-8 prima della conversione
Per salvare un file legacy, esegui la conversione prima che i sottotitoli funzionino anziché dopo. Aprilo in un editor che ti permetta di indicare la codifica su entrambi i lati, digli di riaprire il file come Windows-1252 e conferma che i caratteri accentati vengano visualizzati correttamente. Se lo fanno, l'ipotesi era giusta. Quindi salva il file esplicitamente come UTF-8.
Verifica su una riga che puoi prevedere anziché sul file nel suo insieme. Scegli un segnale contenente un accento che sai dovrebbe essere presente e controllalo nell'output convertito. Fare questo prima significa che lo strumento sottotitoli riceve un file i cui byte corrispondono già alla codifica che assumerà e che la fase di conversione non ha più nulla da sbagliare.
Ciò non copre: file danneggiati da due cicli di conversione errata, in cui i byte originali sono già persi
Un file che ha subito due conversioni errate è un problema diverso. Se un file veniva letto erroneamente e poi salvato in quello stato di lettura errata, i caratteri errati venivano scritti come caratteri reali e i byte originali non esistevano più da nessuna parte al suo interno. A quel punto non c'è più nulla da reinterpretare, perché il file ora contiene veramente il testo confuso.
Questi casi sono talvolta risolvibili invertendo la sequenza esatta delle codifiche errate, ma solo quando ogni passaggio è noto e nessun passaggio ha perso informazioni. Un byte che è diventato un carattere sostitutivo scompare permanentemente: la sostituzione è un singolo carattere che sostituisce un byte che il decodificatore non può utilizzare e non registra quale fosse il byte. La soluzione affidabile è tornare al file originale.
Conclusione: standardizza su UTF-8 prima di convertire: come funziona Subtitle Toolkit sul tuo file nel browser e perché l'output WebVTT è UTF-8 per definizione
Standardizza su UTF-8 prima di convertire qualsiasi cosa. Il file stesso non contiene alcuna dichiarazione sulla sua codifica, quindi ogni programma che lo apre fa un'ipotesi e il modo per evitare che le ipotesi non siano d'accordo è renderle tutte corrette. WebVTT rimuove l'ambiguità per definizione, poiché il formato richiede UTF-8, che è un motivo pratico per convertire SRT in WebVTT per la distribuzione web.
La conversione viene eseguita sul file nella scheda del browser. Controlla il risultato su una riga di cui puoi prevedere gli accenti piuttosto che cercare qualcosa che sembra sbagliato, perché un file con una manciata di parole accentate in novecento battute è facile da approvare senza aver esaminato la parte che fallirebbe.