Altyazı kodlamasını düzelt
Ya da altyazı metnini yapıştırın
Seçenekler
Bu, yazılanı değil dosyanın nasıl okunduğunu değiştirir. Normalde kodlama ilk baytlardan çıkarılır: varsa bayt sırası işareti, dosya geçerli UTF-8 ise UTF-8, aksi hâlde Windows-1252. Bu, Batı Avrupa dosyalarını doğru, diğer her şeyi yanlış yapar; yani bir Japonca, Çince, Korece ya da Kiril dosya ekrana aksanlı anlamsız karakterler olarak gelir. Kodlamayı burada adlandırırsanız tahmin atlanır. Otomatik algıla varsayılandır ve hiçbir şey yapmaz, bu yüzden ona dokunmamak güvenlidir. Sonucun UTF-8 olarak yazıldığını unutmayın: tarayıcılar yalnızca birkaç kodlama üretebilir ve bu listedekilerin hiçbiri onların arasında değildir. Sayfanın amacı da bu — metin doğru ve her aracın okuyabileceği bir biçimde çıkar.
Zamanlamaların hangi kare hızında sayıldığı. Format sayfalarında MicroDVD’nin ihtiyaç duyduğu şey budur, çünkü zamanlamayı kare numarası olarak saklar. Kare hızı sayfalarında ise dosyanın hangi hıza göre zamanlandığı — altyazının hazırlandığı sürüm — ve sayfanın ikinci kutusu altyazıyı birlikte kullanacağınız videonun hızını alır. 23,976, 24, 25, 29,97, 30, 50, 59,94 ve 60 yaygın olanlardır. Yanlış vermek tüm zaman çizelgesini kaydırır; kare hızı sayfalarında ise sabit bir miktar yerine bir oran kadar kaydırır.
Bazı altyazı dosyaları hiçbir dile ait olmayan simgelerle dolu bir ekran olarak gelir. Dosya bozulmamıştır ve metin kaybolmamıştır: onu okuyan program baytlara yanlış kuralı uygulamıştır ve ortaya çıkan karakterler, o baytların başka bir kural altındaki anlamıdır. Bu sayfa hangi kuralın kullanılacağını söylemenizi sağlar ve dosyaya başka bir şey olmadan önce onu uygular.
Bunu sizin söylemeniz gerekir, çünkü baytlar genellikle söylemez. Bir altyazı dosyasını açan program tahmin eder: baştaki bir işaret işi bitirir, geçerli UTF-8 işi bitirir, aksi hâlde bir şeye geri düşer — genellikle dosyayı yazanın değil aracı çalıştıranın yerel kod sayfasına. Japonca, Korece ve Çince altyazı dosyaları tahminin en sık yanlış gittiği durumlardır, çünkü bu kodlamalar onları üreten makinelerin varsayılanıydı ve baytları geçerli UTF-8 değildir. Dosyayı hangi programın yazdığını bilen biri, tahmin ediciden daha fazlasını bilir ve bu bilginin gideceği yer burasıdır.
Otomatik varsayılandır ve tahminin her zamanki gibi çalışması anlamına gelir, bu yüzden bu sayfayı zaten doğru okunan bir dosyada açmak hiçbir şeyi değiştirmez. Belirli bir kodlama seçin ve dosya onun yerine öyle okunur, altyazı ayrıştırılmadan önce — bu sayfanın olağan anlamda ayrı bir uygula adımı olmamasının nedeni budur. Seçtiğiniz şey bir düzenleme değil, okumadır.
Sonuçla ilgili iki şeyi önceden bilmeye değer ve sayfa ikisini de bildirir. Birincisi, yanlış seçim yanlış seçim gibi görünür: simgeler metne değil başka simgelere dönüşür ve denemek hiçbir şeye zarar vermez. İkincisi tarayıcının gerçek bir sınırıdır: tarayıcı buradaki kodlamaların hepsini okuyabilir ama hepsini yazamaz. Shift-JIS, GBK, Big5 ya da EUC-KR olarak onarılan bir dosya bu yüzden UTF-8 olarak geri yazılır; her yerde doğru okunur ve çağdaş araçların beklediği budur, ama adını verdiğiniz kodlama değildir. Aşağı akıştaki bir sistem özgün olanı dayatıyorsa dosyayı burada onardıktan sonra masaüstü bir araçla dönüştürün.
Listedeki bir girdi kendi başına bir sözü hak eder. ISO-8859-1 ile otomatik, bir tarayıcıda aynı kod tablosuna varır, çünkü standart o etiketin Batı Avrupa tablosu anlamına geldiğini söyler. Yine de bulunmaya değer, çünkü otomatikin yapamadığı bir şeyi yapar: tahmini geçersiz kılar. Baytları geçerli bir UTF-8 dizisi oluşturan Batı Avrupa kökenli bir dosya otomatik olarak UTF-8 okunur ve gördüğünüz karakterler dosyadakiler değildir; ISO-8859-1 adını vermek Batı okumasını zorlar. On iki altyazı formatının hepsi kabul edilir ve hiçbir şey yüklenmez — dosya tarayıcınızın içinde okunur ve yazılır.
Örnekler
Zaten doğru okunan bir dosyada otomatik algılama
Girdi
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.
Çıktı
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.
Varsayılan ayar ve hiçbir şey istemeyen tek ayar: otomatik seçiliyken hiçbir kodlama adlandırılmaz, bu yüzden dosya bu sayfa var olmadan önceki hâliyle okunur. Bu da onu emin olmadığınız bir dosyada açmayı güvenli kılar — bir sorun yoksa hiçbir şey olmaz — ve belirli bir seçim işleri kötüleştirdiğinde geri dönülecek ayar budur.
Aynı dosya Shift-JIS olarak okunduğunda
Girdi
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Çıktı
1
00:00:01,000 --> 00:00:02,000
こんにちは、いい天気ですね。
Aynı dosya iki türlü okunuyor. Baytlar Shift-JIS olarak okunduktan sonra bölmenin tuttuğu şey, onların baştan beri söylediği Japoncadır; aynı baytlar Batı metni olarak okunduğunda ilgisiz aksanlı harflerden oluşan bir satırdır ve insanları bu sayfayı aramaya gönderen durum da budur. Bu örneğin iki bölmesi de okunabilir sürümü gösterir, çünkü yeniden okuma altyazı ayrıştırılmadan önce olur — sayfanın, yanlış karakterlerin ekranda olup doğruların olmadığı bir adımı yoktur.
Otomatik algılamanın UTF-8 olarak okuduğu Batılı bir dosya
Girdi
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Çıktı
1
00:00:01,000 --> 00:00:02,000
Café Ã la carte
Zor durum ve bir tarayıcıda otomatik ile adlandırılmış bir kodlamanın anlaşamadığı tek durum. Dosyanın baytları geçerli bir UTF-8 dizisi oluşturur, bu yüzden tahmin UTF-8 olur ve aktarılan karakterler dosyadakiler değildir. ISO-8859-1 adını vermek bunun yerine Batı Avrupa okumasını zorlar. Her iki durumda da aynı kod tablosu söz konusudur; eski belgelerden yanlış çıkarılması kolay olan kısım da budur: seçimin yaptığı şey tahmini geçersiz kılmaktır.
Sık sorulan sorular
Altyazı dosyam doğru metin yerine neden garip karakterler gösteriyor?
Çünkü baytlar yanlış kural altında okunmuştur. Dosya, onu yazan programın kullandığı kodlamada saklanmış Japonca, Korece ya da Kiril metni taşır ve onu okuyan program başka bir şey varsaymıştır — çoğu zaman dosyanın değil makinenin yerel kod sayfasını. Hiçbir şey bozulmamıştır: aynı baytlar doğru kural altında doğru metni verir ve bu sayfada bir kodlama adlandırmak da tam olarak bunu yapar.
Bir altyazı dosyasının gerçekte hangi kodlamada olduğunu nasıl bulurum?
Genellikle onu neyin ürettiğinden. Bir Japon Windows aracından çıkan Japonca dosya büyük olasılıkla Shift-JIS, anakaradan gelen Çince dosya GBK, Tayvan’dan gelen Big5, Korece EUC-KR ve Kiril çoğu zaman Windows-1251’dir. Bunlar yoksa deneyin: yanlış seçim simge verir, doğrusu metin verir, yani bir dosya hakkında hiçbir şey bilmeden birkaç saniyede tanımlanabilir.
Altyazı dosyam için yanlış kodlamayı seçersem ne olur?
Karakterler başka bir yanlış karakter kümesine dönüşür ve başka hiçbir şey olmaz — diskteki özgün dosyanız el sürülmemiş kalır ve hiçbir yere yüklenmez ya da kaydedilmez. Yeniden denemek bedavadır. Dikkat edilmesi gereken tek sonuç, doğru okunan ama tepesinde kuşkulu biçimde uzun bir simge satırı gösteren dosyadır; bu, dosyanın seçilen kodlamanın karakter olarak okuduğu bir işaret de taşıdığı anlamına gelir.
Shift-JIS seçtiğim hâlde onarılan altyazı dosyam neden UTF-8 yazılıyor?
Çünkü tarayıcı o kodlamayı okuyabilir ama yazamaz. Shift-JIS, GBK, Big5 ya da EUC-KR olarak okunan bir dosya UTF-8 olarak geri yazılır; UTF-8 içerdiği her karakteri taşır ve neredeyse bütün çağdaş yazılımların beklediği budur. Altyazı metni tam olarak bölmede gördüğünüzdür; değişen yalnızca kabıdır. Aşağı akıştaki bir sistem özgün kodlamayı istiyorsa onarılmış dosyayı masaüstü bir araçla dönüştürün.
Kodlamayı düzeltmek altyazılarımın metnini değiştirir mi?
Hayır. Dosyanızın baytları değiştirilmez ve hiçbir karakter eklenmez, kaldırılmaz ya da değiştirilmez; değişen, bu baytları metne çevirmek için kullanılan kuraldır ve o adımdan sonraki her şey doğru metinle çalışır. Replik numaraları, zaman kodları ve satır sonları dosyanın kendisine aittir, buradaki diğer bütün işlem sayfalarında olduğu gibi.
Otomatik kodlama algılama yeterli mi, yoksa her zaman kendim mi seçmeliyim?
Otomatik dosyaların büyük çoğunluğu için doğrudur ve varsayılandır, çünkü doğru okunan bir dosya sizin bir şey söylemenizi gerektirmemelidir. Metin gözle görülür biçimde yanlışsa, dosyayı neyin ürettiğini biliyorsanız ya da bir toplu işlem tek bir kaynaktan geldiyse kodlamayı siz seçin. Yardımcı olmayacağı bir durum var: tarayıcının hiç çözücüsü olmadığı bir kodlamadaki dosya, hangi seçeneği seçerseniz seçin yanlış kalır.