איך לתרגם קובץ 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, שאחריו הולכים הדפדפנים, הולך רחוק יותר: הוא קובע ש"המפענח של GBK הוא המפענח של gb18030". אם קובץ הוא GBK, פתיחתו כ-GB18030 תעבוד.
• סינית מסורתית מטייוואן או מהונג קונג היא לרוב Big5.
• יפנית היא לרוב Shift_JIS, או הגרסה המורחבת של מיקרוסופט שלה, ש-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 השורות הסתיימו באמצע משפט. הראשון מסתיים ב"הוא הצביע עם ה" והקטע הבא מתחיל ב"עט לעבר בניין בן שלוש קומות בפינה." בתרגום נפרד, החצי השני איבד את הנושא שלו. בשתי הרצות הוא חזר כ-她瞥了一眼街角那栋三层楼的建筑, "היא העיפה מבט לעבר הבניין בן שלוש הקומות בפינה." בשלישית, הוא הסתיים ב-随后她重新回到填字游戏上, "ואז היא חזרה לתשבץ." בסיפור, האיש בתא הכרטיסים מצביע וחוזר לתשבץ שלו. בכל שלוש ההרצות, קורא הסינית יחשוב שמארה עשתה זאת.

החיתוך השני, בין "היד הקפדנית, המיושנת במקצת, שלמדה ב" ל"בית ספר מנזר," השאיר את המשפט הסיני תלוי ב-那是她在, "זה היה המקום שבו היא," בכל שלוש ההרצות (הרצה אחת הוסיפה 一 מיותר), והמילה "למדה" נעלמה. החיתוך השלישי פיצל את המשפט על התריסים לשתי שורות, והחצי השני הפך את "צבועים, לא היטב, אבל לא מזמן" לצבע מתקלף: 油漆虽已斑驳 בשתי הרצות ו-油漆剥落 בשלישית. ומכיוון שהקטעים חוברו בשבירת שורה אחת, השורה הריקה לפני מעבר הסצנה נעלמה, ולכן בכל הרצה היו 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 שהורדתי מאתר אינטרנט?

ודאו שיש לכם את הזכות להשתמש בו. לגבי ספרים בנחלת הכלל או קבצים שכתבתם בעצמכם, השלבים שלמעלה חלים. הקידוד או הפורמט של קובץ לא מלמדים דבר על זכויות היוצרים שלו.