Tambahkan BOM ke 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. Dalam UTF-8 ia terdiri atas tiga byte, EF BB BF, dan menjadi hal pertama yang dilihat pembaca. Tidak ada yang tampak berbeda pada keluaran halaman ini: cue yang sama, timecode yang sama, akhir baris yang sama, dan satu tanda di depan semuanya.
Alasan orang menginginkannya adalah karena tanda itu menjadi cara file mengatakan “saya UTF-8” tanpa mengatakannya. Program yang membuka file subtitle harus menebak encoding-nya, dan banyak program — pemutar Windows lama, alat authoring cakram, skrip yang membaca baris pertama — memutuskan dengan melihat byte awal alih-alih mencoba mengurai seluruh file. Beri mereka tanda itu, dan nama beraksen, tanda kutip melengkung, atau huruf Yunani keluar sebagai dirinya sendiri. Tanpa tanda, file yang sama bisa dibaca sebagai codepage lokal sistem, tempat karakter itu berubah menjadi sesuatu yang sama sekali lain.
Arah sebaliknya justru yang biasanya ditemui orang lebih dulu: file bertanda dibuka oleh alat yang tidak mengharapkannya. Alat itu membaca tiga byte sebagai tiga karakter dan menampilkannya di awal baris pertama, dan di situlah asal blok simbol kecil di atas file subtitle seseorang. Kalau itu yang Anda lihat, halaman ini bukan yang tepat — tandanya perlu dihapus, bukan ditambahkan, dan halaman untuk itu tertaut di bawah.
Yang tidak dilakukan halaman ini adalah memformat ulang file dalam perjalanan. Ia tidak menyentuh akhir baris CRLF, nomor cue, timecode, atau teks cue mana pun, dan tidak memutuskan encoding file untuk Anda: file yang bukan UTF-8 adalah masalah lain, dan ada halaman untuk itu juga. Yang dilakukannya adalah menambahkan satu karakter di paling depan, dan bila karakternya sudah ada ia membiarkan file itu alih-alih menambahkan yang kedua, sehingga menjalankan halaman dua kali menghasilkan file yang sama dengan sekali.
Tanda ditambahkan pada file yang Anda unduh. Kedua panel di halaman ini karena itu bisa tampak identik — karakter tak terlihat memang tampak seperti karakter tak terlihat — dan cara jujur memeriksa hasilnya adalah melihat tiga byte pertama di penampil heksadesimal atau encoding file di bilah status editor Anda. Kedua belas format subtitle yang ditangani situs ini dapat membawa tanda, karena tanda adalah sifat byte pembuka file dan tidak tahu apa-apa tentang cue. Tidak ada yang diunggah pada titik mana pun: file dibaca, diubah, dan ditulis di dalam peramban Anda.
Contoh
File subtitle ASCII, dengan tanda di depan
Masukan
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.
Keluaran
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.
Teks yang diharapkan dimulai dengan karakter tak terlihat: U+FEFF, tiga byte EF BB BF, sebelum angka 1 pada nomor cue pertama. Kedua panel akan tampak sama bagi Anda dan itu bukan kesalahan render — perbedaan antara kedua file ini sepanjang tiga byte dan tidak satu pun punya bentuk. Unduh hasilnya dan buka di editor yang menampilkan encoding, atau lihat byte pertama di penampil heksadesimal, dan itu hal pertama yang Anda temukan.
File Windows, tanda ditambahkan dan carriage return dipertahankan
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.
Dua hal yang ditulis alat subtitle Windows adalah tanda dan akhir baris CRLF, sehingga keduanya sering dicampur — padahal terpisah, dan halaman ini hanya menulis yang pertama. Setiap carriage return di file hasil adalah milik masukan, dan tanda ditambahkan di depannya. Halaman yang ikut menulis ulang akhir baris akan diam-diam memformat ulang setiap file, tepat jenis perubahan yang tidak disadari sampai ada alat di hilir yang mempermasalahkannya.
File yang sudah membawa tanda
Masukan
1
00:00:01,000 --> 00:00:02,000
Already marked.
Keluaran
1
00:00:01,000 --> 00:00:02,000
Already marked.
Masukan sudah punya tanda, jadi keluarannya sama byte demi byte dengan masukan — file mempertahankan tepat satu tanda. Versi naif halaman ini, yang menempelkan tanda tanpa lebih dulu menghapus yang ada, menghasilkan file dengan dua tanda, dan tanda ganda tak terlihat di setiap editor padahal merupakan file berbeda bagi apa pun yang membaca byte pembuka. Menjalankan halaman pada file yang sudah bertanda seharusnya bisa dilakukan tanpa berpikir.
Pertanyaan yang sering diajukan
Apa yang sebenarnya diubah saat menambahkan byte order mark ke file subtitle?
Satu karakter di paling depan file: U+FEFF, ditulis sebagai tiga byte EF BB BF dalam UTF-8. Tidak ada cue yang ditambah, dihapus, atau disunting, tidak ada timecode yang bergerak, nomor cue dan akhir baris keluar seperti saat masuk, dan teks setiap baris tidak tersentuh. Bila Anda membandingkan kedua file, satu-satunya baris yang berbeda adalah baris pertama, dan perbedaannya tiga byte di awalnya.
Mengapa kedua panel di halaman BOM subtitle ini tampak identik?
Karena karakter yang ditambahkan tidak punya bentuk. U+FEFF adalah zero-width no-break space, jadi panel yang menampilkan teks seperti pemutar Anda menunjukkan hal yang sama sebelum dan sesudah. Perubahannya nyata dan berada di file yang Anda unduh: perbedaannya adalah tiga byte pertama. Indikator encoding di editor Anda, atau penampil heksadesimal yang menunjukkan EF BB BF di awal, adalah tempat mencarinya, bukan teksnya.
Apakah alat tambah BOM subtitle aman dijalankan dua kali pada file yang sama?
Ya. Halaman menghapus tanda apa pun yang sudah ada sebelum menulis tandanya sendiri, jadi file yang sudah bertanda kembali tanpa perubahan dan file yang belum bertanda mendapat tepat satu. Dua kali jalan menghasilkan file yang sama dengan sekali jalan. Artinya juga file yang pernah melewati halaman ini lalu melewati alat yang menambahkan tanda kedua dapat dibersihkan dengan menjalankannya sekali lagi, karena hanya satu yang bertahan.
Apakah tanda tetap ada bila saya mengonversi file subtitle ke format lain sesudahnya?
Tidak oleh halaman konversi di situs ini, yang menulis UTF-8 polos tanpa tanda, sehingga tanda yang ditambahkan di sini tidak terbawa melewati pergantian format. Urutkan pekerjaan sesuai itu: konversi lebih dulu, lalu tambahkan tanda sebagai langkah terakhir sebelum pengiriman. Itu juga urutan yang lebih masuk akal secara umum, karena tanda adalah sifat file jadi, bukan sifat isi subtitle.
Apakah menambahkan tanda ke file subtitle mengubah akhir barisnya?
Tidak. Tanda Latin-1 atau UTF-8 adalah satu karakter yang diletakkan sebelum byte pertama file dan tidak berpengaruh pada apa pun sesudahnya. File Windows penuh CRLF tetap penuh CRLF, file Unix tetap LF, dan file dengan akhir campuran keluar dengan campuran yang sama seperti saat datang. Mengubah akhir baris adalah halaman lain, dan merupakan ide buruk bila satu halaman diam-diam melakukan keduanya.
Format subtitle mana yang bisa diberi byte order mark?
Kedua belas yang ditangani situs ini: SRT, WebVTT, ASS, SSA, SBV, SAMI, LRC, MicroDVD, TTML, JSON, dan CSV. Tanda berkaitan dengan byte pembuka file, bukan dengan format subtitle, jadi tidak ada hal khusus format yang perlu diperhatikan — bahkan transkrip teks biasa, yang tidak punya timeline sama sekali, dapat membawanya.