Hogyan fordítsunk le egy nagy TXT-fájlt: kódolás, fejezetek és sortörések
Javítsa a kódolást, jelölje meg a fejezeteket, és szüntesse meg a kemény sortöréseket, mielőtt lefordít egy hosszú .txt fájlt. Mintafájlokkal, ingyenes ellenőrzővel és egy 9 futásos teszttel.

Egy nagy TXT-fájl lefordításához három dolgot kell előkészítenie, mielőtt bárhová feltöltené. Először győződjön meg arról, hogy a szöveg megfelelően van dekódolva, és mentse el UTF-8-ként. Másodszor, minden fejezetcímet tegyen külön sorba, üres sorral körülvéve. Harmadszor, ha a fájl fix szélességnél tördel, fűzze össze ezeket a sorokat, hogy minden bekezdés egyetlen sor legyen, a bekezdések között pedig üres sor legyen. Ezután fordítsa le az egész fájlt, majd utána hasonlítsa össze a bekezdések és fejezetek számát a forrás és a fordítás között.
Egy egyszerű szöveges fájlnak nincsenek stílusai, nincsenek címsorai és nincs metaadata. Minden, amit egy fordítóeszköz a szerkezetéről tud, a bájtokból és a sortörésekből származik. Ezért jön vissza ugyanaz a három probléma: a bájtokat rossz kódolással olvassák be, a fejezeteket nem lehet megkülönböztetni a hétköznapi soroktól, vagy a sortörések semmit sem mondanak arról, hol végződik egy mondat.
Készítettünk mintafájlokat négy kódolásban, írtunk egy ingyenes ellenőrzőt, és egy keményen tördelt novellát kilenc alkalommal fordítottunk le egyszerűsített kínaira egy helyi modellel. A modell jól kezelte a kemény tördelést, amikor az egész fájlt látta. Mindhárom futásban, ahol a fájlt sorszám szerint darabokra vágták, elrontotta a mondatokat, és az egyik szereplő cselekvését egy másiknak tulajdonította.
Gyors ellenőrzőlista
| Ellenőrzés | Milyen a jó állapot | Hogyan javítsuk |
|---|---|---|
| Kódolás | Az első sorok helyesen olvashatók; a fájl UTF-8 | Nyissa meg újra a megfelelő kódolással, majd mentse UTF-8-ként |
| Bájt sorendjelző | Nincs, vagy olyan, amelyről tud | Mentse „UTF-8” néven, ne „UTF-8 BOM-mal” néven, ha egy eszköz panaszkodik |
| Fejezetcímek | Mindegyik külön sorban, üres sorral előtte és utána | Javítsa ki azt a néhány címsort, amely belefut a szövegbe |
| Bekezdések | Egy üres sor a bekezdések között | Adjon hozzá üres sorokat ott, ahol a bekezdések csak behúzással kezdődnek |
| Kemény tördelés | Minden bekezdés egyetlen hosszú sor | Fűzze össze a bekezdéseken belüli sorokat, de hagyja érintetlenül a verseket, leveleket és listákat |
| Soremzések | Végig egységes stílus | Alakítsa át a régi Mac CR végződéseket; a LF és a CRLF egyaránt megfelelő |
| Sérült szöveg | Nincsenek � karakterek | Szerezzen jobb példányt. Az átalakítás nem hozza vissza az elveszett karaktereket |
Az ellenőrző minden sorról jelentést ad, és kijavítja a kódolást, a bájtsorrend-jelölőt, a soremzéseket és a kemény tördelést. A fejezetcímeket és a hiányzó üres sorokat Önnek kell kézzel javítania. Futtassa a python3 check_txt.py inspect yourfile.txt parancsot a jelentés megtekintéséhez, és a python3 check_txt.py convert yourfile.txt clean.txt --unwrap parancsot egy UTF-8 másolat írásához, amelyben a bekezdések össze vannak vonva. Csak Python 3 szükséges hozzá, és soha nem módosítja az eredeti fájlt.
1. lépés: A kódolás helyes beállítása
A TXT fájl bájtok sorozata. A kódolás az a szabály, amely ezeket a bájtokat karakterekké alakítja, és a fájl nem mondja meg, melyik szabályt használták. Ha egy program rosszul tippel, mojibake-et kap: a szöveg összekavarodik, vagy ami még rosszabb, jól néz ki, de nem az, amit írtak.
Itt van ugyanaz a kínai kifejezés, 最后一班渡轮 ("az utolsó komp"), rossz szabállyal olvasva. Ezeket a Python beépített kodekjeivel állítottuk elő, és Ön is reprodukálhatja őket a mintafájlokkal.
| Mentve mint | Olvasva mint | Amit lát |
|---|---|---|
| GB18030 | Windows-1252 | ×îºóÒ»°à¶ÉÂÖ |
| GB18030 | UTF-8 | ���һ����� |
| UTF-8 | GBK | 鏈�鍚庝竴鐝�娓¤疆 |
| Shift_JIS (japán 最後のフェリー) | GBK | 嵟屻偺僼僃儕乕 |
Az utolsó sor a veszélyes. A japán bájtokat kínaiként olvasva valódi kínai karakterek keletkeznek, hiba és � nélkül. Egy fordítóeszköz boldogan lefordítja őket, és az eredmény jó nyelvtanú értelmetlenség lesz.
Ellenőrzőnk megmutatja, miért nem bízhat abban, hogy "hiba nélkül megnyílt". Amikor a Shift_JIS mintán futtattuk, két kódolás hibátlanul dekódolta az egész fájlt:
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 第一話 最後のフェリー
Csak a második sor japán. Az első ritka kínai karakterek sorozata, amelyet senki sem írt. A GB18030 kínai mintán öt kódolás dekódolt hiba nélkül, és közülük csak egy, a GB18030 mutatta a 第一章 最后一班渡轮 fejezetcímet. Tehát a szabály egyszerű: az első sorok elolvasásával döntse el a kódolást, ne abból, hogy egy program panaszkodott-e.
Ahol a tippelés általában félremegy:
- A régebbi Windows-rendszerekből vagy kínai oldalakról származó kínai szöveg gyakran GBK vagy GB18030. A GB18030 lefedi mindazt, amit a GBK, és a WHATWG Encoding Standard, amelyet a böngészők követnek, továbbmegy: azt mondja, hogy „a GBK dekódere a gb18030 dekódere.” Ha egy fájl GBK, GB18030-ként megnyitva működik.
- A hagyományos kínai Tajvanról vagy Hongkongból gyakran Big5.
- A japán gyakran Shift_JIS, vagy annak Microsoft által kiterjesztett változata, amelyet a Windows és a Python cp932 néven ismer.
- A koreai gyakran EUC-KR.
- Egy NUL bájtokkal teli fájl, vagy olyan, amelyben minden második karakter üresnek tűnik, általában UTF-16 byte order mark nélkül.
A byte order mark (BOM) egy rövid, láthatatlan kód a fájl elején, amely UTF-8-at, UTF-16-ot vagy UTF-32-t jelez. Ha van ilyen, higgyünk neki. Ugyanez a szabvány azt mondja, hogy „a byte order mark hitelesebb minden másnál.” Ellenőrzőnk először a BOM-ot olvassa, és csak akkor tippel, ha nincs.
Mentse a fájlt UTF-8-ként
Amint a szöveg helyesen olvasható, mentse UTF-8-ként. A WHATWG szabvány az UTF-8-at „a Unicode cseréjére legalkalmasabb kódolásnak” nevezi, és ez a legbiztonságosabb választás bármely fordítóeszköz számára.
Van egy második ok is, amely különösen a fordítás szempontjából fontos. A régi kódolások csak saját régiójuk karaktereit fedik le. A Shift_JIS-ben nincs kód a 这 karakterre, a 这是最后一班渡轮 első karakterére, és a Big5-ben sincs, mert ez egy egyszerűsített kínai karakter. A Windows-1252 nem tud cirill betűket tárolni. Ha a lefordított fájlt vissza kell írni az eredeti régi kódolásban, előfordulhat, hogy a célnyelv nem fér bele. A BookTranslator TXT-fordítója azt mondja, hogy automatikusan felismeri a gyakori kódolásokat, és a lefordított fájlt „ugyanazzal a kódolással, mint a bemenet” adja vissza, így az UTF-8-ból indulva a kérdés teljesen megszűnik.
Átalakíthat szövegszerkesztőben (nyissa meg a megfelelő kódolással, majd „Mentés másként” UTF-8-ként), macOS vagy Linux rendszeren a iconv -f GB18030 -t UTF-8 in.txt > out.txt paranccsal, vagy az ellenőrzővel:
python3 check_txt.py convert book.txt book-utf8.txt --encoding gb18030
Ha a fájl már tartalmaz � karaktereket, a kár azelőtt történt, hogy Önhöz került. Az újrakonvertálás nem állítja helyre a hiányzó karaktereket. Keressen jobb példányt a forrásból.
2. lépés: Tegye könnyen megtalálhatóvá a fejezeteket
A fejezetek három okból fontosak. Egy hosszú fájlt darabokban fordítanak le, és a fejezethatárok a legtisztább vágási pontok. Fordítás után ellenőrizni szeretné az egyes fejezeteket. És ha később e-könyvvé alakítja a szöveget, a fejezetcímekből lesz a tartalomjegyzék.
Tegyen minden címsort külön sorba, előtte és utána üres sorral, és használjon egyetlen mintát az egész könyvben. Ezeket a mintákat számolja ellenőrzőnk:
Chapter 1,Chapter One: The Last Ferry,Part Two,Prologue,Epilogue第一章,第12回,第三話,第二卷- egy szám vagy római szám egyedül egy sorban, például
12vagyXII.
Futtassa az inspect parancsot, és olvassa el a talált címsorok listáját. Ha a könyvnek 40 fejezete van, és az ellenőrző 37-et talál, három címsor rejtőzik: az egyik belefut az első mondatba, a másik más szót használ, például „Ch. 7”, a harmadiknak pedig szöveg van ugyanabban a sorban. Javítsa ki ezt a hármat kézzel. Ez kevesebb időbe telik, mint a problémát egy lefordított fájlban megtalálni.
3. lépés: Oldja fel a kemény sortöréseket, óvatosan
Egyes TXT-fájlok minden sort fix szélességnél törnek meg, hogy a szöveg elférjen egy egyszerű terminálban vagy egy keskeny ablakban. A PDF-ekből kimásolt szöveg és az OCR-kimenet ugyanezt teszi a nyomtatott oldal szélességénél. Ezekben a fájlokban a sortörés azt jelenti, hogy „a sor megtelt”, nem pedig azt, hogy „a mondat vagy bekezdés véget ért”.
A kemény tördelést könnyű észrevenni. Keményen tördelt mintánkban az ellenőrző ezt jelentette:
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
A megoldás az, hogy összevonjuk a sorokat minden bekezdésen belül, és megtartsuk az üres sorokat a bekezdések között. A csapda az olyan szöveg, amelynek sortörései valódiak: vers, dalszöveg, levelek, címek, receptek és listák. Mintánk tartalmaz egy ötsoros levelet:
My dear Mara,
The key is under the blue pot.
Do not let your uncle sell the boat.
With love, always,
Nonna
Egy nyers „cseréljünk ki minden egyes sortörést szóközre” művelet egyetlen összefolyó sorrá változtatja. Az ellenőrző --unwrap kapcsolója csak akkor vonja össze a bekezdést, ha a sorainak többsége megközelíti a teljes szélességet, így az ehhez hasonló rövid soros blokkokat, mint ez a levél, békén hagyja. Mintánkon pontosan, bájtra pontosan újjáépítette az eredeti, nem tördelt fájlt, a levelet is beleértve. A saját fájlján ellenőrizzen néhány összevont bekezdést és minden versblokkot, mielőtt megbízik benne.
Két további részlet. Amikor kínai vagy japán szöveg sorait vonja össze, ne tegyen közéjük szóközt; az ellenőrző a CJK sorokat, beleértve a CJK írásjelekkel végződő sorokat is, szóköz nélkül vonja össze. És ha a szöveg OCR-ből származik, a szavak a sorok végén kötőjelekkel is elválhatnak, ami külön döntéseket igényel. Az OCR sortörések és kötőjelezés javításáról szóló útmutatónk ezt tárgyalja.
Amit teszteltünk: keményen tördelt szöveg, egészben vs. feldarabolva
Szerettük volna megtudni, hogy a kemény sortörés valóban rontja-e a fordítást, vagy csak rendetlenül néz ki. Írtunk egy 396 szavas novellát a teszthez: három fejezet, tizenöt bekezdés, párbeszéd, a fenti levél és egy * * * jelenetváltás. Kétszer mentettük el ugyanazokkal a szavakkal: sortörés nélkül, bekezdésenként egy sorral, és 66 karakterenként keményen tördelve, amelyben 19 helyett 43 nem üres sor van.
Ezután megkértünk egy helyi modellt, hogy fordítsa le egyszerűsített kínaira háromféleképpen, mindegyiket háromszor:
- Tördelt, teljes fájl. A keményen tördelt fájl egyetlen kérésben.
- Tördeletlen, teljes fájl. A tördeletlen fájl egyetlen kérésben.
- Tördelt, 12 soronként vágva. A keményen tördelt fájl 12 soronként felosztva, darabonként egy kérés, a válaszok újra összefűzve. Ez történik, amikor egy szkript vagy eszköz bekezdések helyett sorszám szerint vág fel egy hosszú fájlt.
A modell a Qwen 3.6 27B (Q4_K_M) volt LM Studio-ban, gondolkodás kikapcsolva, hőmérséklet 0,3, egy Apple M4 Max 64 GB memóriával. Minden kérés ugyanazt az egymondatos utasítást használta. 2026. október 28-án futtattuk. A szkript a run_llm_txt_test.py, mind a kilenc kimenet szerkesztés nélkül jelent meg, a results.csv pedig futtatásonként egy sort tartalmaz.
| Tördelt, teljes fájl | Tördeletlen, teljes fájl | Tördelt, 12 soronként vágva | |
|---|---|---|---|
| Megtartott bekezdések (15) | 3/3 futtatás | 3/3 futtatás | 0/3 (mindig 14) |
| Megtartott fejezetcímek (3) | 3/3 | 3/3 | 3/3 |
| Levél öt sorként megtartva | 3/3 | 3/3 | 3/3 |
| Vágási pontnál elvágott mondatok | 0 | 0 | 3 minden futtatásban |
| Rossz szereplőnek adott cselekvés | 0 | 0 | 3 futásból 3 |
Az első eredmény meglepett minket. Amikor a modell látta a teljes, kemény tördelésű fájlt, maga fűzte össze a sorokat. Mindhárom kimenetben egy bekezdés volt soronként, ugyanaz a 19 sor, mint a tördelés nélküli futásokban, és ugyanolyan jól olvasható volt. Tehát a kemény tördelés önmagában nem ártott ennek a modellnek ezen a rövid fájlon.
A fájl sorszám szerinti felosztása viszont ártott, minden alkalommal ugyanazokon a helyeken. A 12 soros darabok közül három mondat közepén ért véget. Az első a „He pointed with his” szövegnél ér véget, a következő darab pedig a „pen at a three-storey building on the corner.” szöveggel kezdődik. Külön lefordítva a második fél elvesztette az alanyát. Két futásban 她瞥了一眼街角那栋三层楼的建筑, „she glanced at the three-storey building on the corner” lett belőle. A harmadikban 随后她重新回到填字游戏上, „then she went back to the crossword” lett a vége. A történetben a jegyárus férfi mutat, majd visszatér a keresztrejtvényéhez. Mindhárom futásban a kínai szöveg olvasója azt gondolná, hogy Mara tette.
A második vágás, a „the careful, slightly old-fashioned hand she had learned at a” és a „convent school” között, mindhárom futásban a 那是她在, „that was where she” szövegnél hagyta lógva a kínai mondatot (az egyik futásban egy felesleges 一 jelent meg), és a „learned” szó eltűnt. A harmadik vágás két sorra osztotta a redőnyökről szóló mondatot, és a második fél a „painted, not well, but not long ago” kifejezést lepattogzó festékké változtatta: 油漆虽已斑驳 két futásban és 油漆剥落 a harmadikban. És mivel a darabokat egyetlen sortöréssel fűzték össze, a jelenetváltás előtti üres sor eltűnt, ezért volt minden futásban 14 bekezdés 15 helyett. Az ellenőrzőnk elkapta a bekezdésszámot. A rossz karaktert nem tudta elkapatni; azt olvasással találtuk meg.
Mit jelent ez az Ön fájlja számára:
- A tördelés megszüntetése védelmet nyújt az Ön által nem irányított felosztókkal szemben. Minden hosszú fájlt valahol felosztanak, legyen az saját szkriptje, egy csevegőablak korlátja vagy az eszköz, amelyre feltölti. Ha a bekezdések egyetlen sorok, amelyeket üres sorok választanak el, bármely ésszerű felosztó bekezdések között tud vágni, nem pedig egy mondaton belül.
- A legrosszabb hibák gördülékenyek voltak. A „She glanced at the building” jó kínai. Az olvasó észrevenné a furcsa sortöréseket minden vágásnál és a lógó 那是她在 szöveget, de semmi sem jelöli hibaként a rossz karaktert vagy a lepattogzó festéket. A felosztási pontokon lévő hibák elsősorban jelentésbeli hibák, másodsorban formázási hibák.
- Ez egy modell és egy rövid történet volt. Egy ilyen rövid fájl elfér egyetlen kérésben, így a teljes fájlos futásoknak soha nem kellett felosztaniuk semmit. Egy teljes regényt viszont fel kell osztani, és pontosan ilyenkor térül meg az 1–3. lépésben végzett előkészítés. Ezek a fájlok az előkészítést és a felosztást tesztelik, nem a BookTranslator saját folyamatát.
Egy kisebb megfigyelés: a hat teljes fájlos futás során a modell Mara nevét ötször 玛拉, egyszer pedig 马拉 alakban írta. Minden kimenet önmagában konzisztens volt, de a különálló kérések nem egyeztek egymással. Egy sok darabban lefordított hosszú könyv esetében a nevek és azok egyeztetett írásmódjának listája minden fejezetet összhangban tart. A szószedet-útmutatónk megmutatja, hogyan készítsen egyet.
4. lépés: Fordítás, majd a számok ellenőrzése
Ha a fájl tiszta, a lefordítása a könnyű rész. Feltöltheti a BookTranslator TXT-fordítójába, amely .txt, .md és .mdx fájlokat fogad, azt állítja, hogy legfeljebb 300 MB-os TXT-fájlokat kezel, és a fizetés előtt megmutatja az árat. Nincs ingyenes teljes fordítás, de maga a feltöltés megmondja a költséget. Ha inkább csevegőmodellel vagy helyi LLM-mel szeretne dolgozni, ossza fel a fájlt fejezet- vagy bekezdéshatárokon, és vezessen szószedetet a nevekről. Ha a szövege Markdown, nem pedig egyszerű próza, nézze meg a Markdown-fordítási útmutatónkat, mert a Markdown szintaxisának saját szabályai vannak.
Fordítás után hasonlítsa össze a két fájlt:
python3 check_txt.py compare book-utf8.txt book-translated.txt
Ha bármelyik fájl nem UTF-8, adja hozzá a --source-encoding vagy a --translated-encoding kapcsolót. A fejezetellenőrzés ismeri az angol és a kínai/japán címsor-mintákat; más célnyelvek esetén adja hozzá a „fejezet” helyi megfelelőjét a szkript elején lévő mintához.
Ez a jelentés az egyik felvágott futásunkról:
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
Így olvassa:
- A bekezdéseknek és a fejezetcímeknek egyezniük kell. Egy hiányzó bekezdés gyakran azt jelenti, hogy kettőt összevontak, vagy egyet kihagytak.
- A nem üres sorok jó okból különbözhetnek. A teljes fájlos, tördelt futásaink 43 sorból 19 lettek, mert a modell összefűzte a keményen tördelt sorokat, ami javulás volt. Csak akkor hasonlítsa össze a sorokat, ha a forrás már eleve tördelés nélküli volt.
- A forrásírásból maradt karakterek olyan részekre utalnak, amelyeket egyáltalán nem fordítottak le. Néhány normális a nevek, terméknevek vagy idézetek esetében; egy sorozat belőlük kihagyott szakaszt jelez.
- A helyettesítő karakterek a fordításban kimeneti kódolási problémát jelentenek.
A számok nem mondják meg, hogy a fordítás helyes-e. Olvassa el minden fejezet első és utolsó bekezdését, valamint azokat a bekezdéseket, amelyek minden felosztási pont mindkét oldalán vannak. Itt találta a tesztünk az összes súlyos hibát.
Gyakran Ismételt Kérdések
Miért tűnik a TXT-fájlom az egyik programban rendben lévőnek, a másikban pedig zavarosnak?
A két program különböző kódolásokat talált ki. Az egyik helyesen. Keresse meg azt a kódolást, amely helyesen mutatja a szöveget, majd mentse a fájlt UTF-8-ként, hogy minden program ugyanúgy olvassa.
Átalakítsam a TXT-fájlt EPUB vagy DOCX formátumra fordítás előtt?
Csak akkor, ha szeretnéd, amit ezek a formátumok nyújtanak. Egy tiszta TXT-fájl, amelyben a fejezetek jól elkülönülnek, önmagában is jól fordítható. Ha szeretnél tartalomjegyzéket, fejezetnavigációt és egy e-könyvet, amelyet eszközön is olvashatsz, a webregény fordításhoz kész EPUB-ba alakításáról szóló útmutatónk végigvezet ezen.
Fordíthatok-e vegyes nyelvű TXT-fájlt?
Igen, de mondd meg a fordítónak, mit hagyjon érintetlenül. A harmadik nyelven szereplő idézeteket vagy kifejezéseket, valamint azokat a neveket, amelyeket eredeti írásmódjukban kell hagyni, könnyebb szószedettel vagy rövid utasítással megvédeni, mint utólag javítani.
Mi a helyzet egy weboldalról letöltött TXT-fájllal?
Ellenőrizd, hogy jogosult vagy-e a használatára. A közkincsnek számító könyvek vagy az általad írt fájlok esetében a fenti lépések érvényesek. Egy fájl kódolása vagy formátuma semmit sem árul el a szerzői jogi státuszáról.
Kapcsolódó bejegyzések





