Video & subtitle · Perangkat Subtitle
Mengapa é menjadi é dalam subtitle: pengkodean teks dan bagaimana browser mendekodekannya
· Cara kerjanya
subtitle pengkodean karakter pemrosesan browser
Mojibake dalam subtitle hampir selalu merupakan ketidakcocokan pengkodean. Posting ini menjelaskan bagaimana byte menjadi karakter, mengapa UTF-8 dan halaman kode Windows lama tidak setuju dan bagaimana alat berbasis browser mendekode file tanpa mengirimkannya ke mana pun.
Aksennya jelek tapi waktunya tepat — bagaimana masalah pengkodean muncul
Intinya adalah semuanya kecuali karakternya baik-baik saja. Pengaturan waktunya tepat, urutan isyarat benar, file dimuat, dan hanya huruf beraksen yang salah. Kombinasi tersebut mengesampingkan kesalahan struktural, karena parser yang tidak dapat membaca file tidak akan menghasilkan pengaturan waktu yang tepat. Apa yang salah terjadi sebelum penguraian, ketika jaringan byte diubah menjadi jaringan karakter.
Hal ini juga menjelaskan mengapa kesalahan sering kali muncul di tengah-tengah alur kerja, bukan di sumbernya. File yang terlihat benar di satu editor bisa terlihat salah di editor berikutnya, tanpa ada yang perlu dimodifikasi. Tidak ada yang mengubahnya; program kedua membuat asumsi berbeda tentang arti byte.
Byte versus karakter — mengapa byte yang sama dapat dibaca sebagai 'é' atau 'é' tergantung pada decodernya
File di disk adalah byte. Karakter hanya ada ketika sesuatu menerapkan pengkodean, yaitu tabel yang memetakan urutan byte ke karakter. UTF-8 mewakili huruf Latin beraksen seperti e-acute sebanyak dua byte. Windows-1252 mewakili huruf yang sama dengan satu byte, dan memberikan dua UTF-8 byte arti yang sangat berbeda: yang pertama adalah huruf kapital A dengan tanda gelombang dan yang kedua adalah tanda hak cipta.
Jadi pasangan kacau yang akrab ini bukanlah korupsi. Ini adalah pembacaan yang setia dan lossless dari byte yang benar di bawah tabel yang salah. Setiap byte bertahan; hanya penafsirannya saja yang berubah. Itulah sebabnya kerusakan biasanya dapat dibalik, dan mengapa penting untuk mengidentifikasi ke arah mana ketidakcocokan terjadi daripada mengedit sendiri karakter yang terlihat.
UTF-8, Windows-1252 dan teman-teman — file subtitle pengkodean benar-benar muncul di
File subtitle muncul dalam sejumlah kecil pengkodean. UTF-8 adalah default modern dan satu-satunya yang diizinkan WebVTT. Windows-1252 umum ditemukan pada file yang dihasilkan oleh alat Eropa Barat yang lebih tua, dan kerabat dekatnya ISO-8859-1 mencakup hampir semua hal yang sama. File dari sumber Eropa Tengah, Sirilik atau Yunani muncul di halaman kode Windows yang sesuai, dan materi Asia Timur menambahkan beberapa lagi.
Tak satu pun dari pengkodean ini mencatat identitas mereka sendiri di dalam file. File SRT tidak berisi deklarasi pengkodean yang digunakan untuk menulisnya, yang merupakan akar dari keseluruhan masalah: pembaca harus memutuskan, dan tidak ada yang otoritatif untuk dibaca.
Tanda urutan byte — petunjuk bermanfaat bagi beberapa pemain dan kesalahan yang terlihat pada pemain lain
Tanda urutan byte adalah satu-satunya pengecualian sebagian. Ini adalah karakter spesifik di awal file yang, jika ada, menandakan pengkodean. Ini membantu beberapa pemain dan muncul di pemain lain sebagai karakter tersesat sebelum indeks subtitle pertama, itulah sebabnya file yang membawa seseorang bisa gagal di satu program dan berfungsi di tempat lain.
Pengurai menghapusnya sebelum melakukan hal lain, karena tanda yang tertinggal di tempatnya akan menempel pada nomor indeks pertama dan memerlukan isyarat pertama. Deteksi format ditulis untuk menoleransinya juga, sehingga file WebVTT yang dimulai dengan tanda sebelum headernya masih dikenali sebagai WebVTT daripada diperlakukan sebagai SRT.
Bagaimana browser mendekode file secara lokal — TextDecoder API, dan mengapa deteksi hanya berupa tebakan ketika tidak ada pengkodean yang dideklarasikan
Saat alat memuat file, ia memanggil metode teks File API, dan metode tersebut ditentukan untuk didekode sebagai UTF-8. Tidak ada parameter pengkodean dan tidak ada negosiasi. File yang benar-benar UTF-8 dibaca dengan benar; file Windows-1252 yang berisi huruf beraksen byte tunggal menampilkan byte yang tidak dapat memulai urutan UTF-8 yang valid, dan decoder mengganti karakter pengganti daripada menebak.
Hal ini perlu diketahui karena dapat mengubah gejalanya. Membaca file UTF-8 dengan tabel lama menghasilkan kekacauan dua karakter yang sudah dikenal. Membaca file lama sebagai UTF-8 menghasilkan karakter pengganti, berlian hitam atau kotak kosong. Penguraian kode sebagai sesuatu selain UTF-8 memerlukan penamaan pengkodean secara eksplisit melalui dekoder browser API, dan penamaan itu adalah bagian yang sulit: tanpa deklarasi dalam file, pilihan otomatis apa pun adalah kesimpulan dari pola byte, yang merupakan tebakan yang biasanya benar dan terkadang salah.
Contoh praktis: menyelamatkan file Windows-1252 — mengidentifikasi pengkodean sumber dan menyimpannya kembali sebagai UTF-8 sebelum konversi
Untuk menyelamatkan file lama, lakukan konversi sebelum subtitle berfungsi, bukan setelahnya. Buka di editor yang memungkinkan Anda menyatakan pengkodean di kedua sisi, perintahkan untuk membuka kembali file sebagai Windows-1252, dan konfirmasikan karakter beraksen muncul dengan benar. Jika ya, maka tebakannya benar. Kemudian simpan file secara eksplisit sebagai UTF-8.
Verifikasi pada baris yang dapat Anda prediksi, bukan pada file secara keseluruhan. Pilih isyarat yang berisi aksen yang Anda tahu seharusnya ada di sana dan periksa di keluaran yang dikonversi. Melakukan hal ini terlebih dahulu berarti alat subtitle menerima file yang byte-nya sudah sesuai dengan pengkodean yang akan diasumsikan, dan langkah konversi tidak ada lagi kesalahan.
Apa yang tidak tercakup dalam hal ini — file rusak akibat dua putaran konversi yang salah, sehingga byte aslinya telah hilang
File yang telah melalui dua konversi yang salah adalah masalah yang berbeda. Jika file salah dibaca dan kemudian disimpan dalam status salah baca tersebut, karakter yang salah akan ditulis sebagai karakter asli, dan byte asli tidak lagi ada di mana pun di dalamnya. Pada titik ini tidak ada yang perlu diinterpretasikan ulang, karena file tersebut sekarang benar-benar berisi teks yang kacau.
Kasus-kasus tersebut kadang-kadang dapat dipulihkan dengan membalikkan urutan pengkodean yang salah, tetapi hanya jika setiap langkah diketahui dan tidak ada langkah yang kehilangan informasi. Sebuah byte yang menjadi karakter pengganti hilang secara permanen: penggantinya adalah satu karakter yang menggantikan satu byte yang tidak dapat digunakan oleh decoder, dan tidak mencatat berapa byte tersebut. Perbaikan yang dapat diandalkan adalah kembali ke file asli.
Kesimpulan: lakukan standarisasi pada UTF-8 sebelum Anda mengonversi — cara kerja Perangkat Subtitle pada file Anda di browser dan mengapa keluaran WebVTT menurut definisi adalah UTF-8
Standarisasi pada UTF-8 sebelum mengonversi apa pun. File itu sendiri tidak membawa pernyataan pengkodeannya, jadi setiap program yang membukanya membuat asumsi, dan cara untuk menghentikan asumsi yang tidak sesuai adalah dengan membuat semuanya benar. WebVTT menghilangkan ambiguitas berdasarkan definisi, karena formatnya memerlukan UTF-8, yang merupakan salah satu alasan praktis untuk mengonversi SRT ke WebVTT untuk pengiriman web.
Konversi berjalan pada file di tab browser. Periksa hasilnya pada baris yang aksennya dapat Anda prediksi daripada memindai apa pun yang terlihat salah, karena file dengan beberapa kata beraksen dalam sembilan ratus isyarat mudah untuk ditandatangani tanpa memeriksa bagian yang akan gagal.