תיקון עברית משובשת ב-MySQL וב-phpMyAdmin

phpMyAdmin, קובץ SQL או האפליקציה שלכם מציגים ×©×œ×•× או ??? במקום שלום? בדרך כלל הטבלה, החיבור והייבוא לא תואמים זה לזה. Mojibuster מתקן ייצוא ישירות בדפדפן – ואחר כך מגדירים את MySQL נכון, אחת ולתמיד.

עובד עם טקסט ועם הקבצים האלה:

  • CSV
  • TXT
  • JSON
  • XML
  • SRT
  • VTT
  • SMI
  • TSV
  • MD
  • HTML
  • SQL
  • LOG

למשל קובצי ייצוא מאקסל, גיבויים של מסדי נתונים, כתוביות וקוד של אתרים.

תיקון

  1. גררו קובץ או הדביקו טקסט
  2. התיקון נעשה אוטומטית
  3. העתיקו או הורידו את התוצאה
או גררו את הקובץ לכאן
  • בלי העלאה. הקבצים מתוקנים ישירות בדפדפן ולעולם לא יוצאים מהמכשיר שלכם.

  • שרתים באיחוד האירופי. Mojibuster פועל על שרת בפינלנד (האיחוד האירופי), ולכן חלה עליו תקנת הגנת המידע הכללית (GDPR). נוסח התקנה (EUR-Lex, באנגלית)

שלושה מקומות ש-MySQL דורש בהם קידוד

  • עמודה או טבלה: ערכת התווים שבה הנתונים נשמרים, למשל utf8mb4, latin1 או cp1255 (עברית של Windows).
  • חיבור: ערכת התווים שבה הלקוח והשרת מדברים – נקבעת עם SET NAMES utf8mb4 או בהגדרות החיבור.
  • קובץ: הקידוד שבו נקרא ייבוא או נכתב ייצוא – ב-phpMyAdmin בשדה ערכת התווים של הקובץ.

אם השלושה לא תואמים, התווים משתבשים. המקרה הנפוץ ביותר: טקסט עברי ב-UTF-8 נכתב דרך חיבור latin1 לעמודת latin1. האותיות העבריות לא קיימות ב-latin1, ולכן חלקן הופכות ל-? ונאבדות לצמיתות. מה שעובר נשמר, אבל phpMyAdmin והייצוא מציגים שלו×.

שורה מייצוא CSV של phpMyAdmin

לפני

"1","ãðä ëäï","øçåá äøöì 12","úì àáéá"

אחרי

"1","דנה כהן","רחוב הרצל 12","תל אביב"

בדיקת ערכות התווים

  • SHOW VARIABLES LIKE 'character_set%'; מציג את הגדרות השרת והחיבור.
  • SHOW CREATE TABLE customers; מציג את ערכת התווים של הטבלה ושל העמודות.
  • SELECT name, HEX(name) FROM customers LIMIT 5; מציג את הבתים האמיתיים: בעמודת utf8mb4, D7A9 הוא ש, ואילו C397C2A9 הוא ש משובש שכבר נשמר.

תיקון ייצוא או גיבוי

  1. ייצאו את הטבלה מ-phpMyAdmin כ-SQL או כ-CSV – או עם mysqldump --default-character-set=utf8mb4.
  2. גררו את הקובץ לתיבה שלמעלה. Mojibuster מתקן רק את המקומות המשובשים; תווים תקינים נשארים כמות שהם.
  3. בדקו את התיקונים תחת מה השתנה? והורידו את הקובץ.
  4. ייבאו אותו לטבלת utf8mb4 ובחרו utf-8 כערכת התווים בחלון הייבוא.
  5. נסו קודם על עותק לפני שמחליפים את הטבלה האמיתית.

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

תיקון הסיבה

  • צרו טבלאות חדשות עם DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci. ההשוואה מתעלמת מניקוד, כך שחיפוש עובד גם בטקסט מנוקד.
  • הגדירו את חיבור האפליקציה ל-utf8mb4, ב-PHP למשל עם charset=utf8mb4 ב-DSN של PDO.
  • אם בתי UTF-8 יושבים בעמודת latin1, אל תמירו אותה ישירות עם CONVERT TO – זה מקודד את הטקסט פעם שנייה ויוצר קידוד כפול. הדרך הבטוחה עוברת דרך סוג בינארי: קודם MODIFY name VARBINARY(255), ואז MODIFY name VARCHAR(255) CHARACTER SET utf8mb4.
  • אם MySQL מחליף תווים ב-?, העמודה או החיבור לא יכולים לייצג אותם. מה שכבר נשמר כך אבוד – עוד על כך במה זה מוז'יבייק.

שאלות נפוצות

למה באפליקציה שלי הכול נראה תקין ובפי phpMyAdmin לא?

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

איזה collation כדאי לבחור?

utf8mb4_unicode_ci מתאים לרוב האפליקציות; מ-MySQL 8 ברירת המחדל היא utf8mb4_0900_ai_ci. החשוב יותר הוא ערכת התווים utf8mb4 – ולא utf8, שב-MySQL לא מסוגל לשמור אימוג'י.

זה עובד גם עם MariaDB?

כן. MariaDB מטפלת בערכות תווים כמו MySQL, והפקודות זהות.

מה גודל הגיבוי המרבי?

עד 100 MB לקובץ. מסדי נתונים גדולים יותר ייצאו טבלה אחר טבלה.

מדריכים נוספים