Как да преведете голям TXT файл: кодиране, глави и пренасяне на редове

За да преведете голям TXT файл, подгответе три неща, преди да го качите някъде. Първо, уверете се, че текстът е декодиран правилно и го запазете като UTF-8. Второ, поставете всяко заглавие на глава на отделен ред с празен ред около него. Трето, ако файлът разделя редовете на фиксирана ширина, съединете тези редове, така че всеки абзац да е един ред, с празен ред между абзаците. След това преведете целия файл и след това сравнете броя на абзаците и главите между източника и превода.

Обикновеният текстов файл няма стилове, няма заглавия и няма метаданни. Всичко, което инструментът за превод знае за структурата му, идва от байтовете и пренасянията на редове. Ето защо същите три проблема се появяват отново и отново: байтовете се четат в грешно кодиране, главите не могат да бъдат разграничени от обикновените редове или пренасянията на редове не казват нищо за това къде свършва изречението.

Направихме примерни файлове в четири кодирания, написахме безплатна проверка и преведохме трудно пренасян разказ на опростен китайски девет пъти с локален модел. Моделът се справи добре с твърдото пренасяне, когато видя целия файл. Той разкъса изречения и приписа действието на един герой на друг във всичките три пускания, където файлът беше нарязан на части по брой редове.

Бърза проверка

Проверяващият скрипт докладва за всеки ред и коригира кодирането, маркера за ред на байтовете, краищата на редовете и твърдото пренасяне. Заглавията на главите и липсващите празни редове трябва да поправите ръчно. Изпълнете python3 check_txt.py inspect yourfile.txt, за да видите отчета, и python3 check_txt.py convert yourfile.txt clean.txt --unwrap, за да запишете копие в UTF-8 с обединени параграфи. Нужен е само Python 3 и никога не променя оригиналния файл.

Стъпка 1: Настройте правилно кодирането

TXT файлът е последователност от байтове. Кодирането е правилото, което превръща тези байтове в символи, а файлът не казва кое правило е използвано. Ако програмата познае грешно, получавате мохибаке: текст, който е развален, или по-лошо – текст, който изглежда наред, но не е това, което е било написано.

Ето същата китайска фраза, 最后一班渡轮 („последният ферибот“), прочетена с грешното правило. Генерирахме тези примери с вградените кодекове на Python и можете да ги възпроизведете с примерните файлове.

Последният ред е опасният. Японски байтове, прочетени като китайски, произвеждат истински китайски символи, без грешка и без �. Инструмент за превод ще ги преведе с удоволствие, а резултатът ще бъде безсмислица с добра граматика.

Нашият проверяващ скрипт показва защо не можете да разчитате на „отвори се без грешки“. Когато го пуснахме върху примерния файл Shift_JIS, две кодировки декодираха целия файл без нито една грешка:

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    第一話　最後のフェリー

Само вторият ред е японски. Първият е низ от редки китайски символи, които никой не е писал. Върху китайския пример GB18030 пет кодировки се декодираха без грешки и само една от тях, GB18030, показа заглавието на главата 第一章 最后一班渡轮. Затова правилото е просто: определете кодирането, като прочетете първите редове, а не по това дали програмата се е оплакала.

Къде обикновено се объркват предположенията:

• Китайски текст от по-стари Windows системи или китайски сайтове често е в GBK или GB18030. GB18030 покрива всичко, което покрива GBK, а WHATWG Encoding Standard, който браузърите следват, отива по-далеч: там се казва, че „декодерът на GBK е декодерът на gb18030“. Ако файлът е в GBK, отварянето му като GB18030 работи.
• Традиционен китайски от Тайван или Хонконг често е в Big5.
• Японският често е в Shift_JIS или в разширената версия на Microsoft, която Windows и Python наричат cp932.
• Корейският често е в EUC-KR.
• Файл, пълен с NUL байтове, или такъв, в който всеки втори символ изглежда празен, обикновено е UTF-16 без маркер за ред на байтовете.

Маркерът за ред на байтовете (BOM) е кратък невидим код в началото на файла, който обявява UTF-8, UTF-16 или UTF-32. Когато има такъв, вярвайте му. Същият стандарт казва, че „маркерът за ред на байтовете е по-авторитетен от всичко останало“. Нашият инструмент за проверка първо чете BOM и предполага само когато няма такъв.

Запазете файла като UTF-8

След като текстът се чете правилно, запазете го като UTF-8. Стандартът WHATWG нарича UTF-8 „най-подходящото кодиране за обмен на Unicode“ и това е най-сигурният избор за всеки инструмент за превод.

Има и втора причина, която е особено важна за превода. Остарелите кодировки покриват само символите от собствения си регион. Shift_JIS няма код за 这, първия символ на 这是最后一班渡轮, и Big5 също няма код за него, защото това е опростен китайски символ. Windows-1252 не може да съхранява кирилица. Ако преведеният файл трябва да бъде записан обратно в оригиналното остаряло кодиране, целевият език може да не се побере. Преводачът на TXT на BookTranslator казва, че автоматично разпознава често срещаните кодировки и връща преведения файл „със същото кодиране като входния“, така че започването от UTF-8 премахва въпроса напълно.

Можете да конвертирате в текстов редактор (отворете с правилното кодиране, след което „Запазване като“ UTF-8), с iconv -f GB18030 -t UTF-8 in.txt > out.txt на macOS или Linux, или с инструмента за проверка:

python3 check_txt.py convert book.txt book-utf8.txt --encoding gb18030

Ако файлът вече съдържа символи �, повредата е станала преди да го получите. Повторното конвертиране няма да възстанови липсващите символи. Потърсете по-добро копие на източника.

Стъпка 2: Направете главите лесни за намиране

Главите са важни по три причини. Дългият файл се превежда на части, а границите на главите са най-чистите места за разделяне. Ще искате да проверите всяка глава след превода. И ако по-късно превърнете текста в електронна книга, заглавията на главите стават съдържание.

Поставете всяко заглавие на отделен ред, с празен ред преди и след него, и използвайте един и същ модел в цялата книга. Това са моделите, които нашият инструмент за проверка отчита:

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• число или римска цифра самостоятелно на ред, например 12 или XII.

Изпълнете inspect и прочетете списъка със заглавия, които е намерил. Ако книгата има 40 глави, а инструментът намери 37, три заглавия се крият: едно се слива с първото изречение, едно използва различна дума като „Гл. 7“, или едно има текст на същия ред. Поправете тези три ръчно. Това отнема по-малко време, отколкото намирането на проблема в преведен файл.

Стъпка 3: Премахнете твърдите нови редове внимателно

Някои TXT файлове разделят всеки ред на фиксирана ширина, така че текстът да се побира в обикновен терминал или тесен прозорец. Текстът, копиран от PDF файлове и изход от OCR, прави същото при ширината на печатната страница. В тези файлове новият ред означава „редът е пълен“, а не „изречението или абзацът е приключил“.

Твърдото пренасяне е лесно за забелязване. В нашия пример с твърдо пренасяне инструментът за проверка отчете:

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

Решението е да съедините редовете във всеки абзац и да запазите празните редове между абзаците. Капанът е текст, чиито нови редове са истински: стихове, текстове на песни, писма, адреси, рецепти и списъци. Нашият пример включва петредово писмо:

My dear Mara,
The key is under the blue pot.
Do not let your uncle sell the boat.
With love, always,
Nonna

Грубото „заменете всеки нов ред с интервал“ превръща това в един дълъг ред. Опцията --unwrap на инструмента за проверка съединява абзац само когато повечето му редове са близо до пълната ширина, така че блокове с къси редове като това писмо остават непокътнати. В нашия пример той възстанови оригиналния необвит файл точно, байт по байт, включително писмото. Във вашия собствен файл проверете няколко съединени абзаца и всеки блок стихове, преди да му се доверите.

Още две подробности. Когато съединявате редове от китайски или японски текст, не добавяйте интервал между тях; инструментът за проверка съединява CJK редове, включително редове, които завършват с CJK пунктуация, без интервал. И ако текстът ви идва от OCR, думите може също да са разделени с тирета в края на редовете, което изисква собствени решения. Нашето ръководство за поправяне на нови редове и пренасяне с тире от OCR покрива това.

Какво тествахме: Твърдо пренасят текст, цял срещу разрязан

Искахме да разберем дали твърдото пренасяне наистина вреди на превода, или само изглежда разхвърляно. Написахме разказ от 396 думи за теста: три глави, петнадесет абзаца, диалог, писмото по-горе и разделител на сцена * * *. Запазихме го два пъти с едни и същи думи: без пренасяне, с по един абзац на ред, и твърдо пренесен на 66 знака, който има 43 непразни реда вместо 19.

След това помолихме локален модел да го преведе на опростен китайски по три начина, по три пуска всеки:

1. С пренасяне, цял файл. Файлът с твърдо пренасяне в една заявка.
2. Без пренасяне, цял файл. Файлът без пренасяне в една заявка.
3. С пренасяне, разрязан на всеки 12 реда. Файлът с твърдо пренасяне, разделен на всеки 12 реда, по една заявка на част, а отговорите съединени обратно. Това се случва, когато скрипт или инструмент раздели дълъг файл по брой редове, а не по абзаци.

Моделът беше Qwen 3.6 27B (Q4_K_M) в LM Studio, с изключено мислене и температура 0.3, на Apple M4 Max с 64 GB памет. Всяка заявка използваше една и съща подкана от едно изречение. Пуснахме го на 28 октомври 2026 г. Скриптът е run_llm_txt_test.py, всичките девет резултата са публикувани без редакция, а results.csv има по един ред за всяко пускане.

Първата констатация ни изненада. Когато моделът видя целия файл с твърдо пренасяне, той сам съедини редовете. И трите изхода имаха по един абзац на ред, същите 19 реда като при пусковете без пренасяне, и се четяха също толкова добре. Значи твърдото пренасяне само по себе си не навреди на този модел върху този кратък файл.

Разрязването на файла по брой редове обаче навреди, и то на едни и същи места всеки път. Три от парчетата по 12 реда завършваха по средата на изречение. Първото завършва с „He pointed with his“, а следващото парче започва с „pen at a three-storey building on the corner.“ Преведена отделно, втората половина загуби подлога си. При два пуска се върна като 她瞥了一眼街角那栋三层楼的建筑, „тя погледна към триетажната сграда на ъгъла“. При третия завърши с 随后她重新回到填字游戏上, „после се върна към кръстословицата“. В историята мъжът в билетната будка сочи и се връща към кръстословицата си. И при трите пуска читател на китайски би помислил, че Мара го е направила.

Второто разрязване, между „the careful, slightly old-fashioned hand she had learned at a“ и „convent school“, остави китайското изречение да виси на 那是她在, „това беше мястото, където тя“, и при трите пуска (един пуск добави излишно 一), а думата „learned“ изчезна. Третото разрязване раздели изречението за капаците на два реда и втората половина превърна „painted, not well, but not long ago“ в олющена боя: 油漆虽已斑驳 при два пуска и 油漆剥落 при третия. И тъй като парчетата бяха съединени с един-единствен нов ред, празният ред преди разделителя на сцената изчезна, поради което всеки пуск имаше 14 абзаца вместо 15. Нашата проверка хвана броя на абзаците. Не можа да хване грешния герой; открихме го чрез четене.

Какво означава това за вашия файл:

• Премахването на пренасянето ви предпазва от разделящи инструменти, които не контролирате. Всеки дълъг файл се разделя някъде — било от собствения ви скрипт, от лимита на чат прозореца или от инструмента, в който качвате. Ако абзаците са единични редове, разделени с празни редове, всеки разумен разделител може да реже между абзаците, а не вътре в изречението.
• Най-лошите грешки бяха гладки. „Тя погледна към сградата“ е добър китайски. Читателят би забелязал странните нови редове при всяко разрязване и висящото 那是她在, но нищо не маркира грешния герой или олющената боя като грешки. Грешките в точките на разделяне са първо смислови, после форматни.
• Това беше един модел и един кратък разказ. Файл с такава дължина се побира в една заявка, така че пусковете с целия файл никога не са се налагало да разделят нищо. Един цял роман наистина трябва да се раздели и точно тогава подготовката от стъпки 1 до 3 се отплаща. Тези файлове тестват подготовката и разделянето, а не собствения конвейер на BookTranslator.

Едно по-малко наблюдение: при шестте пуска с целия файл моделът написа името на Мара като 玛拉 в пет и като 马拉 в един. Всеки изход беше последователен сам по себе си, но отделните заявки не се съгласуваха помежду си. За дълга книга, превеждана на много части, списък с имената и договорения им правопис държи всяка глава в съответствие. Нашето ръководство за речник показва как да създадете такъв.

Стъпка 4: Преведете, после проверете бройките

Когато файлът е чист, преводът е лесната част. Можете да го качите в TXT преводача на BookTranslator, който приема файлове .txt, .md и .mdx, според който се обработват TXT файлове до 300 MB, и показва цената преди плащане. Няма безплатен пълен превод, но самото качване ви казва колко ще струва. Ако предпочитате да работите с чат модел или локален LLM, разделете файла сами по границите на главите или абзаците и водете речник за имената. Ако текстът ви е Markdown, а не обикновена проза, вижте нашето ръководство за превод на Markdown, защото синтаксисът на Markdown има собствени правила.

След превода сравнете двата файла:

python3 check_txt.py compare book-utf8.txt book-translated.txt

Ако някой от файловете не е UTF-8, добавете --source-encoding или --translated-encoding. Проверката на главите разпознава английски и китайски/японски шаблони за заглавия; за други целеви езици добавете местната дума за „глава“ към шаблона в началото на скрипта.

Това е отчетът за един от нашите разрязани пускове:

                            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

Четете го така:

• Абзаците и заглавията на главите трябва да съвпадат. Липсващ абзац често означава, че два са слети или един е изпуснат.
• Непразните редове могат да се различават по основателна причина. Нашите пускове с пренасяне на целия файл минаха от 43 реда на 19, защото моделът съедини твърдо пренесените редове, което беше подобрение. Сравнявайте редове само когато източникът вече е бил без пренасяне.
• Останали знаци от изходната писменост сочат пасажи, които изобщо не са преведени. Няколко са нормални за имена, продуктови термини или цитати; поредица от тях е пропуснат раздел.
• Заместващи знаци в превода означават проблем с кодирането на изхода.

Бройките не могат да ви кажат дали преводът е правилен. Прочетете първия и последния абзац на всяка глава и абзаците от двете страни на всяко място, където файлът е бил разделен. Там нашият тест откри всяка сериозна грешка.

Често задавани въпроси

Защо моят TXT файл изглежда добре в една програма и развален в друга?

Двете програми са предположили различни кодировки. Едната е познала правилно. Намерете кодировката, при която текстът се показва правилно, и после запазете файла като UTF-8, за да го четат всички програми по един и същ начин.

Трябва ли да конвертирам TXT файл в EPUB или DOCX преди превод?

Само ако искате това, което тези формати добавят. Чист TXT файл с ясни глави се превежда добре и така. Ако искате съдържание, навигация по глави и електронна книга, която можете да четете на устройство, нашето ръководство за превръщане на уеб роман в EPUB, готов за превод описва целия процес.

Мога ли да преведа TXT файл със смесени езици?

Да, но кажете на преводача какво да не пипа. Цитати или термини на трети език и имена, които трябва да останат в оригиналната си писменост, се защитават по-лесно с глосар или кратка инструкция, отколкото да се поправят после.

А какво да кажем за TXT файл, който съм изтеглил от уебсайт?

Проверете дали имате право да го използвате. За книги в обществено достояние или файлове, които сами сте написали, стъпките по-горе са приложими. Кодирането или форматът на файла не ви казват нищо за авторските му права.