BookTranslator
BookTranslator

Как перевести большой TXT-файл: кодировка, главы и переносы строк

Исправьте кодировку, разметьте главы и уберите жёсткие переносы строк перед переводом длинного .txt-файла. С примерами файлов, бесплатной проверкой и тестом из 9 запусков.

BookTranslator

BookTranslator Team

15 мин чтения

Чтобы перевести большой TXT-файл, подготовьте три вещи, прежде чем загружать его куда-либо. Во-первых, убедитесь, что текст декодируется правильно, и сохраните его в UTF-8. Во-вторых, разместите каждый заголовок главы на отдельной строке, окружив его пустой строкой. В-третьих, если файл разбивает строки по фиксированной ширине, соедините эти строки так, чтобы каждый абзац занимал одну строку, а между абзацами была пустая строка. Затем переведите весь файл и после этого сравните количество абзацев и глав в исходнике и переводе.

В простом текстовом файле нет стилей, заголовков и метаданных. Всё, что инструмент перевода знает о его структуре, происходит из байтов и переносов строк. Вот почему постоянно возвращаются одни и те же три проблемы: байты читаются в неправильной кодировке, главы невозможно отличить от обычных строк, или переносы строк ничего не говорят о том, где заканчивается предложение.

Мы создали образцы файлов в четырёх кодировках, написали бесплатную программу проверки и девять раз перевели короткий рассказ с жёсткими переносами на упрощённый китайский с помощью локальной модели. Модель отлично справилась с жёсткими переносами, когда видела весь файл. Она разрывала предложения и приписывала действие одного персонажа другому во всех трёх запусках, где файл был разрезан на части по количеству строк.

Краткий чек-лист

ПроверкаКак должно выглядетьКак исправить
КодировкаПервые строки читаются правильно; файл в UTF-8Откройте заново с правильной кодировкой, затем сохраните как UTF-8
Метка порядка байтовОтсутствует или о ней известноСохраните как «UTF-8», а не «UTF-8 с BOM», если инструмент жалуется
Заголовки главКаждый на отдельной строке, с пустой строкой до и послеИсправьте те несколько заголовков, которые сливаются с текстом
АбзацыОдна пустая строка между абзацамиДобавьте пустые строки там, где абзацы начинаются только с отступа
Жёсткие переносыКаждый абзац — одна длинная строкаСоедините строки внутри абзацев, но не трогайте стихи, письма и списки
Окончания строкЕдиный стиль по всему файлуПреобразуйте старые окончания Mac CR; LF и CRLF подходят оба
Повреждённый текстНикаких символов �Найдите лучшую копию. Преобразование не вернёт потерянные символы

Скрипт проверки выводит отчёт по каждой строке и исправляет кодировку, метку порядка байтов, окончания строк и жёсткий перенос. Заголовки глав и пропущенные пустые строки придётся исправлять вручную. Запустите python3 check_txt.py inspect yourfile.txt, чтобы увидеть отчёт, и python3 check_txt.py convert yourfile.txt clean.txt --unwrap, чтобы записать копию в UTF-8 с объединёнными абзацами. Для работы нужен только Python 3, и исходный файл никогда не изменяется.

Шаг 1: Правильно определите кодировку

TXT-файл — это последовательность байтов. Кодировка — это правило, превращающее эти байты в символы, и в самом файле не сказано, какое правило использовалось. Если программа угадает неверно, вы получите кракозябры: искажённый текст или, что хуже, текст, который выглядит нормально, но не соответствует написанному.

Вот одна и та же китайская фраза 最后一班渡轮 («последний паром»), прочитанная с неправильным правилом. Мы сгенерировали эти примеры с помощью встроенных кодеков Python, и вы можете воспроизвести их с помощью образцов файлов.

Сохранено какПрочитано какЧто вы видите
GB18030Windows-1252×îºóÒ»°à¶ÉÂÖ
GB18030UTF-8���һ�����
UTF-8GBK鏈�鍚庝竴鐝�娓¤疆
Shift_JIS (японское 最後のフェリー)GBK嵟屻偺僼僃儕乕

Последняя строка — самая опасная. Японские байты, прочитанные как китайские, дают настоящие китайские иероглифы, без ошибок и без �. Инструмент перевода с радостью их переведёт, и результат будет бессмыслицей с хорошей грамматикой.

Наш скрипт проверки показывает, почему нельзя полагаться на «файл открылся без ошибок». Когда мы запустили его на образце 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, которому следуют браузеры, идёт дальше: в нём сказано, что «декодер 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 ГБ памяти. В каждом запросе использовался один и тот же промпт из одного предложения. Мы запускали тест 28 октября 2026 года. Скрипт — run_llm_txt_test.py, все девять выходных файлов опубликованы без правок, а в results.csv по одной строке на каждый прогон.

С переносами, весь файлБез переносов, весь файлС переносами, нарезка каждые 12 строк
Сохранено абзацев (15)3 из 3 прогонов3 из 3 прогонов0 из 3 (по 14 каждый раз)
Сохранено заголовков глав (3)3 из 33 из 33 из 3
Письмо сохранено как пять строк3 из 33 из 33 из 3
Предложений разрезано в месте разрыва003 в каждом прогоне
Действие приписано не тому персонажу003 из 3 прогонов

Первый результат нас удивил. Когда модель увидела весь файл с жёсткими переносами, она сама объединила строки. Во всех трёх вариантах получился один абзац на строку — те же 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 МБ и показывает цену до оплаты. Бесплатного полного перевода нет, но сама загрузка сообщает вам стоимость. Если вы предпочитаете работать с чат-моделью или локальной 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-файла, скачанного с веб-сайта?

Убедитесь, что у вас есть право на его использование. Для книг в общественном достоянии или файлов, написанных вами самими, подходят шаги, описанные выше. Кодировка или формат файла ничего не говорят о его авторских правах.

Похожие статьи