קובץ CSV עם עברית נפתח באקסל כג׳יבריש — למה ואיך מתקנים

התשובה בשורה אחת

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

אקסל בווינדוס מנחש לפי דף הקוד המקומי של המערכת — זה שנקבע בהגדרת השפה לתוכניות שאינן Unicode. במחשב שמוגדר לעברית זה הקידוד הישן Windows-1255, ובמחשב שמוגדר לאנגלית זה Windows-1252. קובץ שנשמר ב־UTF-8 — הקידוד של כל מערכת מודרנית — נקרא לפי הניחוש הזה ויוצא ג׳יבריש, וצורת הג׳יבריש מסגירה איזה מהשניים קרה.

יש יוצא מן הכלל אחד, וזה כל הסיפור: אם הקובץ מתחיל בשלושה בייטים מיוחדים, EF BB BF, אקסל מזהה מיד שמדובר ב־UTF-8 ופותח נכון. שלושת הבייטים האלה נקראים BOM (סימון סדר בתים), הם אינם נראים על המסך, והם ההבדל היחיד בין קובץ שנפתח נכון לקובץ שנפתח כג׳יבריש.

קודם כול — מאיזו תקלה סובלים

מה שרואים על המסך מספר בדיוק מה קרה:

מה רואים	מה קרה	מה עושים
שלו×	הקובץ ב־UTF-8, ואקסל קרא אותו כ־Windows-1252 — כלומר דף הקוד של המחשב לטיני	להוסיף BOM או לייבא עם קידוד ידני
׳©׳׳•׳	אותו קובץ UTF-8 בדיוק, אלא שכאן דף הקוד של המחשב עברי והקריאה הייתה ב־Windows-1255	אותו פתרון — BOM או ייבוא ידני
ùìåí או àáâ	הקובץ עצמו ב־Windows-1255, ונקרא כלטיני	להמיר את הקובץ ל־UTF-8
ריבועים או סימני שאלה	הקידוד המקורי אבד בשמירה	לבקש את הקובץ מחדש מהמקור
עברית תקינה, אבל כל השורה בתא אחד	תקלת מפריד, לא קידוד	ראו את הפרק על המפריד למטה

שתי השורות הראשונות הן אותה תקלה בשני מחשבים שונים — משתנה רק איך היא נראית — ולכן גם הפתרון זהה. השורה השלישית היא תקלה הפוכה, ושם הפתרון אחר. אם הג׳יבריש כבר הודבק אצלכם כטקסט ולא כקובץ, כלי תיקון העברית מחזיר לקריאות את שתי הצורות הנפוצות, שלו× ו־ùìåí. הרחבנו על ההבדל ביניהן במדריך על עברית הפוכה וג׳יבריש.

דרך 1 — להמיר את הקובץ פעם אחת ולסגור את הנושא

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

גררו את הקובץ לכלי המרת הטבלאות. הכלי קורא את הבייטים עצמם ולא סומך על הסיומת: הוא מנסה UTF-8 בקריאה קפדנית, וכשזה נכשל הוא נופל אוטומטית ל־Windows-1255 ואומר לכם שזה מה שקרה. גם קובץ שנשמר כ־“טקסט Unicode” (UTF-16) מזוהה ונקרא.

אחרי שהטבלה מוצגת בתצוגה המקדימה, יש שתי אפשרויות:

• המרה ל־Excel — הפתרון מהשורש. בקובץ xlsx הטקסט שמור כ־UTF-8 בתוך המבנה עצמו, ואין שום ניחוש קידוד. זו ברירת המחדל שהכלי מציע כשמעלים CSV.
• המרה ל־CSV — אם צריך להישאר בפורמט הזה. תיבת הסימון “סימון UTF-8 בתחילת הקובץ” מסומנת כברירת מחדל, וזה בדיוק ה־BOM. הקובץ שיוצא נפתח באקסל בלחיצה כפולה, בלי אשפים.

מתי כן לבטל את הסימון: כשהיעד הוא מערכת ולא אדם. חלק מהמפרסרים הישנים לא מתעלמים מה־BOM, ואז שם העמודה הראשונה מגיע אליהם עם תו נסתר בתחילתו והקוד לא מוצא את השדה. לאקסל להשאיר מסומן; לסקריפט או לייבוא לשרת — לשקול לבטל.

דרך 2 — לייבא לאקסל במקום לפתוח

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

1. פתחו חוברת ריקה — לא את הקובץ.
2. בלשונית נתונים לחצו על מטקסט/CSV ובחרו את הקובץ.
3. בתיבה שנפתחת, בשדה מקור הקובץ, בחרו 65001: Unicode (UTF-8). העברית בתצוגה המקדימה מתקנת את עצמה מיד.
4. בשדה מפריד בחרו את המפריד הנכון — התצוגה המקדימה מראה אם קלעתם.
5. יש בקובץ עמודת טלפון, ת“ז או מק”ט? ברשימה זיהוי סוגי נתונים בחרו אל תזהה סוגי נתונים, אחרת האפסים המובילים יימחקו בטעינה. לשליטה מדויקת יותר לחצו המרת נתונים, סמנו את העמודה, שנו את הסוג לטקסט ואז סגור וטען.
6. לחצו טען.

ההבדל בין “פתיחה” ל“ייבוא” הוא כל העניין: בפתיחה אקסל מנחש, בייבוא אתם קובעים.

אם אתם על גרסה שבה אשף הייבוא הישן מוכר יותר, אפשר להחזיר אותו: קובץ ← אפשרויות ← נתונים ← הצג אשפי ייבוא נתונים מדור קודם, ואז יופיע נתונים ← קבלת נתונים ← אשפים מדור קודם ← מטקסט (מדור קודם). באשף הזה בוחרים קידוד בשלב הראשון, מפריד בשני, ובשלב השלישי אפשר לסמן עמודה ולהגדיר אותה כטקסט — שם זה נגיש יותר מאשר בתיבה החדשה. בחלק מהגרסאות גם שינוי הסיומת ל־.txt ופתיחה מתוך אקסל מפעילים את אותו אשף.

דרך 3 — גוגל שיטס כעוקף

פתחו גיליון חדש, ואז קובץ ← ייבוא ← העלאה. שיטס קורא UTF-8 כברירת מחדל ומזהה את המפריד לבד, ולכן קובץ UTF-8 ייפתח שם נכון גם בלי BOM. משם אפשר קובץ ← הורדה ← Microsoft Excel ולקבל xlsx תקין.

שתי הסתייגויות שכדאי לדעת מראש:

• שיטס לא נותן לבחור קידוד. קובץ שנשמר ב־Windows-1255 יישאר ג׳יבריש גם שם, כי ההנחה תמיד UTF-8. בשביל המקרה הזה צריך את דרך 1 או 2.
• הקובץ עולה לשרת. בטבלת שכר, ברשימת לקוחות או בקובץ עם מספרי טלפון זו לא החלטה מובנת מאליה. ההמרה אצלנו רצה כולה בדפדפן והקובץ לא עוזב את המחשב — ואחרי המרה אחת מלאה, כשכל הקוד כבר יושב אצלכם, אפשר לנתק את האינטרנט ולראות שההמרה הבאה עובדת בדיוק אותו דבר.

הבעיה השנייה: העברית תקינה, אבל הכול בתא אחד

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

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

לבדוק מה מוגדר אצלכם: לוח הבקרה ← אזור ← הגדרות נוספות ← מפריד רשימות. מה שכתוב שם הוא מה שאקסל יצפה לו בפתיחה — וגם מה שהוא יכתוב בשמירה.

מכאן שיש שלוש אפשרויות:

• לייבא במקום לפתוח (דרך 2) ולבחור את המפריד ידנית — הפתרון היחיד שלא משנה דבר במחשב.
• לשנות את הגדרת המערכת — עובד, אבל משפיע על כל תוכנה שקוראת רשימות, ולא רק על הקובץ הזה.
• לשמור את הקובץ עם המפריד שהיעד מצפה לו. בכלי ההמרה אצלנו אפשר לבחור בקריאה בין זיהוי אוטומטי לפסיק, נקודה־פסיק, טאב או קו אנכי, ובכתיבה בין פסיק, נקודה־פסיק וטאב.

ואם אתם מייצרים קובץ למישהו אחר ולא יודעים מה מוגדר אצלו — הבחירה תלויה בשאלה מי יפתח אותו. מערכת שקוראת את הקובץ תסתדר הכי טוב עם טאב, שאינו מופיע בתוך הערכים ואינו משמש באף לוקאל כמפריד עשרוני. אדם שילחץ פעמיים על הקובץ באקסל יקבל דווקא מטאב את כל השורה בתא אחד, ובשבילו עדיף פסיק עם סימון UTF-8 — או קובץ Excel, שעוקף את כל הסיפור.

הכיוון ההפוך: אתם מייצאים והעברית נשברת אצל מי שמקבל

בתיבת השמירה של אקסל יש שתי אפשרויות שנראות כמעט זהות:

• CSV (מופרד בפסיקים) — שומר בקידוד המקומי, כלומר Windows-1255. כל מערכת שקוראת UTF-8 תראה ג׳יבריש.
• CSV UTF-8 (מופרד בפסיקים) — שומר UTF-8 עם BOM. זו האפשרות הנכונה כמעט תמיד.

ההבדל אינו רק אסתטי. ב־Windows-1255 יש מקום לעברית, לאנגלית ולסימן השקל, אבל אין מקום לתווים שמחוץ לטווח — אימוג׳י, ערבית, קירילית, ואפילו אותיות לטיניות עם סימנים כמו é או ü. תו כזה נשמר כסימן שאלה, וזה אובדן מידע שאי אפשר לבטל: פתיחת הקובץ מחדש לא תחזיר אותו.

אם בתפריט השמירה יש רק “טקסט Unicode (*.txt)”, גם הוא פתרון סביר — הוא שומר UTF-16 מופרד בטאבים. כלי ההמרה קורא גם אותו ומוציא UTF-8.

שדות שנשברים גם כשהקידוד תקין

זו הקטגוריה שגורמת לנזק השקט ביותר, כי הקובץ נראה בסדר גמור:

• אפס מוביל נעלם. ‏0501234567 הופך ל־501234567, כי אקסל רואה מספר. אותו דבר בתעודת זהות שנכתבה בתשע ספרות עם אפס בהתחלה. אם אתם מוודאים תקינות של עמודת ת“ז, כלי בדיקת ספרת הביקורת והמדריך איך עובדת ספרת הביקורת מסבירים למה אפס מוביל הוא חלק מהמספר ולא קישוט.
• מספרים ארוכים הופכים לכתיב מדעי. מספר חשבון או כרטיס אשראי בן 16 ספרות מוצג כ־1.23457E+15, וגרוע מכך: אקסל שומר 15 ספרות מובהקות בלבד, והשאר מתאפסות. גם כאן — בלתי הפיך.
• תאריכים מתהפכים. ‏03/04/2026 ייקרא 3 באפריל או 4 במרץ, תלוי בהגדרות האזור של מי שפותח. הכתיב היחיד שאינו דו־משמעי הוא YYYY-MM-DD, ולכן זה הכתיב שכלי ההמרה מייצר כשהוא קורא תאריך מקובץ אקסל.

איך מגנים על השדות האלה: בתיבה של “נתונים ← מטקסט/CSV” אין בחירת עמודות, ולכן צריך אחד משניים — לבחור אל תזהה סוגי נתונים, שמשאיר את כל העמודות כטקסט, או ללחוץ המרת נתונים, לסמן שם את העמודה, לשנות את הסוג לטקסט ואז סגור וטען. ואם אתם ממירים אצלנו ל־Excel זה קורה מעצמו: ערך כמו 007 או 054-1234567 נשמר כטקסט, כי הכלי כותב תא כמספר רק כשהמסלול הלוך־ושוב לא משנה בו אף תו.

מה הכלי שלנו לא עושה

הבטחה בלי מגבלות היא לא הבטחה:

• קובץ xls ישן (הפורמט שלפני 2007) אינו נתמך. פתחו אותו באקסל ושמרו כ־xlsx.
• מחוברת עם כמה גיליונות מומר גיליון אחד בכל פעם, לפי בחירתכם.
• תאים ממוזגים בקובץ המקור מתפרקים: הערך נשאר בתא הראשון של האזור והשאר יוצאים ריקים — שינוי בנתונים ולא רק במראה, ולכן כדאי להציץ בתצוגה המקדימה. עיצוב, תרשימים ותמונות אינם עוברים כלל.
• קובץ ה־Excel שנוצר הוא גיליון פשוט — טבלת תאים בלבד, בלי נוסחאות ובלי עיצוב. תאריך נכתב בו כטקסט בכתיב YYYY-MM-DD ולא כתאריך שאקסל ממיין ומחשב, וצריך להמיר את העמודה אחרי הפתיחה.
• בקריאת xlsx, נוסחה מגיעה כערך המחושב האחרון ששמור בקובץ. אין חישוב מחדש בדפדפן.
• הכול נטען לזיכרון הלשונית, ולכן המגבלה המעשית היא 20MB לקובץ.

שאלות שחוזרות

הקובץ נראה תקין בפנקס הרשימות ושבור באקסל. איך? פנקס הרשימות המודרני — מעדכון 2019 של ווינדוס 10 והלאה — מזהה UTF-8 גם בלי BOM. אקסל, בפתיחה בלחיצה כפולה, לא. אותו קובץ בדיוק, שתי תוכנות עם ניחוש שונה.

איך מוסיפים BOM בלי שום כלי? פתחו את הקובץ בפנקס הרשימות, קובץ ← שמירה בשם, ובתפריט הקידוד בחרו UTF-8 with BOM. שמרו על אותו שם. גם תפריט הקידוד הזה הופיע רק באותו עדכון, ובגרסאות ישנות יותר לא תמצאו אותו. שיטה טובה לקובץ קטן; בקובץ של עשרות אלפי שורות פנקס הרשימות יזחל.

ומה עם JSON? קובצי JSON הם UTF-8 לפי התקן, ולכן בעיית הניחוש לא קיימת בהם. אם אתם עובדים מול מערכת שמחזירה JSON וצריכים לראות אותו כטבלה — אותו כלי המרה עושה גם את זה, וכלי עיצוב ה־JSON מסביר שגיאות מבנה בעברית. פירוט על שאר כלי המפתחים: מדריך כלי המפתחים.

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

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