קלוד קוד מחק את העברית בקובץ? כך שומרים על קבצי Windows-1255

מי שעובד עם מערכות ישראליות ותיקות מכיר את הקבצים האלה: CSV שיוצא מתוכנת הנהלת חשבונות, קובץ הגדרות של מערכת שנכתבה לפני עשרים שנה, דוח שמגיע ממשרד ממשלתי. העברית בהם שמורה בקידוד Windows-1255, ולא ב-UTF-8. עד לפני שלושה ימים, מספיק היה לבקש מקלוד קוד לשנות בקובץ כזה שורה אחת באנגלית כדי שכל האותיות העבריות בו יימחקו. לא רק בשורה שנערכה. בכל הקובץ.

התיקון יצא ב-9 באוקטובר 2026, אבל רוב המשתמשים בערוץ היציב עדיין לא קיבלו אותו.

מה בדיוק קרה?

ב-יומן השינויים של גרסה 2.1.296 מופיעה שורה אחת בין 56 תיקונים: כלי העריכה של קלוד קוד, Edit ו-NotebookEdit, החליפו כל תו שאינו ASCII בקבצים שאינם UTF-8 תקין. הדוגמאות שם הן קידודים של שפות אחרות, Windows-1252 המערבי, Shift-JIS היפני ו-GBK הסיני, אבל הכלל הוא ״כל קובץ שאינו UTF-8 תקין״. קובץ עברי ב-Windows-1255 נופל בדיוק בהגדרה הזאת.

לא הסתפקנו בשורה מהיומן, ובדקנו בעצמנו. יצרנו קובץ קטן ב-Windows-1255 עם שתי שורות בעברית ושורה אחת באנגלית, ובסשן שעוד לא קיבל את 2.1.296 ביקשנו לשנות מילה אחת בשורה האנגלית. העריכה דווחה כמוצלחת. אחריה, כל אחת משש-עשרה האותיות העבריות בקובץ הפכה לתו ההחלפה של יוניקוד, אותו מעוין שחור עם סימן שאלה (U+FFFD), גם בשורות שאף אחד לא ביקש לגעת בהן. השורה באנגלית השתנתה כמו שביקשנו.

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

למה קלוד לא שם לב?

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

זה ההבדל בין הבאג לבין התיקון. מגרסה 2.1.296 העריכה בקובץ כזה נדחית ולא מתבצעת. אבל התיקון מונע את ההרס, הוא לא מלמד את קלוד לקרוא Windows-1255. גם בגרסה החדשה, קובץ עברי בקידוד הישן נשאר בשבילו קובץ שהוא לא יכול לקרוא כמו שצריך.

למי זה עדיין קורה?

נכון ל-12 באוקטובר 2026, ב-npm הערוץ העדכני (‎latest‎) עומד על 2.1.296 והערוץ היציב (‎stable‎) על 2.1.287. כלומר מי שבחר בערוץ היציב עדיין עובד עם הגרסה שמוחקת עברית, ויקבל את התיקון רק כשהיציב יתקדם.

את הגרסה המקומית בודקים כך:

claude --version

כל מה שמתחת ל-2.1.296 חשוף. וגם מעליה, כאמור, הקובץ לא נהרס אבל גם לא נערך.

מה עושים לפני שנותנים לקלוד לגעת בקובץ?

ממירים אותו ל-UTF-8. זו ההמלצה הנכונה בכל גרסה, ולא רק בישנות: היא גם מגינה מפני הבאג וגם מאפשרת לקלוד לקרוא את העברית ולעבוד איתה. בטרמינל של לינוקס, macOS או Git Bash:

iconv -f CP1255 -t UTF-8 report.csv > report.utf8.csv

ובחלונות, ב-PowerShell 5.1 שמגיע עם המערכת, בלי להתקין שום דבר (הדרך הזאת כותבת UTF-8 בלי BOM):

$text = [IO.File]::ReadAllText("C:\data\report.csv", [Text.Encoding]::GetEncoding(1255))
[IO.File]::WriteAllText("C:\data\report.utf8.csv", $text, (New-Object Text.UTF8Encoding $false))

את שתי הפקודות הרצנו על קובץ הבדיקה, ובשתיהן העברית יצאה זהה למקור.

שימו לב לשם הקובץ החדש: לא דורסים את המקור. אם המערכת שמייצרת או קוראת את הקובץ יודעת לעבוד רק עם Windows-1255, ממירים, עורכים, וממירים בחזרה (‎-f UTF-8 -t CP1255‎). לפני שמחליפים קובץ שמערכת אחרת תלויה בו, בודקים שהיא מקבלת UTF-8.

ואם זה כבר קרה?

אם הקובץ בתוך מאגר git, הוא בטוח. מחזירים אותו לגרסה האחרונה שנשמרה:

git restore report.csv

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

ואם אתם לא בטוחים איזה קידוד יש לקובץ, ‎file‎ ב-Git Bash או בלינוקס יגיד לכם. קובץ Windows-1255 מזוהה אצלו בדרך כלל כ-ISO-8859, וקובץ תקין כ-UTF-8.

שורה תחתונה

שלושה צעדים, בסדר הזה: לבדוק גרסה, להמיר ל-UTF-8 לפני שקלוד נוגע בקובץ, ולעבוד רק על קבצים שנמצאים ב-git. הראשון סוגר את הבאג. השני הוא מה שבאמת מאפשר לקלוד לעבוד עם העברית שלכם. השלישי הוא הרשת שתופסת את כל מה ששני הראשונים פספסו.

מי שמגדיר לקלוד קוד כללי עבודה קבועים יכול להוסיף שורה על הקידוד ל-CLAUDE.md, כמו בדוגמה שבמדריך ל-CLAUDE.md. על התקנה ועבודה בחלונות: התקנת קלוד קוד ב-Windows. ולמי שמתחיל מההתחלה: המדריך המלא לקלוד קוד.

המקור לתיקון: יומן השינויים של קלוד קוד, גרסה 2.1.296. הבדיקה המקומית ומצב ערוצי העדכון ב-npm נעשו ב-12 באוקטובר 2026.