Büyük Bir TXT Dosyası Nasıl Çevrilir: Kodlama, Bölümler ve Satır Sonları
Uzun bir .txt dosyasını çevirmeden önce kodlamayı düzeltin, bölümleri işaretleyin ve sabit satır sonlarını birleştirin. Örnek dosyalar, ücretsiz bir denetleyici ve 9 çalıştırmalık bir testle birlikte.

Büyük bir TXT dosyasını çevirmek için herhangi bir yere yüklemeden önce üç şeyi hazırlayın. Birincisi, metnin doğru şekilde çözüldüğünden emin olun ve UTF-8 olarak kaydedin. İkincisi, her bölüm başlığını kendi satırına, etrafında boş bir satır olacak şekilde yerleştirin. Üçüncüsü, dosya sabit bir genişlikte satırlara bölünüyorsa, her paragraf tek satır olacak ve paragraflar arasında boş bir satır bulunacak şekilde bu satırları birleştirin. Ardından dosyanın tamamını çevirin ve sonrasında kaynak ile çeviri arasındaki paragraf ve bölüm sayılarını karşılaştırın.
Düz metin dosyasında stil, başlık ve üst veri yoktur. Bir çeviri aracının yapısı hakkında bildiği her şey baytlardan ve satır sonlarından gelir. Bu yüzden aynı üç sorun sürekli tekrar eder: baytlar yanlış kodlamayla okunur, bölümler sıradan satırlardan ayırt edilemez veya satır sonları bir cümlenin nerede bittiği hakkında hiçbir şey söylemez.
Dört kodlamada örnek dosyalar oluşturduk, ücretsiz bir denetleyici yazdık ve sabit satır sonlarıyla bölünmüş kısa bir öyküyü yerel bir modelle dokuz kez Basitleştirilmiş Çinceye çevirdik. Model, dosyanın tamamını gördüğünde sabit satır sonlarıyla sorunsuz başa çıktı. Dosyanın satır sayısına göre parçalara ayrıldığı üç çalıştırmada da cümleleri böldü ve bir karakterin eylemini başka bir karaktere atfetti.
Hızlı Kontrol Listesi
| Kontrol | İyi görünüm nasıl olur | Nasıl düzeltilir |
|---|---|---|
| Kodlama | İlk satırlar doğru okunuyor; dosya UTF-8 | Doğru kodlamayla yeniden açın, ardından UTF-8 olarak kaydedin |
| Bayt sırası işareti | Yok veya bildiğiniz bir tane var | Bir araç şikayet ederse "UTF-8 with BOM" yerine "UTF-8" olarak kaydedin |
| Bölüm başlıkları | Her biri tek başına bir satırda, öncesinde ve sonrasında boş satır | Metne karışan birkaç başlığı düzeltin |
| Paragraflar | Paragraflar arasında bir boş satır | Paragrafların yalnızca girintiyle başladığı yerlere boş satır ekleyin |
| Sabit satır sonları | Her paragraf tek uzun satır | Paragrafların içindeki satırları birleştirin, ancak şiir, mektup ve listeleri olduğu gibi bırakın |
| Satır sonları | Baştan sona tek stil | Eski Mac CR satır sonlarını dönüştürün; LF ve CRLF ikisi de uygundur |
| Bozuk metin | � karakteri olmamalı | Daha iyi bir kopya edinin. Dönüştürme, kaybolan karakterleri geri getiremez |
Denetleyici her satırı raporlar ve kodlamayı, bayt sırası işaretini, satır sonlarını ve sabit satır kaydırmayı düzeltir. Bölüm başlıkları ve eksik boş satırlar sizin elle düzeltmeniz gereken kısımlardır. Raporu görmek için python3 check_txt.py inspect yourfile.txt komutunu, paragrafları birleştirilmiş bir UTF-8 kopyası yazmak için python3 check_txt.py convert yourfile.txt clean.txt --unwrap komutunu çalıştırın. Yalnızca Python 3 gerektirir ve orijinal dosyayı asla değiştirmez.
1. Adım: Kodlamayı Doğru Ayarlayın
Bir TXT dosyası bayt dizisidir. Kodlama, bu baytları karakterlere dönüştüren kuraldır ve dosya hangi kuralın kullanıldığını söylemez. Bir program yanlış tahmin ederse mojibake ile karşılaşırsınız: bozuk metin ya da daha kötüsü, iyi görünen ama yazılanı yansıtmayan metin.
İşte aynı Çince ifade, 最后一班渡轮 ("son feribot"), yanlış kuralla okunduğunda. Bunları Python'un yerleşik kodekleriyle oluşturduk ve örnek dosyalarla yeniden üretebilirsiniz.
| Kaydedildiği kodlama | Okunduğu kodlama | Gördüğünüz |
|---|---|---|
| GB18030 | Windows-1252 | ×îºóÒ»°à¶ÉÂÖ |
| GB18030 | UTF-8 | ���һ����� |
| UTF-8 | GBK | 鏈�鍚庝竴鐝�娓¤疆 |
| Shift_JIS (Japonca 最後のフェリー) | GBK | 嵟屻偺僼僃儕乕 |
Tehlikeli olan son satırdır. Çince olarak okunan Japonca baytlar, hata vermeden ve � olmadan gerçek Çince karakterler üretir. Bir çeviri aracı bunları seve seve çevirir ve sonuç, dilbilgisi açısından düzgün ama anlamsız bir metin olur.
Denetleyicimiz, "hatasız açıldı" ifadesine neden güvenemeyeceğinizi gösteriyor. Shift_JIS örneğinde çalıştırdığımızda, iki kodlama tüm dosyayı tek bir hata bile vermeden çözdü:
encoding: unknown (not UTF-8)
these legacy encodings decode without errors; read the previews,
because a wrong one can still produce real-looking characters:
gb18030 戞堦榖丂嵟屻偺僼僃儕乕
cp932 第一話 最後のフェリー
Yalnızca ikinci satır Japoncadır. Birincisi, kimsenin yazmadığı nadir Çince karakterlerden oluşan bir dizedir. GB18030 Çince örneğinde, beş kodlama hatasız çözdü ve bunlardan yalnızca biri, GB18030, 第一章 最后一班渡轮 bölüm başlığını gösterdi. Yani kural basit: kodlamaya, bir programın şikayet edip etmediğine göre değil, ilk satırları okuyarak karar verin.
Tahminlerin genellikle yanlış gittiği yerler:
- Eski Windows sistemlerinden veya Çince sitelerden gelen Çince metinler genellikle GBK veya GB18030'dur. GB18030, GBK'nın kapsadığı her şeyi kapsar ve tarayıcıların uyduğu WHATWG Kodlama Standardı daha da ileri gider: "GBK'nın kod çözücüsü, gb18030'un kod çözücüsüdür" der. Bir dosya GBK ise, onu GB18030 olarak açmak işe yarar.
- Tayvan veya Hong Kong'dan gelen Geleneksel Çince genellikle Big5'tir.
- Japonca genellikle Shift_JIS veya Windows ve Python'un cp932 dediği Microsoft'un genişletilmiş sürümüdür.
- Korece genellikle EUC-KR'dir.
- NUL baytlarıyla dolu bir dosya veya her diğer karakterin boş göründüğü bir dosya genellikle bayt sırası işareti olmayan UTF-16'dır.
Bayt sırası işareti (BOM), bir dosyanın başında UTF-8, UTF-16 veya UTF-32'yi bildiren kısa, görünmez bir koddur. Bir BOM varsa ona güvenin. Aynı standart, "bayt sırası işaretinin diğer her şeyden daha yetkili olduğunu" söyler. Denetleyicimiz önce BOM'u okur ve yalnızca BOM yoksa tahmin eder.
Dosyayı UTF-8 olarak kaydedin
Metin doğru okunduğunda, onu UTF-8 olarak kaydedin. WHATWG standardı UTF-8'i "Unicode değişimi için en uygun kodlama" olarak adlandırır ve herhangi bir çeviri aracı için en güvenli seçimdir.
Özellikle çeviri için önemli olan ikinci bir neden daha var. Eski kodlamalar yalnızca kendi bölgelerinin karakterlerini kapsar. Shift_JIS'in 这是最后一班渡轮 ifadesinin ilk karakteri olan 这 için bir kodu yoktur ve Big5'in de yoktur çünkü bu bir Basitleştirilmiş Çince karakteridir. Windows-1252 Kiril alfabesini saklayamaz. Çevrilen dosyanın özgün eski kodlamayla geri yazılması gerekiyorsa, hedef dil sığmayabilir. BookTranslator'ın TXT çevirmeni yaygın kodlamaları otomatik algıladığını ve çevrilen dosyayı "girdiyle aynı kodlamada" döndürdüğünü söyler, bu nedenle UTF-8'den başlamak soruyu tamamen ortadan kaldırır.
Bir metin düzenleyicide (doğru kodlamayla açın, ardından "Farklı Kaydet" ile UTF-8 seçin), macOS veya Linux'ta iconv -f GB18030 -t UTF-8 in.txt > out.txt ile veya denetleyiciyle dönüştürebilirsiniz:
python3 check_txt.py convert book.txt book-utf8.txt --encoding gb18030
Dosya zaten � karakterleri içeriyorsa, hasar siz dosyayı almadan önce oluşmuştur. Yeniden dönüştürmek eksik karakterleri geri getirmez. Kaynağın daha iyi bir kopyasını arayın.
Adım 2: Bölümleri Kolay Bulunur Hale Getirin
Bölümler üç nedenden önemlidir. Uzun bir dosya parçalar halinde çevrilir ve bölüm sonları kesmek için en temiz yerlerdir. Çeviriden sonra her bölümü kontrol etmek isteyeceksiniz. Ve metni daha sonra bir e-kitaba dönüştürürseniz, bölüm başlıkları içindekiler tablosu haline gelir.
Her başlığı kendi satırına, öncesinde ve sonrasında boş bir satır olacak şekilde koyun ve kitap boyunca tek bir desen kullanın. Denetleyicimizin saydığı desenler şunlardır:
Chapter 1,Chapter One: The Last Ferry,Part Two,Prologue,Epilogue第一章,第12回,第三話,第二卷- bir satırda tek başına bir sayı veya Roma rakamı, örneğin
12veyaXII.
inspect komutunu çalıştırın ve bulduğu başlıkların listesini okuyun. Kitapta 40 bölüm varsa ve denetleyici 37 bulursa, üç başlık saklanıyordur: biri ilk cümleyle birleşmiştir, biri "Böl. 7" gibi farklı bir kelime kullanır veya birinin aynı satırda metni vardır. Bu üçünü elle düzeltin. Sorunu çevrilmiş bir dosyada bulmaktan daha az zaman alır.
Adım 3: Sabit Satır Sonlarını Dikkatlice Kaldırın
Bazı TXT dosyaları, metin düz bir terminale veya dar bir pencereye sığsın diye her satırı sabit bir genişlikte böler. PDF'lerden kopyalanan metinler ve OCR çıktıları da basılı sayfanın genişliğinde aynı şeyi yapar. Bu dosyalarda satır sonu "satır doldu" anlamına gelir, "cümle veya paragraf bitti" anlamına gelmez.
Sabit sarma kolayca fark edilir. Sabit sarılmış örneğimizde denetleyici şunu bildirdi:
non-empty lines: 43; longest line: 66 chars; 25 lines within 12 chars of the longest
line breaks inside paragraphs that do not end a sentence: 23
looks hard-wrapped: consider convert --unwrap
Çözüm, her paragrafın içindeki satırları birleştirmek ve paragraflar arasındaki boş satırları korumaktır. Tuzak, satır sonları gerçek olan metinlerdir: şiir, şarkı sözleri, mektuplar, adresler, tarifler ve listeler. Örneğimizde beş satırlık bir mektup var:
My dear Mara,
The key is under the blue pot.
Do not let your uncle sell the boat.
With love, always,
Nonna
Düz bir "her satır sonunu boşlukla değiştir" işlemi bunu tek bir bitişik satıra dönüştürür. Denetleyicinin --unwrap seçeneği yalnızca bir paragrafın satırlarının çoğu tam genişliğe yakınsa birleştirir, bu nedenle bu mektup gibi kısa satırlı bloklar olduğu gibi bırakılır. Örneğimizde orijinal sarılmamış dosyayı mektup dahil bayt bayt tam olarak yeniden oluşturdu. Kendi dosyanızda, güvenmeden önce birkaç birleştirilmiş paragrafı ve her şiir bloğunu kontrol edin.
İki ayrıntı daha. Çince veya Japonca metin satırlarını birleştirirken aralarına boşluk eklemeyin; denetleyici CJK satırlarını, CJK noktalama işaretiyle biten satırlar dahil, boşluksuz birleştirir. Ve metniniz OCR'dan geldiyse, kelimeler satır sonlarında kısa çizgiyle de bölünmüş olabilir, bu da kendi kararlarını gerektirir. OCR satır sonlarını ve kısa çizgiyle bölmeyi düzeltme rehberimiz bunu ele alır.
Neyi Test Ettik: Sabit Sarılmış Metin, Bütün vs. Parçalara Ayrılmış
Sert satır kaydırmanın çeviriyi gerçekten bozup bozmadığını yoksa sadece düzensiz mi göründüğünü bilmek istedik. Test için 396 kelimelik bir kısa öykü yazdık: üç bölüm, on beş paragraf, diyalog, yukarıdaki mektup ve bir * * * sahne arası. Aynı kelimelerle iki kez kaydettik: her satırda bir paragraf olacak şekilde kaydırılmamış ve 19 boş olmayan satır yerine 43 satır içeren 66 karakterde sert kaydırılmış.
Ardından yerel bir modelden bunu Basitleştirilmiş Çinceye üç farklı şekilde, her biri üç kez olmak üzere çevirmesini istedik:
- Kaydırılmış, tüm dosya. Sert kaydırılmış dosya tek bir istekte.
- Kaydırılmamış, tüm dosya. Kaydırılmamış dosya tek bir istekte.
- Kaydırılmış, her 12 satırda kesilmiş. Sert kaydırılmış dosya her 12 satırda bölünmüş, her parça için bir istek gönderilmiş ve yanıtlar yeniden birleştirilmiş. Bir betik veya aracın uzun bir dosyayı paragraf yerine satır sayısına göre böldüğünde olan budur.
Model, Apple M4 Max ve 64 GB bellekte, LM Studio içinde Qwen 3.6 27B (Q4_K_M) idi; düşünme kapalı ve sıcaklık 0.3 olarak ayarlanmıştı. Her istek aynı tek cümlelik istemi kullandı. Testi 28 Ekim 2026'da çalıştırdık. Betik run_llm_txt_test.py, dokuz çıktının tamamı düzenlenmeden yayımlandı ve results.csv her çalıştırma için bir satır içeriyor.
| Kaydırılmış, tüm dosya | Kaydırılmamış, tüm dosya | Kaydırılmış, her 12 satırda kesilmiş | |
|---|---|---|---|
| Korunan paragraflar (15) | 3 çalıştırmanın 3'ü | 3 çalıştırmanın 3'ü | 3'te 0 (her seferinde 14) |
| Korunan bölüm başlıkları (3) | 3'te 3 | 3'te 3 | 3'te 3 |
| Mektubun beş satır olarak korunması | 3'te 3 | 3'te 3 | 3'te 3 |
| Bölünme noktasında kesilen cümleler | 0 | 0 | Her çalıştırmada 3 |
| Yanlış karaktere verilen eylem | 0 | 0 | 3 / 3 çalıştırma |
İlk bulgu bizi şaşırttı. Model, sert satır sonlarıyla bölünmüş dosyanın tamamını gördüğünde satırları kendisi birleştirdi. Üç çıktının da her paragrafı tek satırdı, satır sonları kaldırılmış çalıştırmalardaki aynı 19 satırdı ve aynı derecede akıcı okunuyordu. Yani bu kısa dosyada sert satır sonları tek başına bu modele zarar vermedi.
Dosyayı satır sayısına göre kesmek ise her seferinde aynı yerlerde zarar verdi. 12 satırlık parçalardan üçü cümle ortasında bitiyordu. İlki "He pointed with his" ile bitiyor, sonraki parça "pen at a three-storey building on the corner." ile başlıyordu. Ayrı ayrı çevrildiğinde ikinci yarı öznesini kaybetti. İki çalıştırmada 她瞥了一眼街角那栋三层楼的建筑, "köşedeki üç katlı binaya bir göz attı" olarak geri döndü. Üçüncüsünde ise 随后她重新回到填字游戏上, "sonra bulmacaya geri döndü" ile bitti. Hikâyede bilet gişesindeki adam işaret edip bulmacasına geri döner. Üç çalıştırmanın hepsinde Çince okuyan biri bunu Mara'nın yaptığını düşünürdü.
İkinci kesim, "the careful, slightly old-fashioned hand she had learned at a" ile "convent school," arasında, Çince cümleyi üç çalıştırmanın hepsinde 那是她在, "orası onun olduğu yerdi" diye havada bıraktı (bir çalıştırma araya fazladan bir 一 ekledi) ve "learned" kelimesi kayboldu. Üçüncü kesim, panjurlarla ilgili cümleyi iki satıra böldü ve ikinci yarı "painted, not well, but not long ago" ifadesini dökülen boyaya çevirdi: iki çalıştırmada 油漆虽已斑驳, üçüncüsünde 油漆剥落. Parçalar tek satır sonuyla birleştirildiği için sahne geçişinden önceki boş satır da kayboldu; bu yüzden her çalıştırmada 15 yerine 14 paragraf vardı. Denetleyicimiz paragraf sayısını yakaladı. Yanlış karakteri yakalayamadı; onu okuyarak bulduk.
Bunun dosyanız için anlamı:
- Satır sonlarını kaldırmak sizi kontrol edemediğiniz bölücülerden korur. Her uzun dosya bir yerden bölünür; ister kendi betiğiniz, ister bir sohbet penceresinin sınırı, ister yüklediğiniz araç bölsün. Paragraflar boş satırlarla ayrılmış tek satırlarsa, makul herhangi bir bölücü cümle içinden değil paragraflar arasından kesebilir.
- En kötü hatalar akıcıydı. "Binanın üç katlı olduğunu fark etti" iyi Çincedir. Okuyucu her kesimdeki tuhaf satır sonlarını ve havada kalan 那是她在 ifadesini fark eder, ama yanlış karakteri ya da dökülen boyayı hata olarak işaretleyen hiçbir şey yoktur. Bölünme noktalarındaki hatalar önce anlam, sonra biçim hatalarıdır.
- Bu tek bir model ve tek bir kısa hikâyeydi. Bu kadar kısa bir dosya tek isteğe sığar, bu yüzden dosyanın tamamıyla yapılan çalıştırmalarda hiçbir şeyi bölmek gerekmedi. Tam bir romanın ise bölünmesi gerekir; işte Adım 1–3'teki hazırlık tam bu noktada karşılığını verir. Bu dosyalar hazırlığı ve bölmeyi test eder, BookTranslator'ın kendi işlem hattını değil.
Daha küçük bir gözlem: dosyanın tamamıyla yapılan altı çalıştırmanın beşinde model Mara'nın adını 玛拉, birinde 马拉 olarak yazdı. Her çıktı kendi içinde tutarlıydı, ama ayrı istekler birbiriyle uyuşmadı. Birçok parça hâlinde çevrilen uzun bir kitapta, adların ve üzerinde anlaşılmış yazımlarının bir listesi her bölümü hizada tutar. Sözlük rehberimiz böyle bir listenin nasıl oluşturulacağını gösterir.
Adım 4: Çevirin, Sonra Sayıları Kontrol Edin
Dosya temiz olduğunda çevirmek işin kolay kısmıdır. Dosyayı BookTranslator'ın TXT çeviricisine yükleyebilirsiniz; bu araç .txt, .md ve .mdx dosyalarını kabul eder, 300 MB'a kadar TXT dosyalarını işlediğini belirtir ve ödeme öncesinde fiyatı gösterir. Ücretsiz tam çeviri yoktur, ama yükleme işleminin kendisi size maliyeti söyler. Bir sohbet modeliyle ya da yerel bir LLM ile çalışmayı tercih ederseniz dosyayı bölüm veya paragraf sınırlarından kendiniz bölün ve adlar için bir sözlük tutun. Metniniz düz yazı yerine Markdown ise Markdown çeviri rehberimize bakın, çünkü Markdown sözdiziminin kendi kuralları vardır.
Çeviriden sonra iki dosyayı karşılaştırın:
python3 check_txt.py compare book-utf8.txt book-translated.txt
Dosyalardan biri UTF-8 değilse --source-encoding veya --translated-encoding ekleyin. Bölüm kontrolü İngilizce ve Çince/Japonca başlık kalıplarını bilir; diğer hedef diller için betiğin başındaki kalıba "bölüm" kelimesinin o dildeki karşılığını ekleyin.
Bu, parçalara ayırdığımız çalıştırmalardan birinin raporu:
source translated
paragraphs 15 14 <- differs
chapter headings 3 3
non-empty lines 43 24 <- differs
scene breaks (* * *) 1 1
replacement chars 0 0
source script LATIN characters left in translation: 0
Şöyle okuyun:
- Paragraflar ve bölüm başlıkları eşleşmelidir. Eksik bir paragraf genellikle iki paragrafın birleştirildiği ya da birinin düşürüldüğü anlamına gelir.
- Boş olmayan satırlar haklı bir nedenle farklı olabilir. Dosyanın tamamıyla yapılan sert satır sonlu çalıştırmalarımız 43 satırdan 19 satıra indi, çünkü model sert satır sonlarını birleştirdi ve bu bir iyileşmeydi. Satırları yalnızca kaynak zaten satır sonlarından arındırılmışsa karşılaştırın.
- Geriye kalan kaynak alfabe karakterleri hiç çevrilmemiş pasajlara işaret eder. Birkaç tanesi adlar, ürün terimleri veya alıntılar için normaldir; bir dizi hâlinde gelmeleri atlanmış bir bölüm demektir.
- Çevirideki değiştirme karakterleri çıkış yolunda bir kodlama sorunu olduğunu gösterir.
Sayılar çevirinin doğru olup olmadığını söyleyemez. Her bölümün ilk ve son paragrafını, ayrıca dosyanın bölündüğü her yerin iki yanındaki paragrafları okuyun. Testimizdeki her ciddi hatayı tam oralarda bulduk.
Sıkça Sorulan Sorular
TXT dosyam neden bir programda düzgün görünürken diğerinde bozuk görünüyor?
İki program farklı kodlamalar tahmin etti. Biri doğru tahmin etti. Metni doğru gösteren kodlamayı bulun, sonra dosyayı UTF-8 olarak kaydedin; böylece her program aynı şekilde okur.
Çevirmeden önce bir TXT dosyasını EPUB veya DOCX'e dönüştürmeli miyim?
Yalnızca bu formatların eklediklerini istiyorsanız. Net bölüm başlıklarına sahip temiz bir TXT dosyası olduğu gibi iyi çevrilir. İçindekiler tablosu, bölüm gezinmesi ve bir cihazda okuyabileceğiniz bir e-kitap istiyorsanız, bir web romanını çeviriye hazır EPUB'a dönüştürme rehberimiz bunu adım adım anlatır.
Karışık diller içeren bir TXT dosyasını çevirebilir miyim?
Evet, ancak çeviri aracına neleri olduğu gibi bırakması gerektiğini söyleyin. Üçüncü bir dildeki alıntılar veya terimler ile özgün yazı sisteminde kalması gereken adlar, sonradan düzeltmekten çok bir sözlük veya kısa bir talimatla korunması daha kolaydır.
Bir web sitesinden indirdiğim TXT dosyası ne olacak?
Kullanma hakkınız olduğundan emin olun. Kamu malı kitaplar veya kendi yazdığınız dosyalar için yukarıdaki adımlar geçerlidir. Bir dosyanın kodlaması veya formatı, telif hakkı hakkında size hiçbir şey söylemez.
İlgili Yazılar





