Hapus BOM dari subtitle
Atau tempel teks subtitle
Opsi
BOM adalah tiga byte di awal file yang menyatakan encoding yang dipakai. BOM tidak terlihat di editor dan pemutar mana pun, tidak memakan ruang di layar, dan tidak ada isi subtitle yang berubah ketika BOM ditambahkan atau dihapus. Dua jenis alat peduli terhadapnya: program Windows yang menulis subtitle, yang menambahkannya secara bawaan, dan parser ketat di pipeline build, yang menolak file yang diawali BOM. Halaman ini membuka kotak dalam keadaan yang disebut judulnya, sehingga Anda dapat membaliknya jika ternyata file Anda berada di keadaan sebaliknya. File UTF-16 selalu membawa BOM, karena itulah cara pembaca mengetahui urutan byte mana yang sedang dibacanya — meminta penghapusan di sana membiarkan BOM tetap ada.
Frame rate yang dipakai untuk menghitung waktu. Di halaman format, inilah yang dibutuhkan MicroDVD, karena format itu menyimpan waktu sebagai nomor frame. Di halaman frame rate, ini adalah laju yang dipakai saat file diberi waktu — versi tempat subtitle dibuat — dan kotak kedua di halaman tersebut menerima laju video yang akan Anda gunakan bersama subtitle ini. 23,976, 24, 25, 29,97, 30, 50, 59,94, dan 60 adalah nilai yang umum. Nilai yang salah akan menggeser seluruh timeline, dan di halaman frame rate pergeserannya berupa rasio, bukan jumlah tetap.
Byte order mark adalah satu karakter, U+FEFF, yang duduk di depan semua isi lain dalam file. Banyak alat menulisnya dan banyak alat tidak mengharapkannya, dan yang tidak mengharapkan menampilkannya sebagai blok simbol pendek yang menempel di awal cue pertama. Halaman ini menghapusnya dan membiarkan segala hal lain persis seperti saat ditemukan.
Menghapusnya paling penting ketika file berhenti menjadi sesuatu yang dibaca orang dan mulai menjadi sesuatu yang diurai program: pipeline build subtitle, skrip yang membaca baris pertama file, dan format yang spesifikasinya menyatakan byte pembuka adalah karakter pertama cue pertama. Itu juga penting ketika file digabung, karena tanda di tengah file gabungan adalah karakter di tengah cue. Dan penting untuk pengiriman: bila spesifikasi tujuan menyebut UTF-8 tanpa tanda, tanda adalah perbedaan yang akan ditemukan pemeriksa.
Yang tidak dilakukan halaman ini adalah memutuskan hal lain untuk Anda. Nomor cue, timecode, teks cue, dan akhir baris semuanya kembali seperti saat masuk, termasuk CRLF, dan file yang tidak punya tanda kembali byte demi byte alih-alih ditulis ulang menjadi sesuatu yang setara. Menghapus tanda tidak sama dengan mengubah encoding karakter file, dan keduanya sering dikacaukan: halaman ini mengubah karakter pertama file dan tidak mengubah cara sisa file di-encode.
Ada satu kasus ketika judul halaman ini dan kenyataannya tidak sejalan, dan itu perlu diketahui sebelum menjalankannya. File UTF-16 membutuhkan tandanya: tanpa tanda tidak ada cara membedakan dua urutan byte, sehingga file UTF-16 yang ditulis tanpa tanda tidak dapat dibaca kembali. Kirimkan file seperti itu melalui halaman ini dan file yang diunduh tetap membawa tanda, karena alternatifnya adalah file yang tidak bisa dibuka siapa pun. Kalau file Anda UTF-16 dan tandanya harus hilang, yang Anda butuhkan adalah encoding lain, bukan encoding yang sama tanpa tanda, dan halaman konversi encoding tertaut di bawah.
Tanda dihapus dari file yang Anda unduh, sehingga kedua panel di sini bisa tampak identik — karakter selebar nol memang tampak seperti karakter tak terlihat. Periksa hasilnya di indikator encoding editor atau di penampil heksadesimal: file tanpa tanda dimulai dengan byte pertama cue pertamanya. Kedua belas format yang ditangani situs ini diterima, dari SRT sampai transkrip teks biasa, dan tidak ada yang diunggah: file dibaca, diubah, dan ditulis di dalam peramban Anda.
Contoh
File bertanda, dengan tandanya diambil
Masukan
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Keluaran
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Masukan dimulai dengan U+FEFF dan keluaran tidak: kedua file berbeda tepat satu karakter itu, dan itulah seluruh operasi. File dalam keadaan ini biasanya keluar dari program subtitle Windows, dan alasan orang ingin tandanya hilang adalah langkah build atau parser ketat yang melihat byte pembuka alih-alih cue.
File Windows, tanda dihapus dan carriage return dipertahankan
Masukan
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Keluaran
1
00:00:01,000 --> 00:00:02,000
Marked and Windows.
Hanya tandanya yang hilang. Setiap carriage return milik file dan halaman ini tidak punya pendapat tentangnya — orang yang ingin keduanya berubah membutuhkan halaman akhir baris, dan memisahkan keduanya adalah yang membuat masing-masing aman dijalankan pada file yang belum Anda buka. Teks yang diharapkan tetap mempertahankan CRLF persis seperti masukan.
File tanpa tanda, kembali byte demi byte
Masukan
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Keluaran
1
00:00:01,000 --> 00:00:02,000
The room is dark.
Tidak ada yang perlu dihapus, jadi file kembali tanpa perubahan — termasuk tetap tanpa tanda. Inilah kasus yang menangkap implementasi yang menulis tanda lebih dulu lalu menghapusnya, atau yang menormalkan file dalam perjalanan: pembacaan jujur atas “tidak ada yang perlu dilakukan” adalah masukan itu sendiri, byte demi byte, bukan versi rapinya.
Pertanyaan yang sering diajukan
Bagaimana cara mengetahui apakah file subtitle saya punya byte order mark?
Buka di editor yang menampilkan encoding file; file UTF-8 bertanda biasanya diberi label UTF-8 with BOM atau UTF-8 BOM, bukan UTF-8 polos. Kalau tidak, lihat byte pertama di penampil heksadesimal: file yang dimulai dengan EF BB BF membawanya, dan yang dimulai dengan karakter pertama cue tidak. Blok simbol di awal baris pertama adalah hal yang sama yang dilihat program yang membaca tanda itu sebagai tiga karakter biasa.
Mengapa tanda tetap ada di file subtitle UTF-16 setelah dihapus?
Karena file UTF-16 membutuhkannya. UTF-16 menyimpan setiap karakter sebagai dua byte dan kedua urutan byte tampak sama dari luar, jadi tanda adalah yang memberi tahu pembaca urutan mana yang dipakai — file UTF-16 tanpa tanda tidak dapat dibaca kembali, oleh situs ini maupun yang lain. Halaman ini mempertahankannya karena alasan itu. Untuk mendapat file tanpa tanda sama sekali, ubah encoding-nya ke UTF-8 atau Windows-1252, tempat tanda bersifat opsional.
Apakah halaman ini merusak file subtitle yang tidak pernah punya tanda?
Tidak. Keluaran kasus itu adalah masukan, byte demi byte, dan tidak ada yang dilaporkan untuknya. Menjalankan halaman pada file yang keadaannya Anda ragukan aman secara konstruksi karena alasan yang sama: tanpa tanda tidak ada yang perlu ditulis, dan dengan tanda perubahannya sekecil mungkin. Proses yang tidak menemukan pekerjaan bukan proses yang melakukan sesuatu.
Bisakah satu file subtitle punya lebih dari satu byte order mark?
Bisa, dan itu terjadi setiap kali alat menambahkan tanda tanpa memeriksa apakah sudah ada — tanda kedua membuat file tampak normal sepenuhnya di editor padahal berbeda dari file normal pada byte pembukanya. Halaman ini menghapus semuanya, bukan satu, sehingga file bertanda ganda dibersihkan dalam satu kali jalan dan menjalankannya lagi tidak mengubah apa pun lebih jauh.
Apakah menghapus tanda mengubah encoding file subtitle saya?
Tidak dalam pengertian yang biasanya dimaksud orang. Teks file tetap karakter yang sama dan sisa file tetap di-encode dengan cara yang sama; yang berubah adalah pembaca tidak lagi memiliki byte pembuka yang memberi tahu encoding-nya. File UTF-8 tanpa tanda adalah UTF-8 biasa, yang memang diasumsikan sebagian besar alat. Mengubah encoding itu sendiri adalah halaman terpisah, tertaut dari sini.
Apakah tandanya akan kembali saat saya mengunduh file subtitle?
Tidak. Unduhan adalah titik file ditulis, dan proses halaman ini menulisnya tanpa tanda, jadi yang Anda dapat adalah yang dijelaskan kedua panel. Encoding tempat file ditulis dipertahankan dari cara membacanya, dengan satu pengecualian: file yang datang sebagai UTF-16 ditulis kembali sebagai UTF-16 dan mempertahankan tandanya, karena tanda itu struktural, bukan hiasan.