כתוביות בעברית הופכות לג'יבריש בפרמייר? הנה למה, ואיך נראית התוצאה הנכונה
כשקובץ SRT בעברית נפתח עם קידוד לא נכון, כל אות הופכת לזוג תווים חסרי משמעות. כאן רואים בדיוק איך ג'יבריש כזה נראה מול הטקסט הנכון, ואיך Captain Cut מונע את זה מהשורש.
עורך פותח קובץ SRT שיצא ממערכת תמלול אוטומטית, ובמקום "שלום, ברוכים הבאים לפרק היום" מופיע על המסך משהו כמו שלו×, ×'×¨×•×›×™× ×'××™×. זו לא תקלה נדירה, אלא התוצאה הישירה של קידוד תווים שגוי: הקובץ נכתב ב-UTF-8, אבל התוכנה שפותחת אותו – עורך טקסט, פלטפורמת וידאו או מנוע ייבוא כלשהו – מניחה שהוא כתוב ב-Windows-1252 או ב-ANSI, ומתרגמת כל בייט לתו הלא נכון. התוצאה היא ג'יבריש שאי אפשר לקרוא, מלא בסימנים כמו ×, ©, œ שאין להם שום קשר לעברית.
הבעיה הזו שונה מהותית מבעיית ה-RTL הכללית שמתוארת בעמוד ההורה כתוביות בעברית לפרמייר: שם הכתוביות נראות עברית תקינה, אבל הכיוון או מיקום הפיסוק שגויים. כאן הבעיה עמוקה יותר – הטקסט עצמו נהרס ברמת התו, ואי אפשר "לתקן כיוון" לטקסט שכבר לא מכיל אותיות עבריות אמיתיות. צריך לפתוח את הקובץ מחדש עם הקידוד הנכון, ולפעמים גם לתמלל מחדש.
בעמוד הזה שני דברים: הדגמה מדויקת של איך הג'יבריש נראה לעומת איך זה אמור להיראות, ואיך Captain Cut מונע את זה מלכתחילה – הכתוביות שהוא מפיק לא עוברות דרך ייצוא וייבוא של קובץ SRT עם קידוד לא ברור, אלא נכתבות ישירות כטראק כתוביות סטנדרטי של פרמייר.
Translated naturally.
In every language.
Native phrasing, not word-for-word. Word-level timestamps, burned-in or exported as SRT — in seconds.
למה כתוביות בעברית הופכות לג'יבריש: הבאג של קידוד התווים
התופעה נקראת מוג'יבייק (mojibake) והיא לא ייחודית לעברית – היא קורה בכל שפה שלא נכתבת באותיות לטיניות. בעברית היא בולטת ומתסכלת יותר, כי אין דרך לנחש את המילה המקורית מתוך התווים השבורים.
הנה איך זה נראה בפועל. המשפט התקין: שלום, ברוכים הבאים לערוץ
אם קובץ ה-SRT נשמר ב-UTF-8 ונפתח בתוכנה שמניחה קידוד Windows-1252 (ANSI מערבי, ברירת מחדל נפוצה בעורכי טקסט ישנים), כל תו עברי – שתופס שני בייטים ב-UTF-8 – מתפרש כשני תווים לטיניים נפרדים. התוצאה: שלו×, ×'×¨×•×›×™× ×'××™×
לא רק שהטקסט לא קריא, הוא גם ארוך פי שניים מהמקור, כי כל אות עברית הפכה לשני תווים. זה בדיוק הסימן המזהה: אם מספר התווים בשורה כפול ממה שציפית, וכולם מתחילים ב-× , מדובר בקובץ UTF-8 שנקרא כ-Latin-1.
יש גם וריאציה שנייה, פחות נפוצה ולא פחות מתסכלת: קובץ שנכתב ב-Windows-1255 (הקידוד העברי הישן, שעדיין מופיע בקבצי כתוביות ותיקים) ונפתח כ-UTF-8. במקרה הזה, במקום ג'יבריש ארוך מקבלים ריבועים ריקים, סימני שאלה חוזרים (?????), או שהתוכנה מסרבת לפתוח את הקובץ ומציגה שגיאה על תווים לא חוקיים.
בפרמייר הבעיה מחריפה, כי כל שלב בשרשרת – ייצוא מכלי התמלול, פתיחה בעורך טקסט לתיקון ידני, ייבוא חזרה לפרמייר – הוא הזדמנות נוספת לקידוד להתבלבל. עורך שמתקן כתובית אחת ידנית ושומר בקידוד ברירת המחדל של המערכת יכול להרוס את כל הקובץ בלחיצת שמירה אחת.
היפוך אותיות ופיסוק במקום הלא נכון: הבאג השני
גם כשהקידוד תקין והטקסט נקרא בעברית אמיתית, יש באג שני שנפוץ לא פחות: תוכנה שלא מיישמת נכון את אלגוריתם ה-Bidi (הכיווניות הדו-כיוונית של יוניקוד) מציגה את סדר האותיות הפוך, לא ברמת המילה אלא ברמת התו בתוך המילה.
המשפט התקין: יש לי 3 קבצים לתמלול
בתוכנה שמטפלת בטקסט כרצף LTR בלבד, בלי להפעיל בידי כראוי, המשפט עלול להיראות כך: לוצבק 3 יל שי (כל מילה עברית הפוכה אות-אות, הספרה 3 נשארת תקינה כי ספרות תמיד נקראות LTR, אבל סדר המילים ביחס למספר משתבש)
ברמת הפיסוק זה בולט עוד יותר. משפט שאלה תקין נגמר בסימן שאלה שיושב חזותית בצד שמאל של השורה, כי עברית נכתבת מימין לשמאל וסוף המשפט הלוגי הוא הקצה השמאלי: איך מוסיפים כתוביות בעברית?
בתוכנה עם טיפול RTL שגוי, סימן השאלה נדבק לתחילת המשפט או קופץ לצד הלא נכון: ?איך מוסיפים כתוביות בעברית
זה נראה כמו פרט קטן, אבל בכתובית שרצה על המסך שנייה וחצי, סימן שאלה במקום הלא נכון מאלץ את הצופה לקרוא את המשפט פעמיים כדי להבין את הטון שלו.
הבעיה השלישית בקטגוריה הזו היא שבירת שורה במקום הלא נכון. עורך כתוביות שלא מודע לעברית שובר שורה לפי ספירת תווים בלבד, בלי להתחשב בגבולות מילה ובכיווניות. התוצאה: השורה הראשונה נגמרת באמצע מילה, ושארית המילה קופצת לשורה השנייה.
שבירה שגויה: שורה 1: אני רוצה להס שורה 2: ביר את השתיקות מהפרויקט
לעומת שבירה נכונה, שמכבדת גבול מילה וכיוון קריאה: שורה 1: אני רוצה להסיר שורה 2: את השתיקות מהפרויקט
כל אחת מהתקלות האלה – קידוד, כיווניות אותיות, מיקום פיסוק ושבירת שורה – יכולה לקרות בנפרד מהאחרות. קובץ יכול להיות עם קידוד תקין אבל בידי שבור, או להפך. בדיוק בגלל זה הפתרון הידני, לתקן קידוד ולקוות שהשאר יסתדר, אינו אמין.
איך Captain Cut מונע את כל זה מלכתחילה
קפטן קאט נמנע מרוב הבעיות האלה כי הוא לא עובד עם קובץ SRT ביניים שצריך לפתוח, לערוך ולשמור מחדש בתוכנה חיצונית. זהו תוסף CEP נייטיב לפרמייר פרו בלבד (לא DaVinci), שכותב את הכתוביות ישירות כטראק כתוביות סטנדרטי של פרמייר, עם עיצוב דרך Essential Graphics – כך שאין שלב ביניים שבו הקידוד יכול להתבלבל.
התמלול תומך ביותר מ-40 שפות עם חותמות זמן ברמת מילה בודדת, כך שכל מילה נצמדת לרגע שבו היא נאמרת, ולא רק המשפט השלם. לעברית ולערבית יש תמיכת RTL אמיתית: כיוון הטקסט, מיקום הפיסוק, שורות בכיוון מעורב (עברית עם מילים או מספרים באנגלית באותה שורה) והצגה נכונה של מספרים. כל אלה מטופלים בשכבת התמלול עצמה, ולא כתיקון אחרי ייבוא לפרמייר.
שימור שמות פותר בעיה נלווית: כתובית עם שם דובר שגוי היא בעיה שונה מג'יבריש, אבל היא באה מאותה משפחת כשלים – המערכת מנחשת במקום לזהות. קפטן קאט שומר שמות כפי שנאמרו בפועל.
מי שצריך גם תרגום, למשל ערוץ בעברית שרוצה גרסה באנגלית, יכול להשתמש בתרגום תוך כדי תמלול במקום לתמלל בעברית, לייצא, ואז להריץ כלי תרגום נפרד שעלול להוסיף בעיית קידוד משלו.
הפלט תמיד יוצא כטראק כתוביות תקני של פרמייר, ואפשר לייצא ממנו SRT בסוף התהליך. הייצוא הזה קורה פעם אחת מטקסט שכבר תקין, ולא כחלק משרשרת ייבוא-ייצוא-ייבוא שבה כל שלב הוא הזדמנות לשבירה. מי שמתמלל הקלטת פגישה או שיחת זום ימצא את אותה בעיית קידוד וכיווניות בדיוק, ולכן שווה להסתכל גם על תמלול פגישות בעברית ועל תמלול זום בעברית.
קידוד וכיווניות: Captain Cut מול ייצוא SRT גולמי
| Captain Cut | ייצוא SRT גולמי מכלי תמלול כללי | |
|---|---|---|
| קידוד UTF-8 נשמר לאורך התהליך | כן – הכתוביות נכתבות ישירות כטראק כתוביות של פרמייר | תלוי בכלי ובקידוד שבו הקובץ נשמר ונפתח |
| כיווניות RTL וסדר אותיות | מטופל בשכבת התמלול עצמה | תלוי ביישום ה-Bidi של התוכנה שפותחת את הקובץ |
| מיקום פיסוק בעברית | נכון מהרגע הראשון | משתנה לפי התוכנה שמציגה את הקובץ |
| שורות מעורבות של עברית, אנגלית ומספרים | נתמך | תלוי ביישום אלגוריתם ה-Bidi |
| שלב ביניים של פתיחה ושמירה בעורך טקסט חיצוני | לא נדרש | נדרש, וזה השלב שבו הקידוד עלול להישבר |
שאלות נפוצות
ברוב המקרים זו לא בעיה בתמלול עצמו אלא בשלב הביניים: הכלי שמר את קובץ ה-SRT ב-UTF-8, שהוא הסטנדרט הנכון לעברית, אבל התוכנה שפתחה אותו ניחשה קידוד אחר – בדרך כלל Windows-1252 או ANSI מקומי. כל תו עברי, שתופס שני בייטים, מתפרש כשני תווים לטיניים נפרדים, וזה בדיוק מה שיוצר רצפים כמו שלו×. הפתרון הזמני הוא לפתוח את הקובץ מחדש ולוודא במפורש שהקידוד הוא UTF-8, אבל זה לא תמיד אפשרי אם התוכנה לא מאפשרת לבחור קידוד.
תלוי כמה עמוקה ההריסה. אם הבעיה היא רק קידוד – הטקסט נראה כמו ×©×œ×•× אבל באורך כפול מהצפוי – אפשר לפעמים לתקן בפתיחת הקובץ בעורך טקסט שמאפשר לבחור במפורש פענוח כ-UTF-8, ואז לשמור מחדש עם קידוד נכון. זו בעיה הפיכה, כי המידע המקורי עדיין קיים ורק פורש לא נכון. אבל אם הקובץ עבר כמה סבבי פתיחה ושמירה בקידודים שונים, כל סבב מוסיף שכבת עיוות משלו, והתוצאה לרוב אינה הפיכה. במקרה כזה תמלול מחדש מהיר יותר מניסיון לפענח את השכבות.
אותה בעיה בדיוק ומאותה סיבה: גם ערבית נכתבת ב-UTF-8 בשני בייטים לתו וגם היא שפת RTL, כך שתוכנה שנכשלת בעברית תיכשל באותה צורה בערבית – קידוד שגוי, כיווניות הפוכה ופיסוק במקום הלא נכון. קפטן קאט תומך בשתי השפות עם אותה שכבת RTL אמיתית, כך שערוץ דו-לשוני לא צריך פתרון נפרד לכל שפה. פרטים נוספים בעמוד כתוביות בערבית לפרמייר.
זה בדיוק המקרה שבו כלים רבים נכשלים, כי הם צריכים להחליט על סדר תצוגה לשני כיווני כתיבה באותה שורה. משפט כמו "קניתי את ה-iPhone 15 אתמול" דורש שהמילים העבריות יוצגו מימין לשמאל, שהמילה iPhone תישאר LTR פנימית, שהמספר 15 יישאר LTR, ושסדר הביניים ביניהם יישמר. אלגוריתם Bidi תקני יודע לטפל בזה, אבל לא כל תוכנת כתוביות מיישמת אותו נכון. זו בדיוק הסיבה שהדוגמה בעמוד הזה מראה מילה הפוכה לצד מספר שנשאר תקין: הבעיה היא ברמת האלגוריתם, לא ברמת השפה.
לא. גופן לא פותר בעיית קידוד או כיווניות, כי הוא קובע רק איך כל תו נראה גרפית, ולא באיזה סדר או כיוון התווים מוצגים. אפשר להשתמש בכל גופן עברי תקין שמותקן במערכת ועדיין לקבל ג'יבריש אם הקידוד שגוי, או טקסט הפוך אם ה-Bidi שגוי. הבלבול נפוץ, כי כשמשהו נראה שבור האינסטינקט הראשון הוא לחשוד בגופן, אבל כדאי לבדוק קודם אם מדובר בקידוד או בכיווניות.
עמוד ההורה מתמקד בקושי לעבוד עם טקסט RTL בממשק Essential Graphics של פרמייר, כלומר בכיווניות התצוגה בעורך עצמו. העמוד הזה מתמקד במשהו ספציפי יותר: מה קורה כשהטקסט נהרס עוד לפני שהוא מגיע לפרמייר, בגלל קידוד תווים שגוי בשלב הייצוא והייבוא של קובץ ה-SRT. אפשר לסבול משתי הבעיות בו-זמנית, אבל האבחון שונה ולכן גם הפתרון שונה.
אפשר לצמצם את הסיכון בכלל פשוט: לא לפתוח קובץ SRT בעברית בעורך טקסט שלא מאפשר לבחור קידוד במפורש, ותמיד לוודא שהתוכנה ששומרת את הקובץ מציינת UTF-8. אבל זה פתרון עוקף ולא מניעה אמיתית: כל עוד יש שלב ביניים חיצוני של ייצוא, פתיחה, שמירה וייבוא, יש סיכוי לטעות אנוש או תוכנה. הדרך היחידה למנוע את הבעיה לגמרי היא לוותר על שלב הביניים, בדיוק כפי שקורה כשהכתוביות נכתבות ישירות כטראק של פרמייר במקום לעבור דרך קובץ טקסט חיצוני.
די לתקן קידוד ג'יבריש בכתוביות – תנו לפרמייר לקבל טקסט עברי תקין מהרגע הראשון
כתוביות בעברית ובערבית עם RTL אמיתי, נכתבות ישירות כטראק כתוביות של פרמייר, בלי שלב ביניים של SRT שעלול להישבר. 7 ימי ניסיון חינם בכל התוכניות, אפשר לבטל בכל רגע.
התחילו ניסיון חינם