Jak przetłumaczyć duży plik TXT: kodowanie, rozdziały i podziały wierszy

Aby przetłumaczyć duży plik TXT, przygotuj trzy rzeczy, zanim prześlesz go w dowolne miejsce. Po pierwsze, upewnij się, że tekst jest poprawnie zdekodowany, i zapisz go jako UTF-8. Po drugie, umieść każdy nagłówek rozdziału w osobnym wierszu, otoczony pustymi wierszami. Po trzecie, jeśli plik łamie wiersze na stałej szerokości, połącz te wiersze tak, aby każdy akapit był jednym wierszem, z pustym wierszem między akapitami. Następnie przetłumacz cały plik, a potem porównaj liczbę akapitów i rozdziałów w źródle i w tłumaczeniu.

Plik tekstowy nie ma stylów, nagłówków ani metadanych. Wszystko, co narzędzie tłumaczeniowe wie o jego strukturze, pochodzi z bajtów i podziałów wierszy. Dlatego wciąż powracają te same trzy problemy: bajty są odczytywane w niewłaściwym kodowaniu, rozdziałów nie da się odróżnić od zwykłych wierszy albo podziały wierszy nie mówią nic o tym, gdzie kończy się zdanie.

Przygotowaliśmy pliki przykładowe w czterech kodowaniach, napisaliśmy darmowe narzędzie sprawdzające i przetłumaczyliśmy twardo łamane opowiadanie na uproszczony chiński dziewięć razy za pomocą lokalnego modelu. Model dobrze radził sobie z twardym łamaniem, gdy widział cały plik. Łamał zdania i przypisywał działanie jednej postaci innej we wszystkich trzech przebiegach, w których plik został pocięty według liczby wierszy.

Szybka lista kontrolna

Narzędzie sprawdzające raportuje o każdym wierszu i poprawia kodowanie, znacznik kolejności bajtów, końce wierszy i twarde zawijanie. Nagłówki rozdziałów i brakujące puste wiersze musisz poprawić ręcznie. Uruchom python3 check_txt.py inspect yourfile.txt, aby zobaczyć raport, oraz python3 check_txt.py convert yourfile.txt clean.txt --unwrap, aby zapisać kopię w UTF-8 z połączonymi akapitami. Wymaga tylko Pythona 3 i nigdy nie zmienia oryginalnego pliku.

Krok 1: Ustaw prawidłowe kodowanie

Plik TXT to sekwencja bajtów. Kodowanie to reguła, która zamienia te bajty na znaki, a plik nie mówi, która reguła została użyta. Jeśli program zgadnie źle, otrzymasz mojibake: tekst zniekształcony lub, co gorsza, tekst, który wygląda dobrze, ale nie jest tym, co zostało zapisane.

Oto ta sama chińska fraza, 最后一班渡轮 („ostatni prom”), odczytana złą regułą. Wygenerowaliśmy je za pomocą wbudowanych kodeków Pythona, a Ty możesz je odtworzyć za pomocą plików przykładowych.

Ostatni wiersz jest niebezpieczny. Japońskie bajty odczytane jako chińskie dają prawdziwe chińskie znaki, bez błędu i bez �. Narzędzie do tłumaczenia z przyjemnością je przetłumaczy, a wynik będzie nonsensem z poprawną gramatyką.

Nasze narzędzie sprawdzające pokazuje, dlaczego nie można polegać na „otworzyło się bez błędów”. Gdy uruchomiliśmy je na próbce Shift_JIS, dwa kodowania zdekodowały cały plik bez ani jednego błędu:

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

Tylko drugi wiersz jest japoński. Pierwszy to ciąg rzadkich chińskich znaków, których nikt nie napisał. Na chińskiej próbce GB18030 pięć kodowań zdekodowało plik bez błędów, a tylko jedno z nich, GB18030, pokazało nagłówek rozdziału 第一章 最后一班渡轮. Zasada jest więc prosta: ustal kodowanie, czytając pierwsze wiersze, a nie na podstawie tego, czy program zgłosił błąd.

Gdzie zwykle zawodzą domysły:

• Tekst chiński ze starszych systemów Windows lub chińskich witryn jest często w GBK lub GB18030. GB18030 obejmuje wszystko, co GBK, a WHATWG Encoding Standard, którego przestrzegają przeglądarki, idzie dalej: mówi, że „dekoder GBK jest dekoderem gb18030”. Jeśli plik jest w GBK, otwarcie go jako GB18030 zadziała.
• Chiński tradycyjny z Tajwanu lub Hongkongu jest często w Big5.
• Japoński jest często w Shift_JIS lub w rozszerzonej wersji Microsoftu, którą Windows i Python nazywają cp932.
• Koreański jest często w EUC-KR.
• Plik pełen bajtów NUL lub taki, w którym co drugi znak wygląda na pusty, to zwykle UTF-16 bez znacznika kolejności bajtów.

Znacznik kolejności bajtów (BOM) to krótki, niewidoczny kod na początku pliku, który informuje o UTF-8, UTF-16 lub UTF-32. Gdy jest obecny, należy mu zaufać. Ten sam standard mówi, że „znacznik kolejności bajtów ma większy autorytet niż cokolwiek innego”. Nasz checker najpierw odczytuje BOM i zgaduje tylko wtedy, gdy go nie ma.

Zapisz plik jako UTF-8

Gdy tekst wyświetla się poprawnie, zapisz go jako UTF-8. Standard WHATWG nazywa UTF-8 „najodpowiedniejszym kodowaniem do wymiany Unicode” i jest to najbezpieczniejszy wybór dla każdego narzędzia tłumaczeniowego.

Istnieje drugi powód, który ma szczególne znaczenie dla tłumaczenia. Starsze kodowania obejmują tylko znaki swojego regionu. Shift_JIS nie ma kodu dla 这, pierwszego znaku 这是最后一班渡轮, a Big5 również go nie ma, ponieważ jest to znak chiński uproszczony. Windows-1252 nie może przechowywać cyrylicy. Jeśli przetłumaczony plik ma zostać zapisany z powrotem w oryginalnym starszym kodowaniu, język docelowy może się nie zmieścić. Tłumacz TXT BookTranslatora automatycznie wykrywa popularne kodowania i zwraca przetłumaczony plik „z tym samym kodowaniem co wejściowy”, więc rozpoczęcie od UTF-8 całkowicie usuwa ten problem.

Możesz przekonwertować w edytorze tekstu (otwórz z właściwym kodowaniem, a następnie „Zapisz jako” UTF-8), za pomocą iconv -f GB18030 -t UTF-8 in.txt > out.txt w macOS lub Linuxie, albo za pomocą checkera:

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

Jeśli plik zawiera już znaki �, uszkodzenie nastąpiło przed jego otrzymaniem. Ponowna konwersja nie przywróci brakujących znaków. Poszukaj lepszej kopii źródła.

Krok 2: Ułatw odnajdywanie rozdziałów

Rozdziały mają znaczenie z trzech powodów. Długi plik jest tłumaczony w częściach, a podziały rozdziałów to najczystsze miejsca cięcia. Po tłumaczeniu będziesz chciał sprawdzić każdy rozdział. A jeśli później zamienisz tekst w ebooka, nagłówki rozdziałów staną się spisem treści.

Umieść każdy nagłówek w osobnym wierszu, z pustym wierszem przed i po nim, i używaj jednego wzorca w całej książce. Oto wzorce, które liczy nasz checker:

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• liczba lub cyfra rzymska samotnie w wierszu, np. 12 lub XII.

Uruchom inspect i przeczytaj listę znalezionych nagłówków. Jeśli książka ma 40 rozdziałów, a checker znajduje 37, trzy nagłówki się ukrywają: jeden zlewa się z pierwszym zdaniem, jeden używa innego słowa, np. „Rozdz. 7”, albo jeden ma tekst w tym samym wierszu. Popraw te trzy ręcznie. Zajmie to mniej czasu niż szukanie problemu w przetłumaczonym pliku.

Krok 3: Ostrożnie usuwaj twarde podziały wierszy

Niektóre pliki TXT łamią każdy wiersz na stałej szerokości, aby tekst mieścił się w zwykłym terminalu lub wąskim oknie. Tekst skopiowany z plików PDF i wynik OCR robią to samo na szerokości drukowanej strony. W takich plikach podział wiersza oznacza „wiersz był pełny”, a nie „zdanie lub akapit się zakończył”.

Twarde zawijanie łatwo zauważyć. W naszym próbnym pliku z twardym zawijaniem checker zgłosił:

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

Poprawka polega na połączeniu wierszy w obrębie każdego akapitu i zachowaniu pustych wierszy między akapitami. Pułapką jest tekst, którego podziały wierszy są prawdziwe: wiersze, teksty piosenek, listy, adresy, przepisy i listy. Nasz próbny plik zawiera pięciowierszowy list:

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

Bezmyślne „zamień każdy pojedynczy podział wiersza na spację” zamienia to w jeden ciągły wiersz. Opcja --unwrap checkera łączy akapit tylko wtedy, gdy większość jego wierszy jest bliska pełnej szerokości, więc bloki krótkich wierszy, takie jak ten list, pozostają nietknięte. W naszym próbnym pliku odtworzył oryginalny plik bez zawijania dokładnie, bajt po bajcie, łącznie z listem. W swoim pliku sprawdź kilka połączonych akapitów i każdy blok wierszy, zanim mu zaufasz.

Jeszcze dwa szczegóły. Podczas łączenia wierszy tekstu chińskiego lub japońskiego nie dodawaj między nimi spacji; checker łączy wiersze CJK, w tym wiersze kończące się interpunkcją CJK, bez spacji. A jeśli tekst pochodzi z OCR, słowa mogą być również dzielone myślnikami na końcach wierszy, co wymaga własnych decyzji. Nasz przewodnik po naprawianiu podziałów wierszy i dzielenia wyrazów w OCR omawia ten temat.

Co testowaliśmy: tekst z twardym zawijaniem, całość vs. pocięty

Chcieliśmy sprawdzić, czy twarde zawijanie wierszy faktycznie szkodzi tłumaczeniu, czy tylko wygląda niechlujnie. Napisaliśmy na potrzeby testu opowiadanie liczące 396 słów: trzy rozdziały, piętnaście akapitów, dialogi, powyższy list oraz przejście sceniczne oznaczone * * *. Zapisaliśmy je dwukrotnie z tymi samymi słowami: bez zawijania, z jednym akapitem w wierszu, oraz z twardym zawijaniem przy 66 znakach, który ma 43 niepuste wiersze zamiast 19.

Następnie poprosiliśmy lokalny model o przetłumaczenie go na uproszczony chiński na trzy sposoby, po trzy przebiegi każdym:

1. Z zawijaniem, cały plik. Plik z twardym zawijaniem w jednym żądaniu.
2. Bez zawijania, cały plik. Plik bez zawijania w jednym żądaniu.
3. Z zawijaniem, cięty co 12 wierszy. Plik z twardym zawijaniem podzielony co 12 wierszy, jedno żądanie na fragment, odpowiedzi połączone z powrotem. Tak dzieje się, gdy skrypt lub narzędzie dzieli długi plik według liczby wierszy, a nie według akapitów.

Modelem był Qwen 3.6 27B (Q4_K_M) w LM Studio, z wyłączonym myśleniem i temperaturą 0,3, na Apple M4 Max z 64 GB pamięci. Każde żądanie używało tego samego jednodaniowego promptu. Uruchomiliśmy go 28 października 2026 r. Skrypt to run_llm_txt_test.py, wszystkie dziewięć wyników opublikowano bez edycji, a results.csv zawiera jeden wiersz na przebieg.

Pierwsze odkrycie nas zaskoczyło. Gdy model zobaczył cały plik z twardym zawijaniem, sam połączył wiersze. Wszystkie trzy wyniki miały jeden akapit na wiersz, te same 19 wierszy co w uruchomieniach bez zawijania, i czytały się równie dobrze. Zatem samo twarde zawijanie nie zaszkodziło temu modelowi w tym krótkim pliku.

Cięcie pliku według liczby wierszy zaszkodziło, i to w tych samych miejscach za każdym razem. Trzy z 12-wierszowych fragmentów kończyły się w środku zdania. Pierwszy kończy się na „He pointed with his”, a następny fragment zaczyna się od „pen at a three-storey building on the corner”. Przetłumaczona osobno, druga połowa straciła podmiot. W dwóch uruchomieniach wróciła jako 她瞥了一眼街角那栋三层楼的建筑, „spojrzała na trzypiętrowy budynek na rogu”. W trzecim zakończyła się na 随后她重新回到填字游戏上, „potem wróciła do krzyżówki”. W opowieści mężczyzna w budce biletowej wskazuje i wraca do swojej krzyżówki. We wszystkich trzech uruchomieniach czytelnik chińskiego pomyślałby, że zrobiła to Mara.

Drugie cięcie, między „the careful, slightly old-fashioned hand she had learned at a” a „convent school”, pozostawiło chińskie zdanie zawieszone na 那是她在, „to było tam, gdzie ona”, we wszystkich trzech uruchomieniach (jedno uruchomienie dodało zbłąkane 一), a słowo „learned” zniknęło. Trzecie cięcie rozdzieliło zdanie o okiennicach na dwa wiersze, a druga połowa zamieniła „painted, not well, but not long ago” w łuszczącą się farbę: 油漆虽已斑驳 w dwóch uruchomieniach i 油漆剥落 w trzecim. A ponieważ fragmenty zostały połączone pojedynczym znakiem nowego wiersza, pusta linia przed przerwą sceniczną zniknęła, dlatego każde uruchomienie miało 14 akapitów zamiast 15. Nasz program sprawdzający wychwycił liczbę akapitów. Nie mógł wychwycić błędnej postaci; znaleźliśmy to, czytając.

Co to oznacza dla Twojego pliku:

• Rozwijanie wierszy chroni Cię przed dzielnikami, których nie kontrolujesz. Każdy długi plik jest gdzieś dzielony, czy to przez Twój własny skrypt, limit okna czatu, czy narzędzie, do którego go wgrywasz. Jeśli akapity to pojedyncze wiersze oddzielone pustymi liniami, każdy rozsądny dzielnik może ciąć między akapitami, a nie wewnątrz zdania.
• Najgorsze błędy były płynne. „Spojrzała na budynek” to dobry chiński. Czytelnik zauważyłby dziwne podziały wierszy przy każdym cięciu i zawieszone 那是她在, ale nic nie oznacza złej postaci ani łuszczącej się farby jako błędu. Błędy w punktach podziału to najpierw błędy znaczenia, a dopiero potem formatowania.
• To był jeden model i jedno krótkie opowiadanie. Plik tej długości mieści się w jednym żądaniu, więc uruchomienia na całym pliku nigdy nie musiały niczego dzielić. Pełna powieść musi zostać podzielona, i właśnie wtedy przygotowanie z kroków 1–3 się opłaca. Te pliki testują przygotowanie i dzielenie, a nie własny potok BookTranslatora.

Jedna mniejsza obserwacja: w sześciu uruchomieniach na całym pliku model zapisał imię Mary jako 玛拉 w pięciu i 马拉 w jednym. Każdy wynik był wewnętrznie spójny, ale osobne żądania nie zgadzały się ze sobą. W przypadku długiej książki tłumaczonej w wielu fragmentach lista imion i ich uzgodnionych pisowni utrzymuje spójność każdego rozdziału. Nasz przewodnik po glosariuszach pokazuje, jak taki zbudować.

Krok 4: Przetłumacz, a potem sprawdź liczby

Gdy plik jest czysty, tłumaczenie to łatwa część. Możesz go przesłać do tłumacza TXT BookTranslatora, który przyjmuje pliki .txt, .md i .mdx, obsługuje pliki TXT do 300 MB i pokazuje cenę przed płatnością. Nie ma darmowego pełnego tłumaczenia, ale samo przesłanie mówi Ci, ile to będzie kosztować. Jeśli wolisz pracować z modelem czatu lub lokalnym LLM, podziel plik na granicach rozdziałów lub akapitów i prowadź glosariusz nazw. Jeśli Twój tekst to Markdown, a nie zwykła proza, zobacz nasz przewodnik po tłumaczeniu Markdown, ponieważ składnia Markdown wymaga własnych zasad.

Po tłumaczeniu porównaj oba pliki:

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

Jeśli któryś plik nie jest w UTF-8, dodaj --source-encoding lub --translated-encoding. Sprawdzanie rozdziałów zna angielskie i chińsko-japońskie wzorce nagłówków; w przypadku innych języków docelowych dodaj lokalne słowo oznaczające „rozdział” do wzorca na początku skryptu.

To jest raport z jednego z naszych uruchomień z cięciem:

                            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

Czytaj go tak:

• Liczba akapitów i nagłówków rozdziałów powinna się zgadzać. Brakujący akapit często oznacza, że dwa zostały połączone lub jeden pominięty.
• Liczba niepustych wierszy może się różnić z dobrego powodu. Nasze uruchomienia z zawijaniem całego pliku przeszły z 43 wierszy na 19, ponieważ model połączył twardo zawinięte wiersze, co było poprawą. Porównuj wiersze tylko wtedy, gdy źródło było już rozwinięte.
• Pozostałe znaki pisma źródłowego wskazują na fragmenty, które w ogóle nie zostały przetłumaczone. Kilka jest normalnych w przypadku nazw, terminów produktowych lub cytatów; ciąg takich znaków to pominięta sekcja.
• Znaki zastępcze w tłumaczeniu oznaczają problem z kodowaniem na wyjściu.

Liczby nie powiedzą Ci, czy tłumaczenie jest poprawne. Przeczytaj pierwszy i ostatni akapit każdego rozdziału oraz akapity po obu stronach każdego miejsca, w którym plik został podzielony. To tam nasz test znalazł każdy poważny błąd.

Często zadawane pytania

Dlaczego mój plik TXT wygląda dobrze w jednym programie, a w innym jest zniekształcony?

Oba programy odgadły różne kodowania. Jeden odgadł dobrze. Znajdź kodowanie, które poprawnie wyświetla tekst, a następnie zapisz plik jako UTF-8, aby każdy program czytał go tak samo.

Czy powinienem przekonwertować plik TXT na EPUB lub DOCX przed tłumaczeniem?

Tylko jeśli chcesz to, co dodają te formaty. Czysty plik TXT z wyraźnymi rozdziałami dobrze się tłumaczy tak, jak jest. Jeśli chcesz spis treści, nawigację po rozdziałach i ebooka, którego możesz czytać na urządzeniu, nasz przewodnik po przekształcaniu powieści internetowej w gotowy do tłumaczenia plik EPUB przeprowadzi Cię przez ten proces.

Czy mogę przetłumaczyć plik TXT zawierający tekst w wielu językach?

Tak, ale powiedz tłumaczowi, czego nie ruszać. Cytaty lub terminy w trzecim języku oraz nazwy, które powinny pozostać w oryginalnym zapisie, łatwiej chronić za pomocą glosariusza lub krótkiej instrukcji niż poprawiać później.

A co z plikiem TXT pobranym ze strony internetowej?

Sprawdź, czy masz prawo go używać. W przypadku książek w domenie publicznej lub plików, które sam napisałeś, powyższe kroki mają zastosowanie. Kodowanie lub format pliku nie mówią nic o prawach autorskich.