大きなTXTファイルを翻訳する方法：文字コード、章、改行

大きなTXTファイルを翻訳するには、どこかにアップロードする前に3つのことを準備します。まず、テキストが正しくデコードされていることを確認し、UTF-8で保存します。次に、すべての章見出しを前後に空行を入れて単独の行に配置します。3つ目に、ファイルが固定幅で改行されている場合は、段落ごとに1行になるようにそれらの行を結合し、段落間に空行を入れます。その後、ファイル全体を翻訳し、最後に原文と翻訳の段落数と章数を比較します。

プレーンテキストファイルにはスタイルも見出しもメタデータもありません。翻訳ツールが構造について知ることはすべて、バイトと改行から得られます。だからこそ、同じ3つの問題が繰り返し発生します。バイトが間違った文字コードで読み取られる、章が通常の行と区別できない、または改行が文の終わりを何も示していない、という問題です。

4つの文字コードのサンプルファイルを作成し、無料チェッカーを書き、強制改行された短編小説をローカルモデルで簡体字中国語に9回翻訳しました。モデルはファイル全体を見たときは強制改行を問題なく処理しました。ファイルを行数で分割した3回の実行ではすべて、文が途切れ、ある登場人物の行動が別の人物に割り当てられました。

クイックチェックリスト

チェッカーはすべての行についてレポートし、エンコーディング、バイトオーダーマーク、改行コード、強制改行を修正します。章見出しと欠落した空行は手動で修正してください。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のサンプルで実行したところ、2つのエンコーディングがファイル全体を1つのエラーもなくデコードしました：

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

日本語なのは2行目だけです。1行目は誰も書いていない珍しい中国語文字の羅列です。GB18030の中国語サンプルでは、5つのエンコーディングがエラーなくデコードし、そのうちGB18030だけが章見出し「第一章 最后一班渡轮」を表示しました。したがって、規則は単純です。エンコーディングは、プログラムがエラーを出したかどうかではなく、最初の数行を読んで判断してください。

推測が外れやすいのは次のようなケースです。

• 古いWindowsシステムや中国のサイトから取得した中国語テキストは、GBKまたはGB18030であることがよくあります。GB18030はGBKが扱うすべてをカバーしており、ブラウザが従うWHATWG Encoding Standardはさらに踏み込んで「GBKのデコーダーはgb18030のデコーダーである」と述べています。ファイルがGBKであれば、GB18030として開けば正しく読めます。
• 台湾や香港の繁体字中国語は、Big5であることがよくあります。
• 日本語はShift_JIS、またはMicrosoftによるその拡張版であることが多く、WindowsやPythonではcp932と呼ばれます。
• 韓国語はEUC-KRであることがよくあります。
• NULバイトで埋め尽くされたファイルや、1文字おきに空に見えるファイルは、通常はバイト順マーク（BOM）なしのUTF-16です。

バイト順マーク（BOM）とは、ファイルの先頭にある短い不可視のコードで、UTF-8、UTF-16、UTF-32のいずれかを示します。BOMがあれば、それを信頼してください。同じ標準規格は「バイト順マークは何よりも優先される」と述べています。私たちのチェッカーはまずBOMを読み取り、BOMがない場合にのみ推測します。

ファイルをUTF-8で保存する

テキストが正しく読めるようになったら、UTF-8で保存してください。WHATWG標準規格はUTF-8を「Unicodeの交換に最も適したエンコーディング」と呼んでおり、あらゆる翻訳ツールにとって最も安全な選択です。

翻訳において特に重要な第2の理由があります。レガシーエンコーディングは、それぞれの地域の文字しかカバーしていません。Shift_JISには「这」（「这是最后一班渡轮」の最初の文字）のコードがなく、Big5にもありません。これは簡体字中国語の文字だからです。Windows-1252はキリル文字を保存できません。翻訳後のファイルを元のレガシーエンコーディングで書き戻す必要がある場合、翻訳先の言語が収まらない可能性があります。BookTranslatorのTXT翻訳ツールは、一般的なエンコーディングを自動検出し、翻訳されたファイルを「入力と同じエンコーディング」で返すと謳っているため、最初からUTF-8で始めればこの問題は完全に回避できます。

変換は、テキストエディタで（正しいエンコーディングで開き、「UTF-8として保存」を選ぶ）、macOSやLinuxではiconv -f GB18030 -t UTF-8 in.txt > out.txtで、あるいはチェッカーを使って行えます。

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

ファイルにすでに�文字が含まれている場合、その破損はファイルを受け取る前に起きています。再度変換しても失われた文字は復元されません。より良いソースのコピーを探してください。

ステップ2：章を見つけやすくする

章が重要な理由は3つあります。長いファイルは分割して翻訳され、章の区切りは最もきれいな分割点になります。翻訳後には各章を確認したくなるでしょう。そして後でテキストを電子書籍にする場合、章見出しが目次になります。

各見出しをそれぞれ独立した行に置き、その前後に空行を入れてください。そして本全体を通して1つのパターンを使ってください。私たちのチェッカーが数えるパターンは次のとおりです。

• Chapter 1, Chapter One: The Last Ferry, Part Two, Prologue, Epilogue
• 第一章, 第12回, 第三話, 第二卷
• 数字またはローマ数字だけが行にあるもの（例：12やXII.）

inspectを実行し、見つかった見出しのリストを読んでください。本に40章あるのにチェッカーが37しか見つけない場合、3つの見出しが隠れています。1つは最初の文に食い込んでいる、1つは「第7章」のような別の言葉を使っている、あるいは1つは同じ行にテキストがある、といったケースです。その3つを手作業で修正してください。翻訳後のファイルで問題を探すより時間がかかりません。

ステップ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

修正方法は、各段落内の行を結合し、段落間の空行を保つことです。罠は、改行が本物であるテキストです。詩、歌詞、手紙、住所、レシピ、リストなどです。私たちのサンプルには5行の手紙が含まれています。

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

「すべての単一改行をスペースに置き換える」という乱暴な方法では、それが1つの長い行になってしまいます。チェッカーの--unwrapは、段落のほとんどの行がほぼ全幅に近い場合にのみ段落を結合するため、この手紙のような短い行のブロックはそのまま残されます。私たちのサンプルでは、元のラップされていないファイルをバイト単位で正確に、手紙も含めて再構築しました。ご自身のファイルでは、信頼する前に結合されたいくつかの段落と、すべての詩のブロックを確認してください。

さらに2つの詳細があります。中国語や日本語のテキストの行を結合するときは、行間にスペースを入れないでください。チェッカーはCJKの行を、CJK句読点で終わる行も含めて、スペースなしで結合します。また、テキストがOCR由来の場合、行末で単語がハイフンで分割されていることがあり、これには独自の判断が必要です。OCRの改行とハイフネーションを修正するガイドでその方法を説明しています。

テストした内容：ハードラップされたテキスト、全体 vs. 分割

ハードラップが実際に翻訳を損なうのか、それとも見た目が悪くなるだけなのかを知りたかったのです。テスト用に396語の短編小説を書きました。3章、15段落、会話、上記の手紙、そして * * * の場面転換が含まれています。同じ単語で2回保存しました。ラップなしは1段落1行、66文字でハードラップは空行以外が19行ではなく43行になっています。

次に、ローカルモデルに簡体字中国語への翻訳を3通り、それぞれ3回ずつ実行させました。

1. ラップあり、ファイル全体。 ハードラップされたファイルを1回のリクエストで。
2. ラップなし、ファイル全体。 ラップされていないファイルを1回のリクエストで。
3. ラップあり、12行ごとに分割。 ハードラップされたファイルを12行ごとに分割し、部分ごとに1リクエスト、返答を再結合。これはスクリプトやツールが長いファイルを段落単位ではなく行数で分割した場合に起こることです。

モデルはLM Studio上のQwen 3.6 27B（Q4_K_M）で、thinkingをオフ、temperature 0.3、Apple M4 Max 64 GBメモリ上で実行しました。すべてのリクエストで同じ1文のプロンプトを使用しました。実行日は2026年10月28日です。スクリプトはrun_llm_txt_test.py、9つの出力はすべて未編集で公開されており、results.csvには実行ごとに1行が記録されています。

最初の発見は私たちを驚かせました。モデルがハードラップされたファイル全体を見たとき、モデル自身が行を結合しました。3つの出力はすべて1行に1段落で、ラップされていない実行と同じ19行になり、同じように読めました。つまり、この短いファイルでは、ハードラップだけではこのモデルに悪影響を与えませんでした。

行数でファイルを分割すると、毎回同じ箇所で悪影響が出ました。12行の断片のうち3つが文の途中で終わっていました。最初の断片は「He pointed with his」で終わり、次の断片は「pen at a three-storey building on the corner.」で始まります。別々に翻訳すると、後半は主語を失いました。2回の実行では「彼女は街角の3階建ての建物をちらりと見た」という意味の「她瞥了一眼街角那栋三层楼的建筑」になりました。3回目では「その後彼女はクロスワードに戻った」という意味の「随后她重新回到填字游戏上」で終わりました。物語では、切符売り場の男が指さしてクロスワードに戻ります。3回の実行すべてで、中国語の読者はマラがそうしたと思うでしょう。

2番目の分割は、「the careful, slightly old-fashioned hand she had learned at a」と「convent school,」の間で行われ、3回の実行すべてで中国語の文が「那是她在」（「それは彼女がいたところ」）で宙に浮いたままになり（1回の実行では余分な「一」が追加されました）、「learned」という単語が消えました。3番目の分割はシャッターについての文を2行に分け、後半は「painted, not well, but not long ago」を剥がれた塗装に変えました。2回の実行では「油漆虽已斑驳」、3回目では「油漆剥落」となりました。そして、断片が単一の改行で結合されたため、場面転換前の空行が消え、各実行が15段落ではなく14段落になったのです。私たちのチェッカーは段落数を検出しました。誤った文字は検出できませんでした。それは読んで見つけました。

これがあなたのファイルにとって何を意味するか：

• アンラップは、あなたが制御できないスプリッターからあなたを守ります。 すべての長いファイルは、あなた自身のスクリプト、チャットウィンドウの制限、アップロード先のツールなど、どこかで分割されます。段落が空行で区切られた単一行であれば、どんな合理的なスプリッターでも文の途中ではなく段落間で切ることができます。
• 最悪のエラーは流暢でした。 「彼女は建物をちらりと見た」は良い中国語です。読者は各分割箇所の奇妙な改行と宙に浮いた「那是她在」に気づくでしょうが、誤った文字や剥がれた塗装が間違いであることを示すものは何もありません。分割点でのエラーは、まず意味のエラーであり、次にフォーマットのエラーです。
• これは1つのモデルと1つの短編小説でした。 この短さのファイルは1回のリクエストに収まるため、ファイル全体の実行では何も分割する必要がありませんでした。完全な小説は分割する必要があり、まさにそのときにステップ1から3の準備が報われます。これらのファイルは準備と分割をテストするものであり、BookTranslator自体のパイプラインをテストするものではありません。

もう1つ小さな観察：6回のファイル全体の実行で、モデルはマラの名前を5回は「玛拉」と書き、1回は「马拉」と書きました。各出力はそれ自体と一致していましたが、別々のリクエストは互いに一致しませんでした。多くの断片に分けて翻訳される長い本では、名前とその合意された綴りのリストがすべての章を揃えます。私たちの用語集ガイドはその作り方を示しています。

ステップ4：翻訳してから、カウントを確認する

ファイルがきれいであれば、翻訳は簡単な部分です。BookTranslatorのTXT翻訳ツールにアップロードできます。これは.txt、.md、.mdxファイルを受け付け、最大300 MBのTXTファイルを処理すると述べており、チェックアウト前に価格を表示します。無料の完全翻訳はありませんが、アップロード自体がコストを教えてくれます。チャットモデルやローカルLLMで作業したい場合は、章や段落の境界でファイルを自分で分割し、名前の用語集を保持してください。テキストがプレーンな散文ではなくMarkdownの場合は、Markdown翻訳ガイドを参照してください。Markdown構文には独自のルールが必要です。

翻訳後、2つのファイルを比較します：

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

どちらかのファイルがUTF-8でない場合は、--source-encodingまたは--translated-encodingを追加してください。章のチェックは英語と中国語/日本語の見出しパターンを認識します。他のターゲット言語の場合は、スクリプトの先頭にあるパターンに「chapter」に相当する現地語を追加してください。

これは、私たちの分割実行の1つのレポートです：

                            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

次のように読みます：

• 段落と章の見出しは一致するはずです。段落が欠けている場合は、2つが統合されたか、1つが削除されたことを意味することがよくあります。
• 空でない行は、正当な理由で異なることがあります。私たちのファイル全体のラップ実行は、モデルがハードラップされた行を結合したため、43行から19行になりました。これは改善でした。行を比較するのは、ソースがすでにアンラップされている場合だけにしてください。
• 残っているソーススクリプトの文字は、まったく翻訳されなかった箇所を指します。名前、製品用語、引用符については少数なら正常です。連続している場合は、スキップされたセクションです。
• 翻訳内の置換文字は、出力時のエンコーディング問題を意味します。

カウントは翻訳が正しいかどうかを教えてくれません。各章の最初と最後の段落、およびファイルが分割されたすべての箇所の両側の段落を読んでください。そこが私たちのテストがすべての重大なエラーを見つけた場所です。

よくある質問

なぜ私のTXTファイルはあるプログラムでは問題なく見え、別のプログラムでは文字化けするのですか？

2つのプログラムが異なるエンコーディングを推測しました。1つは正しく推測しました。テキストを正しく表示するエンコーディングを見つけ、ファイルをUTF-8として保存して、すべてのプログラムが同じように読めるようにしてください。

翻訳する前にTXTファイルをEPUBやDOCXに変換すべきですか？

そうした形式が加えるものが本当に必要な場合だけです。章が明確なきれいなTXTファイルは、そのままでも十分に翻訳できます。目次や章ナビゲーション、デバイスで読める電子書籍が必要なら、ウェブ小説を翻訳可能なEPUBに変換するガイドで手順を説明しています。

複数の言語が混在したTXTファイルを翻訳できますか？

はい、ただし翻訳者に何をそのままにするかを伝えてください。第三言語の引用や用語、元の文字のままにすべき固有名詞は、後から修正するよりも用語集や短い指示で保護する方が簡単です。

ウェブサイトからダウンロードしたTXTファイルはどうすればよいですか？

使用する権利があるか確認してください。パブリックドメインの書籍や自分で書いたファイルなら、上記の手順が当てはまります。ファイルのエンコーディングや形式は、著作権について何も教えてくれません。