קידוד כתוביות בעברית: למה SRT הופך לג'יבריש ואיך פותרים את זה
UTF-8, Windows-1255, BOM וכיוון טקסט – ארבע בעיות שונות שנראות לעורך בדיוק אותו דבר: "הכתוביות שלי שבורות". כאן תזהו איזו מהן קרתה לכם, עם דוגמאות של טקסט שבור מול טקסט תקין.
זה קורה כמעט תמיד באותו רגע: מייבאים קובץ SRT בעברית לפרמייר, ובמקום "תודה שצפיתם בסרטון" מופיע על המסך משהו כמו תודה – שורה של תווים אקראיים שנראים כמו קוד שגוי, לא כמו שפה. פותחים את הקובץ בעורך טקסט, רואים שהעברית שם ותקינה לגמרי, ומתחילים לנחש: אולי לתמלל שוב? אולי כלי התמלול פגום? אולי פרמייר בכלל לא תומך בעברית?
האמת פשוטה יותר, וגם מתסכלת יותר: זו כמעט תמיד בעיית קידוד תווים (character encoding), לא בעיית תוכן. הקובץ נשמר בקידוד אחד – נניח UTF-8 – ונפתח בתוכנה שמצפה לקידוד אחר, לרוב Windows-1255 (הקידוד העברי הישן של ווינדוס). כל בית (byte) מתפרש לפי טבלת התווים הלא נכונה, וכל אות עברית הופכת לרצף סימנים שאין לו קשר למה שנכתב. זו לא שגיאת תרגום ולא באג בפרמייר – זו שיחה בין שתי תוכנות שמדברות שתי "שפות בתים" שונות בלי לדעת את זה.
באנגלית הבעיה כמעט לא קיימת, כי כל קידוד נפוץ מסכים על 128 התווים הבסיסיים (A‑Z, ספרות, סימני פיסוק). היא מופיעה בעיקר בשפות שאינן לטיניות – עברית, ערבית, יפנית, רוסית – כי שם כל קידוד ממקם את התווים האלה בטווח בתים אחר. וזה עוד לפני כיוון הטקסט (RTL) ומיקום הפיסוק, שהיא בעיה נפרדת לגמרי שגם UTF-8 תקין לא פותר. בעמוד הזה נפריד בין השתיים, עם דוגמאות של טקסט שבור לצד הגרסה התקינה שלו.
Translated naturally.
In every language.
Native phrasing, not word-for-word. Word-level timestamps, burned-in or exported as SRT — in seconds.
למה קובץ SRT בעברית הופך לג'יבריש – בעיית קידוד התווים
כל קובץ טקסט, כולל SRT, הוא בסופו של דבר רצף בתים על הדיסק. כדי להפוך אותם בחזרה לאותיות קריאות, המחשב צריך טבלת המרה – קידוד תווים. באנגלית זה כמעט לא משנה, כי כמעט כל קידוד מסכים על אותה טבלה בסיסית. בעברית זה משנה מאוד, כי יש לפחות שלושה קידודים נפוצים שממקמים את האותיות העבריות בטווחי בתים שונים לגמרי: UTF-8 (התקן המודרני, שמכסה את כל השפות), Windows-1255 (הקידוד העברי הישן, שעדיין מופיע ככברירת מחדל בכלים מסוימים בווינדוס), ו‑ISO-8859-8 (תקן ישן יותר ופחות נפוץ).
כשכלי תמלול או עורך טקסט שומר קובץ SRT ב‑Windows-1255, ותוכנה אחרת קוראת אותו כ‑UTF-8, כל בית בטווח העברי מתפרש דרך הטבלה הלא נכונה. אות עברית אחת (בית בודד ב‑Windows-1255) נקראת כחלק מתו UTF-8 רב‑בתי, והתוצאה היא רצף כמו תודה במקום תודה. לתופעה הזו קוראים mojibake, וברגע שרואים תווים כמו × חוזרים בתחילת מילים לאורך כל הקובץ – זה כמעט תמיד סימן ודאי לבעיית קידוד ולא לשום דבר אחר.
יש כאן גם בעיה שנייה, עדינה יותר: BOM (Byte Order Mark) – שלושה בתים בלתי־נראים בתחילת קובץ UTF-8, שתפקידם לסמן לתוכנה "זה UTF-8". חלק מהתוכנות מוסיפות אותו וחלק לא, וחלק מהפרסרים של SRT קוראים אותו כחלק מהטקסט של הכתובית הראשונה – כך שדווקא הכתובית הראשונה נראית משובשת בזמן שכל שאר הקובץ תקין. הפתרון הבסיסי הוא לוודא ששני הצדדים, הכלי ששומר והכלי שקורא, עובדים באותו קידוד – עדיף UTF-8 בלי BOM, שזו ברירת המחדל שרוב התוכנות המודרניות מצפות לה.
גם UTF-8 תקין לא מספיק: כיוון טקסט, פיסוק ומספרים
נניח שהקידוד תקין – הקובץ שמור ב‑UTF-8 בלי BOM, וכל אות מוצגת נכון. עדיין נשארת בעיה שנייה, שהרבה עורכים מבלבלים עם הראשונה: כיוון הטקסט. עברית נכתבת מימין לשמאל, אבל התו עצמו לא "יודע" את כיוונו – זה תפקידו של האלגוריתם הדו‑כיווני של יוניקוד (Bidi), שמחליט איך לסדר על המסך רצף שחלקו RTL וחלקו LTR: מספרים, מילים באנגלית וסימני פיסוק. כשהאלגוריתם לא מיושם כמו שצריך, הפיסוק והמספרים "בורחים" לצד הלא נכון.
דוגמה: המשפט התקין הוא האם זה עובד? כן, ברוב המקרים. כשה‑Bidi נשבר, סימן השאלה עלול להופיע ויזואלית בתחילת המשפט במקום בסופו – ?האם זה עובד כן, ברוב המקרים. אותו דבר קורה עם ספרות: דקה 5 בסרטון עלול להיראות כ‑5 בסרטון דקה כשהמנוע לא יודע לטפל בבלוק מספרים בתוך משפט עברי.
ההבחנה הזו חשובה מעשית: תיקון קידוד לא יפתור בעיית כיוון, ותיקון כיוון לא יפתור ג'יבריש. אם אחרי המרה ל‑UTF-8 האותיות קריאות אבל הפיסוק עדיין יושב במקום מוזר – זו בעיית Bidi, וצריך מנוע כתוביות שמטפל בעברית מלכתחילה ולא מוסיף לה תמיכה בדיעבד.
איך Captain Cut פותר את שתי הבעיות בתוך פרמייר
Captain Cut הוא תוסף CEP נייטיבי לפרמייר פרו (לפרמייר בלבד) שבונה את הכתוביות ישירות בתוך הפרויקט, על גבי מסלולי כתוביות תקניים של פרמייר – כאלה שאפשר לעצב ב‑Essential Graphics, לערוך בטיימליין ולייצא כ‑SRT. כשהתמלול נוצר בתוך פרמייר עצמו, שרשרת ה"שמירה בתוכנה אחת ופתיחה בתוכנה אחרת" – בדיוק זו שיוצרת את בעיית הקידוד – פשוט לא קיימת.
על בעיית הכיוון והפיסוק, Captain Cut תומך ב‑RTL אמיתי: לא הצהרה כללית על "תמיכה בעברית וערבית", אלא טיפול מפורש בארבעה אלמנטים שכל אחד מהם יכול להישבר בנפרד – כיוון הטקסט עצמו, מיקום סימני הפיסוק ביחס למשפט, שורות בכיוון מעורב (עברית יחד עם מספרים או אנגלית באותה שורה), והצגת ספרות בתוך משפט עברי. כלומר, הדוגמאות מהסעיף הקודם הן בדיוק המקרים שהמנוע נבנה כדי לטפל בהם.
מעבר לזה, לכל כתובית יש חותמות זמן ברמת מילה בודדת, כך שאפשר לערוך מילה אחת בלי לפרק את כל השורה. יש שימור שמות, כלומר שמות פרטיים ומונחים ספציפיים נשמרים כפי שנאמרו. Captain Cut תומך ב‑40+ שפות תמלול וכתוביות, כולל תרגום תוך כדי תמלול – אפשר לתמלל בעברית ולקבל באותה הרצה גם גרסה מתורגמת, בלי לעבור דרך קובץ SRT חיצוני. הכול קורה בתוך התוסף, על טיימליין פרמייר רגיל.
תמלול נייטיבי בפרמייר מול ייבוא קובץ SRT חיצוני
| Captain Cut | תמלול חיצוני וייבוא SRT | |
|---|---|---|
| קידוד תווים בין ייצוא לייבוא | לא רלוונטי – הכתוביות נוצרות בתוך פרמייר | תלוי בקידוד שבו הכלי החיצוני שמר |
| BOM בתחילת הקובץ | לא רלוונטי | לעיתים צריך לבדוק ולהסיר ידנית |
| מיקום פיסוק בשורות RTL | מטופל אוטומטית | תלוי בכלי המקור |
| שורות מעורבות של עברית ומספרים | מטופל אוטומטית | תלוי בכלי המקור |
| עריכה כמסלול כתוביות תקני בפרמייר | כן, כולל עיצוב ב‑Essential Graphics | רק אחרי ייבוא |
| ייצוא ל‑SRT בעברית | כן | כן, אם הקידוד נשמר נכון |
שאלות נפוצות על קידוד כתוביות בעברית
קידוד תווים הוא הטבלה שהופכת בתים לאותיות על המסך. באנגלית כמעט כל קידוד מסכים על אותה טבלה עבור 128 התווים הבסיסיים, ולכן גם שני כלים עם קידודים שונים יציגו את הטקסט נכון. בעברית יש לפחות שלושה קידודים נפוצים – UTF-8, Windows-1255 ו‑ISO-8859-8 – וכל אחד ממקם את האותיות העבריות בטווח בתים אחר. כשקובץ נשמר בקידוד אחד ונקרא כאילו הוא בקידוד אחר, כל אות מתפרשת דרך הטבלה הלא נכונה והתוצאה היא רצף סימנים חסר משמעות.
הדרך הבטוחה היא לפתוח את הקובץ בעורך טקסט שמאפשר לבחור קידוד תצוגה, כמו VS Code או Notepad++, ולהחליף בין UTF-8 ל‑Windows-1255 עד שהטקסט נראה תקין – הקידוד שבו הוא קריא הוא הקידוד שלו. רוב העורכים גם מציגים בשורת המצב איזה קידוד זוהה. בלי עורך כזה, סימן מהיר הוא חיפוש תווים חוזרים כמו × בתחילת מילים, שכמעט תמיד מעיד על mojibake.
כי קידוד וכיוון הן שתי בעיות שונות. הקידוד קובע איזו אות מוצגת; הכיוון, דרך אלגוריתם ה‑Bidi של יוניקוד, קובע היכן היא מוצגת ביחס לשאר המשפט – במיוחד כששורה אחת מכילה גם עברית, גם מספרים וגם סימני פיסוק. קובץ עם קידוד UTF-8 תקין לחלוטין עדיין יכול להציג פיסוק במקום שגוי אם הכלי שיצר אותו לא יישם Bidi כראוי. לכן צריך לבדוק את שתי השכבות בנפרד.
אם הבעיה היא קידוד בלבד (mojibake), לרוב אפשר לתקן: פותחים את הקובץ בעורך טקסט תחת קידוד המקור – בדרך כלל Windows-1255 בקבצים ישנים מווינדוס – ושומרים מחדש כ‑UTF-8 בלי BOM. אם הבעיה היא כיוון או פיסוק שגוי, תיקון ידני שורה‑שורה אפשרי אבל גוזל זמן רב בקבצים ארוכים, ולרוב מהיר יותר לתמלל מחדש עם מנוע שמטפל ב‑RTL מלכתחילה.
אלה שתי שכבות טכניות נפרדות. קידוד פועל ברמת הבתים בקובץ וקובע איזו אות מיוצגת. כיוון פועל ברמת התצוגה וקובע את סדר הצגת התווים כשיש שילוב של RTL ו‑LTR באותה שורה. קובץ יכול להיות מקודד ב‑UTF-8 בצורה מושלמת וכל אות בו תוצג נכון, ועדיין להיראות שבור כי הפיסוק או המספרים לא מוקמו נכון. הבלבול בין השניים הוא הסיבה שעורכים מתקנים קידוד וממשיכים לראות בעיה.
שורה בעברית טהורה זקוקה לכיוון RTL אחיד לכל אורכה. שורה מעורבת – למשל "פגישה ב־14:00 עם John" – מחייבת את מנוע ה‑Bidi לעבור בין RTL ל‑LTR כמה פעמים באותה שורה, ולהחליט בכל מעבר היכן בדיוק כל בלוק מתחיל ומסתיים ויזואלית. זו הנקודה הרגישה ביותר, ולכן Captain Cut מטפל בשורות בכיוון מעורב במפורש, כולל ספרות בתוך משפט עברי.
הפתרון הוא לתמלל מחדש בתוך פרמייר, וכך למנוע לחלוטין את שרשרת השמירה־ייבוא שיוצרת את בעיית הקידוד. קובץ SRT ישן שכבר שבור לא מתקן את עצמו בעקבות התקנת התוסף – הוא דורש תיקון ידני חד־פעמי, כפי שתואר למעלה, או תמלול מחדש. בפרויקטים חדשים עדיף להתחיל את התמלול בתוך פרמייר במקום לגלות את הבעיה רק בסוף.
תמללו בעברית בלי להתעסק בקידודים
7 ימים ניסיון חינם בכל התוכניות, אפשר לבטל בכל רגע. כתוביות ברמת מילה, RTL אמיתי וייצוא SRT – הכול בתוך פרמייר.
לתוכניות ולמחירים